Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Grumpy: Go running Python

opensource.googleblog.com

Post reply on HN
Print view View original

401–410 of 463 posts

Re: Grumpy: Go running Python

#401

Post by orf »

madgar wrote: post #396
orf wrote: post #314

Earlier quoted context omitted.

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.

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

C wasn't a one man band project (at least a two-man-band one at the start!) and neither was JavaScript. C also didn't have a formal specification for over 20 years (only an informal one) and JavaScript had a strong selection bias for interpreters that roughly conformed to the specification. But that didn't exactly help it, JS is/was notorious for differing implementations of browser APIs.

Each of them also has a strong need for a specification, as there are many differing compilers and interpreters. There are a few for Python but are specialized, the CPython interpreter is good enough for 90% of cases.

Re: Grumpy: Go running Python

#402

Post by orf »

pjmlp wrote: post #388
orf wrote: post #375

Earlier quoted context omitted.

Except without the great Python ecosystem and without great projects like Numpy/Scipy

Numpy/Scipy are only relevant to a minor set of computer users, and even then, there are alternatives like LANPACK and BLAS. Also Java and .NET ecosystems are just a little bigger than Python.

> there are alternatives like LANPACK and BLAS.

LANPACK + BLAS = scipy

> Numpy/Scipy are only relevant to a minor set of computer users..

> ... Java and .NET ...

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

#403

Post by ensignavenger »

loeg wrote: post #359
ensignavenger wrote: post #295

Earlier quoted context omitted.

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.

It seems like the 2.7 community is happy enough without the new features -- just need the bugfixes and continued backwards compatibility to keep that segment happy. From a new features perspective, the other reply's Placeholder is fascinating. (I haven't looked into it thoroughly yet.)

It is certainly interesting if it truly materializes. But it looks like the plan is to mostly backport stuff from py3- so py3 is still the future, with Placeholder getting some of those features eventually. And that is great from a legacy codebase perspective.

Re: Grumpy: Go running Python

#404

Post by whyrt12 »

dx034 wrote: post #367
robohamburger wrote: post #318

Earlier quoted context omitted.

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…

We try to use Python 3 at work but have to run Python 2 as well because there are still packages that weren't upgraded and it's too much working re-writing them all for no direct benefit. We also have third party vendors that only support Python 3 in experimental versions, and there not even recent versions (Bloomberg is a great example). I really like Python3 features, but the pain of using them drives me towards us…

Do you do data science?

Re: Grumpy: Go running Python

#405

Post by pjmlp »

orf wrote: post #402
pjmlp wrote: post #388

Earlier quoted context omitted.

Numpy/Scipy are only relevant to a minor set of computer users, and even then, there are alternatives like LANPACK and BLAS. Also Java and .NET ecosystems are just a little bigger than Python.

> there are alternatives like LANPACK and BLAS. LANPACK + BLAS = scipy > Numpy/Scipy are only relevant to a minor set of computer users.. > ... Java and .NET ... 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.

> LANPACK + BLAS = scipy

Thanks, I already knew that.

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

Hence we are back at Scala, Clojure, F#, enjoying the respective AOT/JIT native code compilers, and integrating with that highly-optimized C/Fortran code.

Re: Grumpy: Go running Python

#406

Post by orf »

pjmlp wrote: post #405
orf wrote: post #402

Earlier quoted context omitted.

> there are alternatives like LANPACK and BLAS. LANPACK + BLAS = scipy > Numpy/Scipy are only relevant to a minor set of computer users.. > ... Java and .NET ... 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.

> LANPACK + BLAS = scipy Thanks, I already knew that. > 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. Hence we are back at Scala, Clojure, F#, enjoying the respective AOT/JIT native code compilers, and integrating with that highly-optimized C/Fortran code.

> Scala, Clojure, F#

Functional languages. The "year of Linux on the desktop" of programming languages. Also none of those look like pseudocode (Scala does if you ignore bits and squint).

Re: Grumpy: Go running Python

#407

Post by xigency »

ot wrote: post #60

There's no mention of whether Grumpy passes the CPython test suite. Until it doesn't, it's not a Python runtime, it's a compiler for a language with Python-like syntax. Compilers like this, from almost-Python to say C/C++, have existed for a while: Cython, Shedskin, Nuitka are some examples.

> Until it doesn't, it's not a Python runtime...

True Python runtimes fail the CPython test suite. They have some work to do!

Re: Grumpy: Go running Python

#408

Post by devy »

lomnakkus wrote: post #282
devy wrote: 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++.)

For your narrow minded understanding of what a programming language specification is only: https://en.wikipedia.org/wiki/Programming_language_specifica...

You can say it's imprecise or lack of ratification from one or many international organization(s), but you cannot say it doesn't exist. End of story.

Re: Grumpy: Go running Python

#409

Post by BuckRogers »

guitarbill wrote: post #330
BuckRogers wrote: post #322

Earlier quoted context omitted.

Go compiles down to native code (x86, ARM assembly etc). That's what Grumpy code generates as well but it still needs to be maintained in the original Python2 or Go (depending on whatever your original source is). What I'm suggesting is that Python3 is jettisoned and Grumpy takes the forsaken throne that Python left behind. One thing is clear with all these new compilers/runtimes, you want to be writing Python2 synta…

> you want to be writing Python2 syntax because that's where all the action is. > This is Python3 as most of us wanted it to be. > Valid Python2 is Grumpy already. > It compiles existing Python2 AND offers a legitimate upgrade from CPython at the same time. > As far as all of the lost C extensions? You won't need them None of the statements are true. You seem to be very confused what Grumpy can and can't do, and what…

Citations needed for your assertion on each point being false.

Grumpy proves Python2 is where the action is at. Everyone wanted a speed improvement with a new Python, that's the ultimate carrot.. instead Python3 was and still is in some ways slower than 2. Other than exec, eval and C-extensions, Python2 is valid Grumpy.

You didn't provide any reasoning or proof that my points, which were just reiterated, were false. If you're going to "port" anywhere from Python2, removing C extensions (which no language should have to be dependent upon anyway, so it's an improvement) and exec/eval usage is a bigger win than Python3.

The future of Python is what the users decide, not what the PSF decided. I recognize there's a lot of confusion and propaganda surrounding that. This is open source, not top-down control.

Re: Grumpy: Go running Python

#410

Post by xapata »

xapata wrote: post #271
trotterdylan wrote: post #169

Earlier quoted context omitted.

Heh, I came across the namedtuple exec thing the other day when I was trying to get the collections module working :\ namedtuple will have to be implemented differently. I think it can be accomplished by defining the class with type()? Maybe with a metaclass...

You won't get exact compatibility, but a metaclass implementation would give almost all the features. I can't remember what exactly you give up, but I did that once and I lost some introspection friendliness.

Nevermind, all you need is type(). Metaclass unnecessary.
Post reply on HN