19 ms·

Python 3 Is Winning Library Developer Support

297 points by brettcannon 11y ago

buovjaga 11y ago
The 360 angle: http://py3readiness.org/ http://py3readiness.org/
- mangeletti 11y ago
  Thanks for the link. I found it shocking that Fabric was still not supported.
  - ThatGeoGuy 11y ago
    I am skeptical of the link entirely. It says gevent does not support Python 3, yet if you look at the PyPI page [0], it says "Gevent runs on Python >= 2.6, Python >= 3.3, or PyPy >= 4.0.1 (but not PyPy3)". Is the lack of PyPy3 really worth saying Gevent doesn't run on Python 3 (the language, not CPython specifically)? Perhaps this website is out-of-date in some respects, and helps contribute to the confusion. On an unrelated note, a lot of people I have encountered claim Gevent as the reason they haven't switched yet. For now I guess such claims are shaky, assuming the PyPI page isn't false advertising. [0] https://pypi.python.org/pypi/gevent https://pypi.python.org/pypi/gevent
    - mangeletti 11y ago
      I think Gevent 1.1 added Python 3 support, and its final release was just a few days ago (03/05).
    - pingswept 11y ago
      The same is true for Supervisor. It has supported Python 3 for years.
      - brettcannon 11y ago
        Their PyPI page explicitly says otherwise: https://pypi.python.org/pypi/supervisor https://pypi.python.org/pypi/supervisor . It looks like there is support in their repository but not in any official release (yet).
        pingswept 11y ago
        You are correct. But the setup.py for Supervisor noted support for Python 3 starting in May of 2014: https://github.com/Supervisor/supervisor/commit/ad5cd0849a5f7c04afe6837add63ca653b585540 https://github.com/Supervisor/supervisor/commit/ad5cd0849a5f... I don't know why PyPI isn't updated yet.
    - brettcannon 11y ago
      pyreadiness.org uses https://github.com/brettcannon/caniusepython3 https://github.com/brettcannon/caniusepython3 to figure out if a project supported Python 3. The issue is that gevent doesn't specify their support through a trove classifier on PyPI. There is a hand curated overrides file, though, that I just edited to list as supported (https://github.com/brettcannon/caniusepython3/blob/master/caniusepython3/overrides.json https://github.com/brettcannon/caniusepython3/blob/master/ca...). I don't know how often py3readiness.org updates, but the issue should resolve itself the next time they update the data on the site.
      - ThatGeoGuy 11y ago
        This is actually very informative. Combined with mangeletti's answer, it does explain the discrepancy. Thank you for sharing this. It's interesting (and also sad) that this tool has evolved up to version 3.3.0 over the years since we had Python 3.0.
      - neokya 11y ago
        I will take note and update it ;) It should update those overrides daily but seems like it is not.
