Live data from Hacker News

Grumpy: Go running Python

opensource.googleblog.com

311–320 of 463 posts

Re: Grumpy: Go running Python

#311

Earlier quoted context omitted.

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…

> A single developer can download 50 deps across his codebase, and update them to later versions 2-3 times a year.

As if individual developers are the reason behind the bulk of the downloads. I wonder how many downloads Travis alone counts for?

Your hate of Python 3 in every discussion about it is frankly baffling.

Re: Grumpy: Go running Python

#312
post #258

Earlier quoted context omitted.

This comment made me wonder what you consider to be a complex site.

Not a video host with comments. That's practically CRUD. A very solved problem.

But, really, what site cannot be boiled down to practically CRUD? That does not help us understand what you believe is a complex site.

Is this supposed to be some kind of no true Scotsman?

Re: Grumpy: Go running Python

#313
post #236
post #66

Earlier quoted context omitted.

> Nobody uses that stuff in production code Nobody uses the features of Python which make it a dynamic language? Google must write some really weird Python if their compiler is that strict.

Anybody running Django uses this. It uses the pattern of specifying plugins as class paths in strings in the config, which are then looped over and instantiated at runtime. Frameworks do lots of such dynamic tricks in order to provide nice DSLs for building apps.

'exec' and 'eval'? No it's not, the importlib machinery is used (which doesn't just eval(read('import.py')))

Re: Grumpy: Go running Python

#314
post #152

Earlier quoted context omitted.

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

CPython is the spec (or really more the CPython test suite). Just like the Ruby MRI. It's a simple, plain interpreter without many frills, and to add or remove a feature you have to submit a PEP which goes through a specification process.

Python started as a one-man-band project and of course didn't have a specification.

Re: Grumpy: Go running Python

#315
post #46

For those who are interested, I've used grumpy to compile the following Python code and placed it at https://play.golang.org/p/YP1SP7WsdR . (Note the playground can't run this, it just had convenient formatting support for Go; the generated source wasn't 100% gofmt compliant.) class Test(object): def __init__(self, value): self.value = value def method(self): print(self.value) class Test2(Test): pass t = Test("hello"…

Interesting to note that `print()` is supported out of the box--no need to `from __future__ import print_function`.

Sure, but that works without from `__future__ import print_function` in Python2 as well.

But it gives different output; the print() prints a tuple whereas the function print() prints a newline.

Also compare print(1) and print(1,2) with and without the __future__ import.

Re: Grumpy: Go running Python

#316
post #223
post #219

Earlier quoted context omitted.

Julia? Look, I enjoy playing with Julia, but have you actually used it? Because most of the people I meet who turn up their nose at Python and say nice things about Julia haven't ever used Julia. It's got great potential but has some major gaps and warts, and is just plain dog shit slow for certain things compared to SciPy, which, you may not be aware, is basically C and Fortran code wrapped in Python API.

I do follow Julia development and I am aware that it isn't quite there, but at least their community does embrace JIT compilation, not like Python that PyPy is just yet another project, ignored by the reference implementation. > SciPy, which, you may not be aware, is basically C and Fortran code wrapped in Python API. Which for me personally means, that I would rather C and Fortran directly or better yet, a C++, .NET…

> Which for me personally means, that I would rather C and Fortran directly or better yet, a C++, .NET or Java binding to them.

Being able to describe things with a syntax that looks almost like pseudocode and runs highly-optimized C/Fortran code to do heavy lifting has huge, huge advantages.

Re: Grumpy: Go running Python

#317
post #222
post #168

Earlier quoted context omitted.

Because they want to get off of Python completely, and forever. They're not looking for speed, they're looking to ditch the liability of supporting Python and its ecosystem.

Yeah, they didn't at all say that.

Of course, that doesn't necessarily mean it is not true. There are many reasons why Google may not want to reveal long-term plans so explicitly.

It's clear that existing Python codebases will be maintained for the foreseeable future – there would be no reason to build this otherwise – but this may signify a shift away from Python for new extensions to the project, as this now makes it possible to integrate Go packages with relative ease.

Re: Grumpy: Go running Python

#318
post #251

I can't help but see this balkanization of Python as a sign that the core language is falling apart. How many interpreters are there now? And how many of them have even close to 100% compatibility with Python 2.7 or 3.N? Guido has lost control of the language, but has he's still officially the BDFL there's no real standardization body. His stubborn view on functional mechanisms have held the language back syntactical…

GVR, the PSF and the core dev team overestimated their influence. They still truly believe the majority will come around to Python3. I agree with your sentiments and balkanization is the right word. Guido won't even read these comments. He thinks it's all some unjust slander and nonsense that will be forgotten in 3 years. :) It is a good time to jump off the Python train in general, and I say that as someone invested…

Both my workplace and the one big open source project I use homeassistant all use python 3. Do you have any data to backup python 3 adoption being a failure? I know it was certainly painful for many years.

As a python 3 user everything seems fine on my end. Though 3 has its own new warts. They are smaller and more forgivable warts for now but its probably not a good sign.

I do agree the direction python is heading is not very interesting anymore but that doesn't mean its dead or useless now.

Re: Grumpy: Go running Python

#319
post #258

Earlier quoted context omitted.

This comment made me wonder what you consider to be a complex site.

Not a video host with comments. That's practically CRUD. A very solved problem.

Well, go on then, why spend just an afternoon when you could spend 5 whole days. Make a YouTube that's 10x better, host it from your closet and watch the megabucks roll in as you take down Google.

Re: Grumpy: Go running Python

#320
post #48

- Amusingly, it runs Python 2.7, even though this project started long after Python 3.x came out. - 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 all of Python's self modification at run-time features work, complicating PyPy enormously. Nobody uses that stuff in production code,…

I was in second year of college and the Python 2 vs Python 3 was a couple of years running. Is this fight -still- not resolved? I'm not a python developer so I'm out of the loop.
Post reply on HN