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

Modifying the Python object model

lwn.net

Post reply on HN
Print view View original

21–30 of 45 posts

Re: Modifying the Python object model

#21

Post by neuland »

myWindoonn wrote: post #12
eximius wrote: post #4

Strange that Guido or the other CPython devs would object to adding caching (though, rereading, maybe they only objected to the tone it was presented in - which still seems a bit sensitive). I get favoring simple code over optimizations for more extreme cases like switching from dictionaries to arrays, but what essentially sounds like a tiny LRU cache for method dispatch seems like a clear win for everyone.

CPython has always strived to be a simple easy-to-read reference implementation of Python. They have rejected many patches over the decades which would have sped up various things at the expense of readability. People should not use CPython for speed; they should use PyPy for speed.

The article did mention that Instagram's code wasn't much faster on PyPy.

I agree with you though; one of the interesting and good things about Python is that it's a standard not an implementation. Although CPython is the the most popular by usage, PyPy and Cython are mainstream alternatives (or superset in the case of cython). There's also Jython, IronPython, Unladen Swallow, Grumpy, and others that I can't think of now. Some of those are defunct and others only are Python 2. But the point is, competition is good.

Re: Modifying the Python object model

#22

Post by eesmith »

mistrial9 wrote: post #20

things that immediately come to mind: - GVR founder, involved and opinionated.. argues against the TONE of the communication ! during a fairly ordinary technical discussion of language implementation. Certainly a trained compiler implementor can carefully measure and then show becnhmarks on function dispatch.. but the concern raised has to do with maintainability of the code, more than raw performance. Dont you see?…

> "argues against the TONE of the communication! during a fairly ordinary technical discussion of language implementation.

The LWN piece says "Guido van Rossum, who loudly objected to Shapiro's tone, which was condescending, he said".

That sounds appropriate.

In your experience, do most people presenting an 'ordinary technical discussion' use a condescending tone? If so, I'm glad I don't work in your organization.

Otherwise, when should people complain when speaker is disparaging most of the people in the audience, even if accidentally?

Re: Modifying the Python object model

#23

Post by xapata »

eximius wrote: post #4

Strange that Guido or the other CPython devs would object to adding caching (though, rereading, maybe they only objected to the tone it was presented in - which still seems a bit sensitive). I get favoring simple code over optimizations for more extreme cases like switching from dictionaries to arrays, but what essentially sounds like a tiny LRU cache for method dispatch seems like a clear win for everyone.

A version of attr-lookup caching is already added in 3.7. Thus Guido objected to the tone of, "I'm the first person to notice this!"

> Mark Shannon said that Python 3.7 has added a feature that should provide a similar boost as the method-lookup caching used in the experiment.

As I understand it, class-attribute dicts now carry a version number which increments on every mutation. The first method lookup gets cached and subsequent lookups check the version number to decide whether to invalidate the cache.

Re: Modifying the Python object model

#24

Post by bakery2k »

hodgesrm wrote: post #6
MR4D wrote: post #2

Great article worth reading for any hardcore Python fans. I’d also add that the comments on the LWN article are good too.

LWN.net articles are generally quite good. I signed up after reading an excellent summary of Spectre/Meltdown work from Greg Kroah-Hartmann. @all if you like this article please pay for a subscription. LWN.net deserves our support.

> LWN.net deserves our support.

Agreed. I subscribed a few months ago, in part because LWN.net seems to be the only publication providing significant coverage of the Python Language Summits.

Re: Modifying the Python object model

#25

Post by eximius »

myWindoonn wrote: post #11
MR4D wrote: post #3

I would love to see python get much faster. Seeing all the work on node and V8 has made me jealous to the point of wondering if someone would ever take the Python syntax and just put it on top of V8 or (preferably) LLVM. Yeah, I know that’s more work that I can imagine, but I can dream, right?

Language implementations don't work that way. However, the PyPy JIT has been around for over a decade and works wonderfully. It is a continuing disappointment that only about 1-2% of the Python community knows about and/or uses PyPy. (PyPy on LLVM has been a thing before. It requires constant upkeep and isn't very fast. I'm sure that the PyPy team would love to hear from prospective maintainers!)

I think PyPy is relatively unused because of the difficulty in using C extensions written for CPython. With PyPy, everything will work until suddenly things go horribly wrong or the library you need is just not available (numpy). The work they've done is fantastic, it's just a very difficult situation.