- levemi 11y ago
  fabric is that lone holdout that went against all conventional wisdom and decided on a complete rewrite when a small few simple changes would have been enough. fabric's developer has made promises over the last few years for their rewrite to be beta ready and it's nowhere yet. I say that with all the appreciation in the world for the work that went into original fabric, which is a wonderful tool. Criticism may be harsh but it's not inaccurate. What's amazing is that the forks to bring fabric to python3 haven't really caught on and I think that's partly because fabric is something you do not use inside your application. It's used in deploy and configuration scripts. It being python 2 hasn't been a problem for most people since most distros and platforms ship with python 2 support. It's just that the people who want to stop writing python 2 for everything including their deploy scripts who are the most vocal and it's not a big enough group. The fabric dev basically has until platforms start to abandon python 2, and who knows when that will be, so maybe they have forever for their great rewrite.
  - tclancy 11y ago
    Fabric is superseded by Invoke (https://github.com/pyinvoke/invoke https://github.com/pyinvoke/invoke), from the same developer. So other than that . . .
    - levemi 11y ago
      > Warning...While fully usable, Invoke is still pre-1.0 software and has no backwards compatibility guarantees until the 1.0 release occurs! Please make sure to read the changelog carefully anytime you upgrade! And if I recall, it's only half of fabric's feature set.
stared 11y ago
Plots using second since epoch as the x axis... nope. (I mean, if I do it then it is for internal plots only and still I am feeling lazy.)
dsil 11y ago
I really like the showing-his-work, via ipython/jupyter notebooks. Unfortunately it's behind an azureml login so it can't be directly linked.
- chupapuma 11y ago
  If you want to link to the Jupyter Notebook, you should be able to share the notebook in the gallery. http://aka.ms/py3winningnb http://aka.ms/py3winningnb or, if you want a less nice url, https://gallery.cortanaanalytics.com/Notebook/95a0e835f88b439ab0537c7b8e6daac5 https://gallery.cortanaanalytics.com/Notebook/95a0e835f88b43...
ihuman 11y ago
To add to this article, here is the Python 3 Wall of Superpowers. It is a list of the most popular packages on PyPI, and shows if they support Python 3. https://python3wos.appspot.com/ https://python3wos.appspot.com/
inanutshellus 11y ago
I program in python 2 because that's where /usr/bin/python takes me to. ;-)
- ChrisArgyle 11y ago
  Believe it or not, you don't even have to change your workflow to try out python 3. If you're on a Red Hat/Ubuntu-based system just add a '3' to everything (python3, pip3, pdb3, etc) edit: added relevant platforms
  - inanutshellus 11y ago
    I've been bitten by Poe's Law[1], despite the winky. Blast! Edit: Really though, it's a problem of apathy. I'm supposed to care about python 3? Why? When I type "python" on the command line (and everyone else that doesn't care, which is most every "filthy casual", right?), I--and everyone else with a default install of Ubuntu and CentOS/RedHat--gets python 2. Fix that, and overnight you'll have massive python 3 uptake. In fact, you're suggesting I set myself up to be stuck with the problem Maven is in, which is that everyone has an "m2" repository even though they're onto Maven 3. I'm supposed to hardcode "3" into everything? C'mon. [1] https://en.wikipedia.org/wiki/Poe's_law https://en.wikipedia.org/wiki/Poe's_law
    - brettcannon 11y ago
      I believe both Ubuntu and Fedora have/are dropping Python 2 from the default install this year.
- deleted 11y ago
  [deleted]
rcarmo 11y ago
Well, I'd be happier if Pypy 3 were faster. As it is, I can get pretty decent speedups with 4.0 (2.7.x) but not for python3 code in my use cases...
- mangeletti 11y ago
  If Python Software Foundation would create a serious initiative to double (or more) the speed of cPython, specifically for Python 3.5+, I'd donate at least $100, and I'm sure there are a vast many other individuals (and companies) that would donate as well. In the meantime, my Python-related donations go to Django. I think that speed can't be treated like a niche feature (e.g., via PyPy, Cython, etc.) any longer; not with tools like Go out there.
  - brettcannon 11y ago
    There's actually been a lot of work the past few months to speed up CPython 3.6. I expect there will be more news coming out of PyCon US on stuff related to this.
  - rufugee 11y ago
    I wonder why Dropbox is focusing Pyston (https://github.com/dropbox/pyston https://github.com/dropbox/pyston) only on 2.7 atm. With PyPy supporting 2.7 very well, it'd seem a greater benefit to the community to target 3. That said, I'm sure there are specific things Dropbox needs to solve for 2.7 which PyPy doesn't do.
    - brettcannon 11y ago
      Pyston targets Python 2.7 because that's what they use on their servers. As for why Pyston over PyPy, http://blog.pyston.org/2015/11/24/pyston-talk-recording/ http://blog.pyston.org/2015/11/24/pyston-talk-recording/ has a nice video that mentions why (among other things).
    - gsnedders 11y ago
      Pyston has a goal of full C-API compatibility, unlike PyPy. Dropbox are almost certainly not trying to create the greatest benefit for the community, but rather the greatest benefit for themselves, and they have huge amounts of Python 2 code in production. As such, Python 2.7 with full C-API compatibility makes sense for them to focus on.
MrZongle2 11y ago
FTA: "In 3 months, Python 3 will be better supported than Python 2." This just seems to validate my choice to stick with Python 2 up until now.
- lmm 11y ago
  If you're an application developer rather than a library developer then yeah that may well have been the correct decision. But if you intend to maintain your application for more than 3 months then it's time to switch to Python 3 now.
  - MrZongle2 11y ago
    "But if you intend to maintain your application for more than 3 months then it's time to switch to Python 3 now." No disagreement there. But I'm surprised at the downvotes I've received.
afarrell 11y ago
Ubuntu 16.04 LTS is planned to have only python3 installed by default
- collinmanderson 11y ago
  Super exciting.
- iso-8859-1 11y ago
  here is the bug https://blueprints.launchpad.net/ubuntu/+spec/foundations-x-python3-only https://blueprints.launchpad.net/ubuntu/+spec/foundations-x-...
declnz 11y ago
Interesting. Whilst it is slightly embarrassing how long it's taken, recently I feel that Python 3 conversion is gaining critical mass, and I now hope / expect these adoption lines to go non-linear in the coming year or so...
KaiserPro 11y ago
meh, there isn't (still) any reason to really jump onboard python 3, 2.7 is good enough for me the only real selling point is that strings are unicode by default. Unless I'm missing something python 3 just doesn't really seem to be worth the effort, yet. Can someone enlighten me?
- mey 11y ago
  When will support stop for Python 2.7? Once it stops being patched/supported, it represents a security risk (in my book). Additionally, eventually new libraries will also stop supporting 2.7, with the same issues as well as making development harder (or not as easy as your peers/competitors)
  - brettcannon 11y ago
    The Python development team will cease supporting Python 2.7 in 2020. After that you will have to buy support from someone like Red Hat or Continuum Analytics.
    - mey 11y ago
      So I assume everyone will migrate in 2021 or 2022.
      - rjurney 11y ago
        I don't think people will migrate at all.
    - rjurney 11y ago
      Open source support is not a centrally governed entity. FOSS support for Python 2.7 will continue after 2020. You will certainly still have the option of paying someone for support.
      - brettcannon 11y ago
        Sure, there's a chance people will pick up the mantle and essentially fork Python 2.7 to do unofficial bugfix releases past 2020; as you pointed out, it's open source and people can do what they want. But my point is there is no guarantee that will happen, nor that those unofficial releases will be of quality either. RH and Continuum on the other hand will most likely have financial incentives to make sure any maintenance they do meets the needs of their paying customers and thus are of a certain level of quality. IOW one possible future is more of a certain than the other.
mindcrime 11y ago
Is anybody surprised by this? Everybody knew the transition was going to take a long time, and that it would be a gradual process. It may be that it's actually been even slower and more gradual than people expected, but by and large everything seems to be proceeding nicely.
- godzillabrennus 11y ago
  I don't think anyone expected a lengthy transition at the onset of the version 3 release. It's taken a long time and the 2.X releases that have come along since have helped make the transition easier by showing developers some of the benefits from version 3 releases.
  - EliAndrewC 11y ago
    I was on the "Python 3000" mailing list while it was being planned, and the prevailing attitude seemed to be "it'll probably take 5 years before the community moves to Python 3". (That's paraphrased and not a direct quote, though I saw people say that sort of thing almost word for word a few times.) This was optimistic, but at least we see that the community is indeed gradually moving to Python 3, even if it's taking a few more years.
    - brettcannon 11y ago
      Technically the goal was a majority of new projects started using Python 3 in 5 years. Regardless, everyone knew it would take several years to reach a point like this.
      - mangeletti 11y ago
        Exactly, and I, for one, was using Python 3 for a new app, in production, in 2013, precisely 5 years after the release.
      - philipov 11y ago
        I switched from Perl to Python at version 3.4, and while it might be popular for people already invested in Python 2 to downplay the syntactic improvements, they were a big deal in convincing me to switch to Python as my go-to infrastructure language.
cdnsteve 11y ago
Who is this Microsoft? Loving this new community involvement.
BuckRogers 11y ago
It will have taken 8 years for Python3 supporting uploads to have outpaced Python2. If that's not lack of enthusiasm, I don't know what is. This is really a pitiful display. It's not a surprise though. This all stems back to the original reasons why Python3 was a bad idea. Some things to keep in mind regarding Python2/3. - Python3 is pure technical churn, nothing there is true technical innovation. They simply mixed the pot to their liking. Unicode is supported in Python2. - It is slower than Python2 for most people. Though there are crafty arguments out there that it's a wash. It's really not. - CPython3 was adopted to benefit the core development team, to make it easier to maintain. Not the community on the whole. The community has paid the price by doing a lot of unnecessary ports. - CPython3 was deliberately created to not support Python2 code even though modern VMs can easily support this. The CLR is a great example. They did it this way for their good, not for the community. - In most things in life, you'd always want to be using the latest supported version. That isn't the case here. It may still effectively "fail" with a permanent split. This migration is not even close to being completely in the books and won't be for another 10 to 20 years. So why punish yourself moving before it's in your best interests. The syntactic differences are so slight, it's extremely easy to switch to Python3 if it ever truly reaches Python's momentum (this article does not convey momentum holistically, that includes package downloads and the majority of employers using 3). - Related to the bullet above, almost all job opportunities are still Python2. - The ecosystem can't keep up, PyPy is still only production-ready on Python2. Python 3.2 support is essentially experimental by comparison. - Many changes and additions are being made and they aren't being vetted by the larger community. No significant userbase for Python3 has created this situation. Mistakes are being made and no one is around to speak up because the core devs don't care. - Python3 is feature-soup. There is now a new 4th and possibly 5th string formatting method in 3.6 incoming. Really jumped the shark on that one. See Mark Lutz's great insight on this topic and more.[0] - Downloads are still dramatically in Python2's favor, to this day. Judging from downloads, there's a ~10% community userate of Python3. - The bullet above means that the Python3 packages you do use are far less vetted and tested than the Python2 equivalent. - CPython3 was slopped together. The initial 3.0 release was mostly pure Python in effort to get it out the door. Many parts of the standard library that are written in C are slower than the modules used in the CPython 2.7 counterpart, to this day. It was not and is not being tested. The users are not there to test it either. - Community trust has been broken, I'm not sure anyone really believes another big break isn't incoming regardless of statements to the contrary. The core dev team is going to do what they want and you're going to like it, period. - Python3 zealots have done a lot of harm by not accepting valid criticism, and aggressively attacking those who do what is in their best interests (which we should all do, this should not just apply to the CPython core devs), and continue using Python2 all these years. Watch for downvotes instead of countering my points. - The 2020 date is a just a big political stunt and scare tactic. Code will continue working after 2020. As noted, it works better in CPython2 and PyPy today, and likely will in 2021 as well. - Python3 lives off of and is pushed by PSF propaganda. No way around it as there is no innovation involved. Which is what should determine if new technologies are adopted or not. - Usually when people make mistakes, such as Python3's existence, or the inability to mix Python2 and 3 code in the same VM- they go back and fix them. That has not happened with CPython3. - Even back in 2014 projects such as Pyston from GvR's employer (Dropbox), were Python(2)-only. It's still Python2 today, which says it all. All that said about this trainwreck, I'm in favor of getting back to a single major version of Python for the community. I'm using 3.5 for a single project myself but I will still plainly state the truth about the Python3 transition. It was a bad idea, for all the wrong reasons to benefit a rogue band of developers who believe since you aren't paying them- you as a community do not matter and should shutup and get to porting. I love Python but will eagerly embrace Pythonic language alternatives as more are released. In particular, I'd love to see a Pythonic Erlang variety similar to Elixir. Or better yet, just a concise, minimum featured version of Python without all the extra. Picking 1 string formatting method would suffice, the basics but done well, stable in feature-set like Go and compiled. Something similar to a Pythonic Lua would suit me and would be the ideal case for a Python-reboot. Making it a subset of Python2 would make a lot of sense. Lesson learned and bottom line is that we should overthrow all BDFLs. [0]http://learning-python.com/books/python-changes-2014-plus.html http://learning-python.com/books/python-changes-2014-plus.ht...
deleted 11y ago
[deleted]
jedberg 11y ago
Sadly I'm stuck using Python 2.7 until Amazon Lambda supports Python 3.
- jay_kyburz 11y ago
  Me also on Google App Engine!
- abrookewood 11y ago
  Yes, just found this out today. Rather annoying! I've logged a ticket about it for what it's worth ... even cited this article.
toyg 11y ago
Windows could be the first platform to ship Python3 without having ever shipped python2. Total clean slate, perfect opportunity, they could sell it as MS "aligning with the cloud" and offer something special -- if I could start and provision a Windows cloud instance from any python3 repl without having to bother with devops tool (Vagrant, Packer, Ansible and whatnot), I would switch tomorrow.
- Cyph0n 11y ago
  Wow. Now that would be something. Writing desktop apps in Python would actually become viable. You'd essentially only have to distribute your source code and dependencies instead of bloated binaries containing a Python interpreter.
  - jestar_jokin 11y ago
    I've found, building Python binaries for Windows, the interpreter and standard library takes up a negligible amount of space (a few MB). Most of the space was taken up by dependencies anyway, e.g. wxPython something like 15 MB! (I think I got it down to 7 MB using UPX to compress the DLLs.)
    - plq 11y ago
      UPX is not magic -- it compresses machine code and makes sure unpacking code is run every time the executable is loaded. So if you only care about the size of the binaries in transit, don't use UPX, just use eg NSIS with lzma compression. You'll probably end up with a smaller package this way.
      - nibnib 11y ago
        I agree, but UPX is magic.
      - ionelm 11y ago
        Speaking of that, there's a nice tool to build the installer for you: http://pynsist.readthedocs.org/en/latest/ http://pynsist.readthedocs.org/en/latest/
rjurney 11y ago
I recently started Python 4, which will be backwards compatible with 2.7. Submit your ideas as issues today! https://github.com/rjurney/python4 https://github.com/rjurney/python4
- maxerickson 11y ago
  Beware that Python is a trademarked name. I honestly can't tell if you are joking or think that using "Python 4" as the name of such a thing is a good idea (no way will the Python Software Foundation let you use their trademark, so if you are serious, you are just setting yourself up for hassles).
  - rjurney 11y ago
    Thanks for the feedback, I'll look into it. I think Python 4 is a good name because most Python users feel that Python 3 was a misstep, and never plan to move to Python 3.
    - Redoubts 11y ago
      You could call it TwentyEight.
    - collinmanderson 11y ago
      Yeah, "Python 4" sounds _less_ compatible with 2.7, not _more_ compatible. I like the "TwentyEight" name, or how about "Two4Evr". :)
username223 11y ago
It still blows my mind how badly the Python and Perl developers misunderstood their languages' roles. Many developers viewed them as Unix infrastructure like C, sed, and awk: a stable foundation upon which to build long-lasting programs. But the core devs got bored and decided to either break most things for very minor improvements (Python), or break everything to provide all things to all people (Perl). The Perl folks eventually admitted that version 6 was a separate language; we'll see how that turns out. The Python ones can't make the same move, since version 3 offers no major benefits/changes over version 2, so they simply have to continue the beatings until... everyone moves to version 3. What a colossal waste of time!
- rckclmbr 11y ago
  > But the core devs got bored and decided to either break most things for very minor improvements I think asyncio in python3.4 and async/await keywords in python3.5 is a gamechanger. It's hardly a minor improvement
  - kec 11y ago
    Well 1) it took us 5 years to get those features, 3.0 just broke shit and ran slowly for no discernible benefit to the end user. And 2) I know of no reason those features couldn't be implemented in Python2 other than "we don't want to, because otherwise few people will ever upgrade to 3"
    - rat87 11y ago
      Was upgrading even recommended before 3.3?
      - kec 11y ago
        That doesn't actually help the "py3k was a good idea" argument. 3.3 came out 4 years after 3.0. 4 years to become a reasonable choice is kind of pathetic, especially given the fact that python2 was put into bugfix-only mode 2 years after the 3.0 release
ksec 11y ago
And No love for Ruby. Sigh /Rant
markonen 11y ago
Python 3 : Python 2 :: IPv6 : IPv4
- collinmanderson 11y ago
  IPv6 came out 10 years before PY3, though I have more hope for PY3.

297 points by brettcannon 11y ago

buovjaga 11y ago

The 360 angle: http://py3readiness.org/ http://py3readiness.org/

mangeletti 11y ago
Thanks for the link. I found it shocking that Fabric was still not supported.
- ThatGeoGuy 11y ago
  I am skeptical of the link entirely. It says gevent does not support Python 3, yet if you look at the PyPI page [0], it says "Gevent runs on Python >= 2.6, Python >= 3.3, or PyPy >= 4.0.1 (but not PyPy3)". Is the lack of PyPy3 really worth saying Gevent doesn't run on Python 3 (the language, not CPython specifically)? Perhaps this website is out-of-date in some respects, and helps contribute to the confusion. On an unrelated note, a lot of people I have encountered claim Gevent as the reason they haven't switched yet. For now I guess such claims are shaky, assuming the PyPI page isn't false advertising. [0] https://pypi.python.org/pypi/gevent https://pypi.python.org/pypi/gevent
  - mangeletti 11y ago
    I think Gevent 1.1 added Python 3 support, and its final release was just a few days ago (03/05).
  - pingswept 11y ago
    The same is true for Supervisor. It has supported Python 3 for years.
    - brettcannon 11y ago
      Their PyPI page explicitly says otherwise: https://pypi.python.org/pypi/supervisor https://pypi.python.org/pypi/supervisor . It looks like there is support in their repository but not in any official release (yet).
      - pingswept 11y ago
        You are correct. But the setup.py for Supervisor noted support for Python 3 starting in May of 2014: https://github.com/Supervisor/supervisor/commit/ad5cd0849a5f7c04afe6837add63ca653b585540 https://github.com/Supervisor/supervisor/commit/ad5cd0849a5f... I don't know why PyPI isn't updated yet.
  - brettcannon 11y ago
    pyreadiness.org uses https://github.com/brettcannon/caniusepython3 https://github.com/brettcannon/caniusepython3 to figure out if a project supported Python 3. The issue is that gevent doesn't specify their support through a trove classifier on PyPI. There is a hand curated overrides file, though, that I just edited to list as supported (https://github.com/brettcannon/caniusepython3/blob/master/caniusepython3/overrides.json https://github.com/brettcannon/caniusepython3/blob/master/ca...). I don't know how often py3readiness.org updates, but the issue should resolve itself the next time they update the data on the site.
    - ThatGeoGuy 11y ago
      This is actually very informative. Combined with mangeletti's answer, it does explain the discrepancy. Thank you for sharing this. It's interesting (and also sad) that this tool has evolved up to version 3.3.0 over the years since we had Python 3.0.
    - neokya 11y ago
      I will take note and update it ;) It should update those overrides daily but seems like it is not.
