10 ms·

>- Amusingly, it runs Python 2.7, even though this project started long after Python 3.x came out. Python 2.7 is what's running at Google. Not really surprisi

• quotemstr 10y ago
  > Python 2.7 is what's running at Google. Not really surprising they're looking at this considering the fast approaching end of (core dev) support for Python 2.7. I'd prefer that all new Python tools that need to support 2.x also support 3.x. It's an additional development cost, but IMHO, a worthwhile investment in the future.
  • BuckRogers 10y ago
    Python3 was never the future of Python. It never got over the hump all new languages need to if attempting to reach relevance. It's likely code using lots of C-extensions will continue with CPython2 and new code will be written in Grumpy (pure Python2).
    • cdelsolar 10y ago
      That is pretty ridiculous. Pretty much all major libraries are Python 3 compatible and everyone is writing Python 3 (or should be). (Yes, I'm still on Python 2 but moving soon).
      • quotemstr 10y ago
        I've been writing Python 3 for years.
      • coldtea 10y ago
        >and everyone is writing Python 3 (or should be) You'd be surprised. If anything, the numbers show the opposite. The vast majority of Python codebases, legacy or new, are 2.7 or older.
        • dbaupp 10y ago
          Which numbers? People keep saying things like that, but things like the Python 3 Wall of Superpowers https://python3wos.appspot.com/ https://python3wos.appspot.com/ don't seem to support it. Do you have something more concrete?
          • coldtea 10y ago
            The "Wall" is just numbers for Python3, without context for how it compares to Python 2. For 2.7 Pypy reported 419,227,040 downloads for 2016. At the same time, for ALL 3.x versions combined (up to 3.6) there are just: ~52 million downloads. That's 1/8th of the Python 2 downloads.
            • LeifCarrotson 10y ago
              Given that there are only 7.5 billion humans on the planet, and that rather significantly fewer than 1 in 20 people are PyPy-using developers, perhaps those numbers should be taken with a grain of salt? The message I would take from those statistics is that needing a fresh download of Pypy is less common among 3.x users than among 2.7 users, who apparently needed to reinstall from the web at least a few times a day during 2016.
              • gsnedders 10y ago
                It should be PyPI rather than PyPy in the parent, FWIW.
                • coldtea 10y ago
                  Oops, mea culpa.
              • coldtea 10y ago
                >Given that there are only 7.5 billion humans on the planet, and that rather significantly fewer than 1 in 20 people are PyPy-using developers, perhaps those numbers should be taken with a grain of salt? Those are not downloads of PyPi, but of packages. It's not like "number of downloads == number of individual developers". Those are packages, including package updates. A single developer can download 50 deps across his codebase, and update them to later versions 2-3 times a year.
      • BuckRogers 10y ago
        That's top-down change from the PSF/core dev team and some major library developers added dual 2/3 support. The users never arrived and it'll be 10 years Python3 has been available next December. I'd like to unify Python again but we as users didn't break it either. 10 years any reasonable person in charge would hang it up or change course. Grumpy is pretty much what most everyone would actually want out of a new Python and may have arrived just in time.
        • lima 10y ago
          > some major library developers added dual 2/3 support > The users never arrived That's the way it used to be a few years ago - it changed a lot the last few years. Pretty much all libraries are ported and many new libraries are Python 3-only. asyncio is nice. All Python devs I personally know moved to Python 3. Porting is a lot less painful than it used to be.
          • BuckRogers 10y ago
            Gevent is nice. AsyncIO is terrible[0]. [0]http://lucumr.pocoo.org/2016/10/30/i-dont-understand-asyncio/ http://lucumr.pocoo.org/2016/10/30/i-dont-understand-asyncio...
            • orf 10y ago
              It's actually ridiculously nice, especially with the new async/await constructs.
          • dismantlethesun 10y ago
            Python 3 is largely cross-compatible with Python 2. If you're not working with unicode, not reliant on perfect floating point division, and not using aysncio, then chances are what you produce will work just fine on Python 2.
      • spanishgum 10y ago
        My python course at uni focused on python3. We talked about differences and toyed with both interpreters, but ultimately wrote all projects and assignments in 3. I'm sure this is the case for students at other schools too.
      • kj01a 10y ago
        >(Yes, I'm still on Python 2 but moving soon). I'm like really new to programming and I'm still just learning the basics, but I see this little addendum a lot from people who say everyone should be writing Python 3.
        • kstrauser 10y ago
          Here, I'll give you a counterexample: We're on Python 3 for all new stuff, and are migrating the old whenever we can.
        • wiz21c 10y ago
          me too. I've migrated a big project from 2 to 3 two years ago. And let's get this straight : innovation happens on python 3. So staying on 2 would feel like riding a dead horse. I know I did the right thing. And if Google can make an interpreter for 2, then sooner or later, one for 3 will pop up. Since Google made some restrictions on what Grumpy supports from python 2, I'm sure someone somewhere will be able to do the same stuff for three.
        • joatmon-snoo 10y ago
          Python 2.7 is EOL in 2020. Make of that what you will :/
          • loeg 10y ago
            The community will fork the 2.7 codebase and continue to support it, even if Python.org EOLs it.
            • xrange 10y ago
              It looks like all Python 2.8 is missing is a new name: https://www.naftaliharris.com/blog/why-making-python-2.8/ https://www.naftaliharris.com/blog/why-making-python-2.8/
            • ensignavenger 10y ago
              I can see "the community" doing security fixes, maybe some bug fixing and a few back ports, but so far I havn't seen much effort from any community to bring active development of new features.
  • packetized 10y ago
    Well, the difference here is that Google seems to be looking at Golang as the future for their internal tooling currently implemented in Python 2.x, instead of Python 3.x. I'm curious to know how much additional work might be necessary for this to support 3.x, but it doesn't sound like that's part of their use case.
  • shanemhansen 10y ago
    While python2 may be the past, I think that for many python3 is not the future.
    • lima 10y ago
      Highly depends on the use case. Python 3.5 with uvloop+sanic can be faster than node.js without any JIT: https://github.com/channelcat/sanic#benchmarks https://github.com/channelcat/sanic#benchmarks
      • pjmlp 10y ago
        Still slower than OCaml, Haskell, Java or .NET.
        • mathw 10y ago
          Mmm, "faster than node.js" isn't a great benchmark out in the wide world. Although node.js being as fast as it is remains an astonishing thing.
          • quotemstr 10y ago
            Who cares about the speed of the interpreter? The interpreter's job is to orchestrate high-performance components written in some high-performance language. If your interpreter is dominating execution time, you should move some of your logic to native code.
            • pjmlp 10y ago
              Better not use an interpreter in first place, rather a language with REPL that allows compilation straight to native code.
              • quotemstr 10y ago
                Why? Native code is costly: machine code generally has a much bigger footprint than interpreter bytecode. In some cases, interpreted code can be faster due to cache effects and reduced IO load making it faster to be smaller.
  • koffiezet 10y ago
    From Google's POV, Go is the future, not Python 3, they created it for this reason. As mainly a sysadmin these days, I tend to agree with them for their use-case. For deployment, performance and overhead, Go is great for system tools, which is reflected in the new toys in the "sysops" toolbox. Pretty much every-one of them is written in Go these days, where that used to be Python or for a brief period Ruby or C/C++ for the more performance sensitive stuff.
• tedmielczarek 10y ago
  Given the failure of their unladen-swallow work to make it into CPython, I think Google is probably tired of trying to make Python faster. Some of their stated goals with Go were to be a faster, compiled Python, so this makes a lot of sense for their use case. They face the choice of fixing all their existing Python code to run in Python 3 (which won't make anything faster), or just porting everything to a different language. They chose the latter, and this lets them incrementally convert Python code to Go. I don't know that this makes sense for anyone but Google, just like Hack probably doesn't make sense for most PHP development that's not at Facebook.
  • derefr 10y ago
    > I don't know that this makes sense for anyone but Google I'm not sure; as a Go developer, I kind of like the idea of having access to the Python library ecosystem from Go, without being forced to create an IPC bridge and building up the requisite release-management and deploy-time goop. Plus, I'm just not a Python developer; in the case where the only library that exists to do something is written in Python, I'd much rather write Go that calls that Python library than Python that calls that Python library.
    • kibwen 10y ago
      > I kind of like the idea of having access to the Python library ecosystem from Go I'd like to see an example of this, because from the blog post I get the impression that this mostly allows accessing the Go ecosystem from Python, rather than the other way around. For example, how would Python classes be handled from Go?
      • jwillp 10y ago
        embed a cpython interpreter into the Go runtime as an embedded interpreter?
    • SureshG 10y ago
      IIUC, it's not about accessing python libs from go. It's for accessing go libs from your python program and transpiling that python code to go source and compile it with go tool chains. Eg: python code (from blog post) from __go__.net.http import ListenAndServe, RedirectHandler handler = RedirectHandler('http://github.com/google/grumpy', 303) ListenAndServe('127.0.0.1:8080', handler)