Re: Modifying the Python object model

#26

Post by eximius »

myWindoonn wrote: post #12
eximius wrote: post #4

Strange that Guido or the other CPython devs would object to adding caching (though, rereading, maybe they only objected to the tone it was presented in - which still seems a bit sensitive). I get favoring simple code over optimizations for more extreme cases like switching from dictionaries to arrays, but what essentially sounds like a tiny LRU cache for method dispatch seems like a clear win for everyone.

CPython has always strived to be a simple easy-to-read reference implementation of Python. They have rejected many patches over the decades which would have sped up various things at the expense of readability. People should not use CPython for speed; they should use PyPy for speed.

And it is simple. I haven't written C since college and it's mostly very readable, really great for exploration. In many ways, I agree that should be kept.

But memoizing lookups can be a single branch at the top of a few functions. We should strive to have our cake and eat it too, not simply declare we shouldn't bother.

Re: Modifying the Python object model

#27

Post by fijal »

eximius wrote: post #25
myWindoonn wrote: post #11

Earlier quoted context omitted.

Language implementations don't work that way. However, the PyPy JIT has been around for over a decade and works wonderfully. It is a continuing disappointment that only about 1-2% of the Python community knows about and/or uses PyPy. (PyPy on LLVM has been a thing before. It requires constant upkeep and isn't very fast. I'm sure that the PyPy team would love to hear from prospective maintainers!)

I think PyPy is relatively unused because of the difficulty in using C extensions written for CPython. With PyPy, everything will work until suddenly things go horribly wrong or the library you need is just not available (numpy). The work they've done is fantastic, it's just a very difficult situation.

FYI numpy both works these days and it's officially supported

Re: Modifying the Python object model

#28

Post by sandGorgon »

eximius wrote: post #25
myWindoonn wrote: post #11

Earlier quoted context omitted.

Language implementations don't work that way. However, the PyPy JIT has been around for over a decade and works wonderfully. It is a continuing disappointment that only about 1-2% of the Python community knows about and/or uses PyPy. (PyPy on LLVM has been a thing before. It requires constant upkeep and isn't very fast. I'm sure that the PyPy team would love to hear from prospective maintainers!)

I think PyPy is relatively unused because of the difficulty in using C extensions written for CPython. With PyPy, everything will work until suddenly things go horribly wrong or the library you need is just not available (numpy). The work they've done is fantastic, it's just a very difficult situation.

Which is why I'm very excited about Graal Python (https://github.com/graalvm/graalpython/blob/master/README.md)

It has the potential to bring an underlying framework which is built on industrial quality VM+JIT and it's primary goal is being compatible with the Scipy ecosystem at least ...Which is reason enough for unlimited optimism.

Re: Modifying the Python object model

#29

Post by xapata »

eximius wrote: post #26
myWindoonn wrote: post #12

Earlier quoted context omitted.

CPython has always strived to be a simple easy-to-read reference implementation of Python. They have rejected many patches over the decades which would have sped up various things at the expense of readability. People should not use CPython for speed; they should use PyPy for speed.

And it is simple. I haven't written C since college and it's mostly very readable, really great for exploration. In many ways, I agree that should be kept. But memoizing lookups can be a single branch at the top of a few functions. We should strive to have our cake and eat it too, not simply declare we shouldn't bother.

It ain't that easy (cache invalidation is hard). But they did it anyway, so, yeah, you can have your cake and eat it.

Re: Modifying the Python object model

#30

Post by carapace »

myWindoonn wrote: post #12
eximius wrote: post #4

Strange that Guido or the other CPython devs would object to adding caching (though, rereading, maybe they only objected to the tone it was presented in - which still seems a bit sensitive). I get favoring simple code over optimizations for more extreme cases like switching from dictionaries to arrays, but what essentially sounds like a tiny LRU cache for method dispatch seems like a clear win for everyone.

CPython has always strived to be a simple easy-to-read reference implementation of Python. They have rejected many patches over the decades which would have sped up various things at the expense of readability. People should not use CPython for speed; they should use PyPy for speed.

Yes, or Cython or Nuitka.

And keep an eye on the (poorly named) Grumpy project (Python compiled to Go.)

http://cython.org/

https://nuitka.net/

https://github.com/google/grumpy

Post reply on HN