levemi 11y ago
fabric is that lone holdout that went against all conventional wisdom and decided on a complete rewrite when a small few simple changes would have been enough. fabric's developer has made promises over the last few years for their rewrite to be beta ready and it's nowhere yet. I say that with all the appreciation in the world for the work that went into original fabric, which is a wonderful tool. Criticism may be harsh but it's not inaccurate. What's amazing is that the forks to bring fabric to python3 haven't really caught on and I think that's partly because fabric is something you do not use inside your application. It's used in deploy and configuration scripts. It being python 2 hasn't been a problem for most people since most distros and platforms ship with python 2 support. It's just that the people who want to stop writing python 2 for everything including their deploy scripts who are the most vocal and it's not a big enough group. The fabric dev basically has until platforms start to abandon python 2, and who knows when that will be, so maybe they have forever for their great rewrite.
- tclancy 11y ago
  Fabric is superseded by Invoke (https://github.com/pyinvoke/invoke https://github.com/pyinvoke/invoke), from the same developer. So other than that . . .
  - levemi 11y ago
    > Warning...While fully usable, Invoke is still pre-1.0 software and has no backwards compatibility guarantees until the 1.0 release occurs! Please make sure to read the changelog carefully anytime you upgrade! And if I recall, it's only half of fabric's feature set.

stared 11y ago

Plots using second since epoch as the x axis... nope. (I mean, if I do it then it is for internal plots only and still I am feeling lazy.)

dsil 11y ago

I really like the showing-his-work, via ipython/jupyter notebooks. Unfortunately it's behind an azureml login so it can't be directly linked.

chupapuma 11y ago
If you want to link to the Jupyter Notebook, you should be able to share the notebook in the gallery. http://aka.ms/py3winningnb http://aka.ms/py3winningnb or, if you want a less nice url, https://gallery.cortanaanalytics.com/Notebook/95a0e835f88b439ab0537c7b8e6daac5 https://gallery.cortanaanalytics.com/Notebook/95a0e835f88b43...

ihuman 11y ago

To add to this article, here is the Python 3 Wall of Superpowers. It is a list of the most popular packages on PyPI, and shows if they support Python 3. https://python3wos.appspot.com/ https://python3wos.appspot.com/

inanutshellus 11y ago

I program in python 2 because that's where /usr/bin/python takes me to. ;-)

ChrisArgyle 11y ago
Believe it or not, you don't even have to change your workflow to try out python 3. If you're on a Red Hat/Ubuntu-based system just add a '3' to everything (python3, pip3, pdb3, etc) edit: added relevant platforms
- inanutshellus 11y ago
  I've been bitten by Poe's Law[1], despite the winky. Blast! Edit: Really though, it's a problem of apathy. I'm supposed to care about python 3? Why? When I type "python" on the command line (and everyone else that doesn't care, which is most every "filthy casual", right?), I--and everyone else with a default install of Ubuntu and CentOS/RedHat--gets python 2. Fix that, and overnight you'll have massive python 3 uptake. In fact, you're suggesting I set myself up to be stuck with the problem Maven is in, which is that everyone has an "m2" repository even though they're onto Maven 3. I'm supposed to hardcode "3" into everything? C'mon. [1] https://en.wikipedia.org/wiki/Poe's_law https://en.wikipedia.org/wiki/Poe's_law
  - brettcannon 11y ago
    I believe both Ubuntu and Fedora have/are dropping Python 2 from the default install this year.
deleted 11y ago
[deleted]

rcarmo 11y ago

Well, I'd be happier if Pypy 3 were faster. As it is, I can get pretty decent speedups with 4.0 (2.7.x) but not for python3 code in my use cases...

mangeletti 11y ago
If Python Software Foundation would create a serious initiative to double (or more) the speed of cPython, specifically for Python 3.5+, I'd donate at least $100, and I'm sure there are a vast many other individuals (and companies) that would donate as well. In the meantime, my Python-related donations go to Django. I think that speed can't be treated like a niche feature (e.g., via PyPy, Cython, etc.) any longer; not with tools like Go out there.
- brettcannon 11y ago
  There's actually been a lot of work the past few months to speed up CPython 3.6. I expect there will be more news coming out of PyCon US on stuff related to this.
- rufugee 11y ago
  I wonder why Dropbox is focusing Pyston (https://github.com/dropbox/pyston https://github.com/dropbox/pyston) only on 2.7 atm. With PyPy supporting 2.7 very well, it'd seem a greater benefit to the community to target 3. That said, I'm sure there are specific things Dropbox needs to solve for 2.7 which PyPy doesn't do.
  - brettcannon 11y ago
    Pyston targets Python 2.7 because that's what they use on their servers. As for why Pyston over PyPy, http://blog.pyston.org/2015/11/24/pyston-talk-recording/ http://blog.pyston.org/2015/11/24/pyston-talk-recording/ has a nice video that mentions why (among other things).
  - gsnedders 11y ago
    Pyston has a goal of full C-API compatibility, unlike PyPy. Dropbox are almost certainly not trying to create the greatest benefit for the community, but rather the greatest benefit for themselves, and they have huge amounts of Python 2 code in production. As such, Python 2.7 with full C-API compatibility makes sense for them to focus on.

MrZongle2 11y ago

FTA: "In 3 months, Python 3 will be better supported than Python 2." This just seems to validate my choice to stick with Python 2 up until now.

lmm 11y ago
If you're an application developer rather than a library developer then yeah that may well have been the correct decision. But if you intend to maintain your application for more than 3 months then it's time to switch to Python 3 now.
- MrZongle2 11y ago
  "But if you intend to maintain your application for more than 3 months then it's time to switch to Python 3 now." No disagreement there. But I'm surprised at the downvotes I've received.

afarrell 11y ago

Ubuntu 16.04 LTS is planned to have only python3 installed by default

collinmanderson 11y ago
Super exciting.
iso-8859-1 11y ago
here is the bug https://blueprints.launchpad.net/ubuntu/+spec/foundations-x-python3-only https://blueprints.launchpad.net/ubuntu/+spec/foundations-x-...

declnz 11y ago

Interesting. Whilst it is slightly embarrassing how long it's taken, recently I feel that Python 3 conversion is gaining critical mass, and I now hope / expect these adoption lines to go non-linear in the coming year or so...

KaiserPro 11y ago

meh, there isn't (still) any reason to really jump onboard python 3, 2.7 is good enough for me the only real selling point is that strings are unicode by default. Unless I'm missing something python 3 just doesn't really seem to be worth the effort, yet. Can someone enlighten me?

mey 11y ago
When will support stop for Python 2.7? Once it stops being patched/supported, it represents a security risk (in my book). Additionally, eventually new libraries will also stop supporting 2.7, with the same issues as well as making development harder (or not as easy as your peers/competitors)
- brettcannon 11y ago
  The Python development team will cease supporting Python 2.7 in 2020. After that you will have to buy support from someone like Red Hat or Continuum Analytics.
  - mey 11y ago
    So I assume everyone will migrate in 2021 or 2022.
    - rjurney 11y ago
      I don't think people will migrate at all.
  - rjurney 11y ago
    Open source support is not a centrally governed entity. FOSS support for Python 2.7 will continue after 2020. You will certainly still have the option of paying someone for support.
    - brettcannon 11y ago
      Sure, there's a chance people will pick up the mantle and essentially fork Python 2.7 to do unofficial bugfix releases past 2020; as you pointed out, it's open source and people can do what they want. But my point is there is no guarantee that will happen, nor that those unofficial releases will be of quality either. RH and Continuum on the other hand will most likely have financial incentives to make sure any maintenance they do meets the needs of their paying customers and thus are of a certain level of quality. IOW one possible future is more of a certain than the other.

mindcrime 11y ago

Is anybody surprised by this? Everybody knew the transition was going to take a long time, and that it would be a gradual process. It may be that it's actually been even slower and more gradual than people expected, but by and large everything seems to be proceeding nicely.

godzillabrennus 11y ago
I don't think anyone expected a lengthy transition at the onset of the version 3 release. It's taken a long time and the 2.X releases that have come along since have helped make the transition easier by showing developers some of the benefits from version 3 releases.
- EliAndrewC 11y ago
  I was on the "Python 3000" mailing list while it was being planned, and the prevailing attitude seemed to be "it'll probably take 5 years before the community moves to Python 3". (That's paraphrased and not a direct quote, though I saw people say that sort of thing almost word for word a few times.) This was optimistic, but at least we see that the community is indeed gradually moving to Python 3, even if it's taking a few more years.
  - brettcannon 11y ago
    Technically the goal was a majority of new projects started using Python 3 in 5 years. Regardless, everyone knew it would take several years to reach a point like this.
    - mangeletti 11y ago
      Exactly, and I, for one, was using Python 3 for a new app, in production, in 2013, precisely 5 years after the release.
    - philipov 11y ago
      I switched from Perl to Python at version 3.4, and while it might be popular for people already invested in Python 2 to downplay the syntactic improvements, they were a big deal in convincing me to switch to Python as my go-to infrastructure language.

cdnsteve 11y ago

Who is this Microsoft? Loving this new community involvement.

BuckRogers 11y ago

It will have taken 8 years for Python3 supporting uploads to have outpaced Python2. If that's not lack of enthusiasm, I don't know what is. This is really a pitiful display. It's not a surprise though. This all stems back to the original reasons why Python3 was a bad idea. Some things to keep in mind regarding Python2/3. - Python3 is pure technical churn, nothing there is true technical innovation. They simply mixed the pot to their liking. Unicode is supported in Python2. - It is slower than Python2 for most people. Though there are crafty arguments out there that it's a wash. It's really not. - CPython3 was adopted to benefit the core development team, to make it easier to maintain. Not the community on the whole. The community has paid the price by doing a lot of unnecessary ports. - CPython3 was deliberately created to not support Python2 code even though modern VMs can easily support this. The CLR is a great example. They did it this way for their good, not for the community. - In most things in life, you'd always want to be using the latest supported version. That isn't the case here. It may still effectively "fail" with a permanent split. This migration is not even close to being completely in the books and won't be for another 10 to 20 years. So why punish yourself moving before it's in your best interests. The syntactic differences are so slight, it's extremely easy to switch to Python3 if it ever truly reaches Python's momentum (this article does not convey momentum holistically, that includes package downloads and the majority of employers using 3). - Related to the bullet above, almost all job opportunities are still Python2. - The ecosystem can't keep up, PyPy is still only production-ready on Python2. Python 3.2 support is essentially experimental by comparison. - Many changes and additions are being made and they aren't being vetted by the larger community. No significant userbase for Python3 has created this situation. Mistakes are being made and no one is around to speak up because the core devs don't care. - Python3 is feature-soup. There is now a new 4th and possibly 5th string formatting method in 3.6 incoming. Really jumped the shark on that one. See Mark Lutz's great insight on this topic and more.[0] - Downloads are still dramatically in Python2's favor, to this day. Judging from downloads, there's a ~10% community userate of Python3. - The bullet above means that the Python3 packages you do use are far less vetted and tested than the Python2 equivalent. - CPython3 was slopped together. The initial 3.0 release was mostly pure Python in effort to get it out the door. Many parts of the standard library that are written in C are slower than the modules used in the CPython 2.7 counterpart, to this day. It was not and is not being tested. The users are not there to test it either. - Community trust has been broken, I'm not sure anyone really believes another big break isn't incoming regardless of statements to the contrary. The core dev team is going to do what they want and you're going to like it, period. - Python3 zealots have done a lot of harm by not accepting valid criticism, and aggressively attacking those who do what is in their best interests (which we should all do, this should not just apply to the CPython core devs), and continue using Python2 all these years. Watch for downvotes instead of countering my points. - The 2020 date is a just a big political stunt and scare tactic. Code will continue working after 2020. As noted, it works better in CPython2 and PyPy today, and likely will in 2021 as well. - Python3 lives off of and is pushed by PSF propaganda. No way around it as there is no innovation involved. Which is what should determine if new technologies are adopted or not. - Usually when people make mistakes, such as Python3's existence, or the inability to mix Python2 and 3 code in the same VM- they go back and fix them. That has not happened with CPython3. - Even back in 2014 projects such as Pyston from GvR's employer (Dropbox), were Python(2)-only. It's still Python2 today, which says it all. All that said about this trainwreck, I'm in favor of getting back to a single major version of Python for the community. I'm using 3.5 for a single project myself but I will still plainly state the truth about the Python3 transition. It was a bad idea, for all the wrong reasons to benefit a rogue band of developers who believe since you aren't paying them- you as a community do not matter and should shutup and get to porting. I love Python but will eagerly embrace Pythonic language alternatives as more are released. In particular, I'd love to see a Pythonic Erlang variety similar to Elixir. Or better yet, just a concise, minimum featured version of Python without all the extra. Picking 1 string formatting method would suffice, the basics but done well, stable in feature-set like Go and compiled. Something similar to a Pythonic Lua would suit me and would be the ideal case for a Python-reboot. Making it a subset of Python2 would make a lot of sense. Lesson learned and bottom line is that we should overthrow all BDFLs. [0]http://learning-python.com/books/python-changes-2014-plus.html http://learning-python.com/books/python-changes-2014-plus.ht...

deleted 11y ago

[deleted]

jedberg 11y ago

Sadly I'm stuck using Python 2.7 until Amazon Lambda supports Python 3.

jay_kyburz 11y ago
Me also on Google App Engine!
abrookewood 11y ago
Yes, just found this out today. Rather annoying! I've logged a ticket about it for what it's worth ... even cited this article.

toyg 11y ago

Windows could be the first platform to ship Python3 without having ever shipped python2. Total clean slate, perfect opportunity, they could sell it as MS "aligning with the cloud" and offer something special -- if I could start and provision a Windows cloud instance from any python3 repl without having to bother with devops tool (Vagrant, Packer, Ansible and whatnot), I would switch tomorrow.

Cyph0n 11y ago
Wow. Now that would be something. Writing desktop apps in Python would actually become viable. You'd essentially only have to distribute your source code and dependencies instead of bloated binaries containing a Python interpreter.
- jestar_jokin 11y ago
  I've found, building Python binaries for Windows, the interpreter and standard library takes up a negligible amount of space (a few MB). Most of the space was taken up by dependencies anyway, e.g. wxPython something like 15 MB! (I think I got it down to 7 MB using UPX to compress the DLLs.)
  - plq 11y ago
    UPX is not magic -- it compresses machine code and makes sure unpacking code is run every time the executable is loaded. So if you only care about the size of the binaries in transit, don't use UPX, just use eg NSIS with lzma compression. You'll probably end up with a smaller package this way.
    - nibnib 11y ago
      I agree, but UPX is magic.
    - ionelm 11y ago
      Speaking of that, there's a nice tool to build the installer for you: http://pynsist.readthedocs.org/en/latest/ http://pynsist.readthedocs.org/en/latest/

rjurney 11y ago

I recently started Python 4, which will be backwards compatible with 2.7. Submit your ideas as issues today! https://github.com/rjurney/python4 https://github.com/rjurney/python4

maxerickson 11y ago
Beware that Python is a trademarked name. I honestly can't tell if you are joking or think that using "Python 4" as the name of such a thing is a good idea (no way will the Python Software Foundation let you use their trademark, so if you are serious, you are just setting yourself up for hassles).
- rjurney 11y ago
  Thanks for the feedback, I'll look into it. I think Python 4 is a good name because most Python users feel that Python 3 was a misstep, and never plan to move to Python 3.
  - Redoubts 11y ago
    You could call it TwentyEight.
  - collinmanderson 11y ago
    Yeah, "Python 4" sounds _less_ compatible with 2.7, not _more_ compatible. I like the "TwentyEight" name, or how about "Two4Evr". :)

username223 11y ago

It still blows my mind how badly the Python and Perl developers misunderstood their languages' roles. Many developers viewed them as Unix infrastructure like C, sed, and awk: a stable foundation upon which to build long-lasting programs. But the core devs got bored and decided to either break most things for very minor improvements (Python), or break everything to provide all things to all people (Perl). The Perl folks eventually admitted that version 6 was a separate language; we'll see how that turns out. The Python ones can't make the same move, since version 3 offers no major benefits/changes over version 2, so they simply have to continue the beatings until... everyone moves to version 3. What a colossal waste of time!

rckclmbr 11y ago
> But the core devs got bored and decided to either break most things for very minor improvements I think asyncio in python3.4 and async/await keywords in python3.5 is a gamechanger. It's hardly a minor improvement
- kec 11y ago
  Well 1) it took us 5 years to get those features, 3.0 just broke shit and ran slowly for no discernible benefit to the end user. And 2) I know of no reason those features couldn't be implemented in Python2 other than "we don't want to, because otherwise few people will ever upgrade to 3"
  - rat87 11y ago
    Was upgrading even recommended before 3.3?
    - kec 11y ago
      That doesn't actually help the "py3k was a good idea" argument. 3.3 came out 4 years after 3.0. 4 years to become a reasonable choice is kind of pathetic, especially given the fact that python2 was put into bugfix-only mode 2 years after the 3.0 release

ksec 11y ago

And No love for Ruby. Sigh /Rant

markonen 11y ago

Python 3 : Python 2 :: IPv6 : IPv4

collinmanderson 11y ago
IPv6 came out 10 years before PY3, though I have more hope for PY3.