Live data from Hacker News

Grumpy: Go running Python

opensource.googleblog.com

281–290 of 463 posts

Re: Grumpy: Go running Python

#281
post #203

Earlier quoted context omitted.

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).

>(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.

It's true, but moving our huge codebase to Python 3 is a big undertaking. We're making progress towards it by using Python 3 constructs for new files, etc. For my personal projects I'm already in the process of moving over.

Re: Grumpy: Go running Python

#282
post #152

Python needs a new runtime. This talk shows how bad of shape it's really in. https://www.youtube.com/watch?v=qCGofLIzX6g&list=PLRdS-n5seL... Basically, the language doesn't have a "spec" per-se. The language is whatever the defacto CPython implementation happens to do within it's giant eval loop. Another great talk about CPython internals: http://pgbovine.net/cpython-internals.htm

> Basically, the language doesn't have a "spec" per-se. It does[1]. And process of improving it is called PEP[2]. [1]: https://docs.python.org/ [2]: https://en.wikipedia.org/wiki/Python_(programming_language)#...

Uh, what? Claiming that your [1] is in any way a specification for the language is utterly absurd. It's far too vague. (Compare to even an IETF RFC, and you'll see what I mean. If you want to compare to a real language spec, compare to ISO C++.)

Re: Grumpy: Go running Python

#283

Earlier quoted context omitted.

Is there not a single namedtuple in the entire Google codebase? That's strange :o

Are namedtuples that popular? They always felt awkward to me. If some temp variable with multiple values inside a loop, I either use normal tuple or a dict. If passing data around a dict or a real class. I never got the huge win from namedtuple?

We use them extensively in our API client code to pass back immutable, well-defined data structures. Dictionaries and classes are mutable and then each layer of code tends to sloppily change them however is convenient, meaning the underlying data can end up being represented differently in different code flows.

Namedtuples are a way to preserve the data unless the consuming code _really_ wants to change it, which is sometimes legitimate.

I'm not totally sold, as in some cases dictionaries or classes would add nice value. But namedtuples have a rigidity that makes you think twice before tampering with retrieved data.

Re: Grumpy: Go running Python

#284

Does anyone know if there is an easy way to get involved in open source projects like this? The readme mentions adding PRs, but as someone that doesn't have much experience working with open source projects like this, I don't even know where to begin. It sounds like an incredible learning opportunity though.

"much" could mean anything, from "what's a PR?" https://guides.github.com/activities/hello-world/

to "what's good etiquette for contributing to open source projects?", I'd say: add as much information as possible to your PR, why it does what it does, how it does it, etc.

Re: Grumpy: Go running Python

#285

Earlier quoted context omitted.

> Amusingly, it runs Python 2.7, even though this project started long after Python 3.x came out. Basically, we needed to support a large existing Python 2.7 codebase. See discussion here: https://github.com/google/grumpy/issues/1 > It's a hard-code compiler, not an interpreter written in Go. That implies some restrictions, but the documentation doesn't say much about what they are. PyPy jumps through hoops to make a…

> I'll update the README to make note of them. I managed to run into 2 trying to build a 5 line program :-) $ cat t.py; ./tools/grumpc t.py > t.go;go build t.go;echo '----';./t import sys print sys.stdin.readline() ---- AttributeError: 'module' object has no attribute 'stdin' $ $ cat t.py ;./tools/grumpc t.py c = {} top = sorted(c.items(), key=lambda (k,v): v) Traceback (most recent call last): File "./tools/grumpc",…

Ugh, sorry about that. There's a couple issues here:

1. Lambda tuple args are not yet supported -- I actually didn't know that was a thing :\ -- https://github.com/google/grumpy/issues/17

2. Even if that worked properly, sorted() is not yet implemented: https://github.com/google/grumpy/issues/16

Re: Grumpy: Go running Python

#286

Earlier quoted context omitted.

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.

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 d…

>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.

Re: Grumpy: Go running Python

#287
post #248

Earlier quoted context omitted.

Python 2.7 is EOL in 2020. Make of that what you will :/

The community will fork the 2.7 codebase and continue to support it, even if Python.org EOLs it.

It looks like all Python 2.8 is missing is a new name:

https://www.naftaliharris.com/blog/why-making-python-2.8/

Re: Grumpy: Go running Python

#288
post #225
post #215

Earlier quoted context omitted.

Just because the site is popular doesn't mean the codebase is big. It's a simple site. I could probably write YouTube in Go in an afternoon and I don't even know Go.

You could perhaps write a feature-bare clone. Here's some basic features: - search (the various search pages) - trending - channels - subscription - video uploads - history - comments - likes - upload - video editing (most of this is in browser, but still) - livestream - video analytics - payment and ad management - video comment review and moderation - translation - captioning - video replication, multiscaling, cach…

> resolution management based on network speed

Not so much a feature of YouTube as it is a feature of HLS/Dash... but yes, it means you've gotta transcode the source video into multiple different bitrates.

Re: Grumpy: Go running Python

#289

Earlier quoted context omitted.

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.

A huge confounding factor: newer Py3 codebases are more likely to be built with newer pipeline tooling like devpi (to cache PyPI downloads), wheel (to cache locally-built packages), and Docker (which caches all the things). Our legacy Python 2 build pipelines that we're actively moving off of hit PyPI far more often than our Py3 processes.

>A huge confounding factor: newer Py3 codebases are more likely to be built with newer pipeline tooling like devpi (to cache PyPI downloads), wheel (to cache locally-built packages), and Docker (which caches all the things).

Maybe in your case, but from what I've seen, I seriously doubt use of Docker or Devpi makes any dent in newer Py3 codebase dependency downloads. Besides, tons of new codebases for greenfield projects are still done in 2.x Python.

Not sure how it is in scientific computing area, but for enterprise/web apps, any company that has legacy 2.x code and libs in production (which is most of them) will continue to write new parts (including new projects) in 2.7 for compatibility with their Python production setup.

3.x is either from companies that didn't already have significant 2.x Python code in production (generally newer companies that for some reason went with Python instead of Node or Go that the cool kids use) or new programmers that just get started and start with 3.x.

Re: Grumpy: Go running Python

#290

Earlier quoted context omitted.

Hmm, numpy isn't pure python, is it? If I read correctly this only works with pure python.

By volume numpy is mostly assembler written to the Fortran ABI (it's a LAPACK/BLAS-etc wrapper).

Are you sure you aren't mistaking numpy for scipy?
Post reply on HN