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

A tail calling interpreter for Python (already landed in CPython)

blog.reverberate.org

Post reply on HN
Print view View original

31–40 of 93 posts

Re: A tail calling interpreter for Python (already landed in CPython)

#31

Post by kqr »

riffraff wrote: post #21
ehsankia wrote: post #4

Earlier quoted context omitted.

Guido is no longer BDFL though, it's the steering committee that decides.

the steering committee seems way less conservative than Guido, right? Looking at python from the outside a lot of changes since GvR stepped down seem like stuff he'd not have been fond of.

I think this is a change longer in the making than that. Back when I started working with Python in the mid--late 2000s, the Zen was holy and it seemed very unlikely to ever see multiple ways to do "one thing".

The Python community has since matured and realised that what they previously thought of as "one thing" were actually multiple different things with small nuances and it makes sense to support several of them for different use cases.

Re: A tail calling interpreter for Python (already landed in CPython)

#32

Post by pinoy420 »

rpcope1 wrote: post #3
thunkingdeep wrote: post #2

This does NOT mean Python will get Tail Call Optimization, as Guido cannot be shown The Light, and has decided.

That's probably one of the more frustrating things about Python. Each release it gets all sorts of questionable new syntax (including the very strange pattern matching "feature" that kind of sucks compared to something like Erlang or Scala), but we never get real useful quality of life improvements for basic functional programming like TCO or multi line lambdas

The choice of “unique” verbs is weird too. Case match. Try except?

Re: A tail calling interpreter for Python (already landed in CPython)

#33

Post by pinoy420 »

saagarjha wrote: post #7
jgalt212 wrote: post #5

Earlier quoted context omitted.

The utility value of multi-line lambdas is real, but the readability of these is terrible. And Python prizes readability. So you know where this initiative will end up.

Nothing more readable than a triply-nested list comprehension on an object that exists only to vend its __getattr__ for some unholy DSL

Annoying. Because it “compiles” to less optimal code than writing it explicitly.

Re: A tail calling interpreter for Python (already landed in CPython)

#34

Post by pinoy420 »

pansa2 wrote: post #24
riffraff wrote: post #21

Earlier quoted context omitted.

the steering committee seems way less conservative than Guido, right? Looking at python from the outside a lot of changes since GvR stepped down seem like stuff he'd not have been fond of.

Any examples? The biggest change since Guido stepped down has been the addition of pattern matching, which he was strongly in favour of. Moreover, Guido is in favour of ongoing addition of major new features (like pattern matching), worrying that without them Python would become a “legacy language”: https://discuss.python.org/t/pep-8012-frequently-asked-quest...

Pattern matching seems like a cool feature that was added just because it was cool. I think the syntax is really odd too - apparently to “be pythonic”. I really see no use for it other than to “look smart”. The fact that case match (switch case is a much better description) is expanded to practically a huge if else is disturbing. Similarly the walrus operator. Other than an answer to “what is a new feature of python that you like” interview trivia question, really, who has actually used it?

Re: A tail calling interpreter for Python (already landed in CPython)

#35

Post by tomsmeding »

dataflow wrote: post #30
dragonwriter wrote: post #26

Earlier quoted context omitted.

By that standard, any optimization that changes scaling in any dimension changes semantics, which, well, I’m not saying its wrong, but I would say it is exactly what people looking for optimization want.

> By that standard, any optimization that changes scaling in any dimension changes semantics That doesn't follow. This isn't like going from driving a car to flying an airplane. It's like going from driving a car to just teleporting instantly. (Except it's about space rather than time.) It's a difference in degree (optimization), yes, but by a factor of infinity (O(n) overhead to 0 overhead). At that point it's not u…

Modern C compilers are able to transform something like this:

for (int i = 0; i To:

a += n * (n+1) / 2;

Is this an optimisation or a change in program semantics? I've never heard anyone call it anything slse than an optimisation.

Re: A tail calling interpreter for Python (already landed in CPython)

#36

Post by pinoy420 »

tomsmeding wrote: post #35
dataflow wrote: post #30

Earlier quoted context omitted.

> By that standard, any optimization that changes scaling in any dimension changes semantics That doesn't follow. This isn't like going from driving a car to flying an airplane. It's like going from driving a car to just teleporting instantly. (Except it's about space rather than time.) It's a difference in degree (optimization), yes, but by a factor of infinity (O(n) overhead to 0 overhead). At that point it's not u…

Modern C compilers are able to transform something like this: for (int i = 0; i To: a += n * (n+1) / 2; Is this an optimisation or a change in program semantics? I've never heard anyone call it anything slse than an optimisation.

Amazing it can do that. How does it work?

That definitely does seem to change its semantics to me. I am not a c expert but this surely has problems the previous one doesn’t?

Re: A tail calling interpreter for Python (already landed in CPython)

#37

Post by riffraff »

pansa2 wrote: post #24
riffraff wrote: post #21

Earlier quoted context omitted.

the steering committee seems way less conservative than Guido, right? Looking at python from the outside a lot of changes since GvR stepped down seem like stuff he'd not have been fond of.

Any examples? The biggest change since Guido stepped down has been the addition of pattern matching, which he was strongly in favour of. Moreover, Guido is in favour of ongoing addition of major new features (like pattern matching), worrying that without them Python would become a “legacy language”: https://discuss.python.org/t/pep-8012-frequently-asked-quest...

I was thinking of the walrus operator, various f-string changes, relenting on the "GIL removal must not cost performance" stance (although"covered" by other improvements), things like that.

I don't follow python closely so it may 100% be stuff that GvR endorsed too, or I'm mixing up the timelines. It just feels to me that python is changing much faster than it did in the 2.x days.

Re: A tail calling interpreter for Python (already landed in CPython)

#38

Post by riffraff »

kqr wrote: post #31
riffraff wrote: post #21

Earlier quoted context omitted.

the steering committee seems way less conservative than Guido, right? Looking at python from the outside a lot of changes since GvR stepped down seem like stuff he'd not have been fond of.

I think this is a change longer in the making than that. Back when I started working with Python in the mid--late 2000s, the Zen was holy and it seemed very unlikely to ever see multiple ways to do "one thing". The Python community has since matured and realised that what they previously thought of as "one thing" were actually multiple different things with small nuances and it makes sense to support several of them…

You may be right. I checked and found the introduction of the ternary expression, which I found to be wildly "unpythonic", was back in 2006. Time flies.

Re: A tail calling interpreter for Python (already landed in CPython)

#39

Post by guappa »

kqr wrote: post #31
riffraff wrote: post #21

Earlier quoted context omitted.

the steering committee seems way less conservative than Guido, right? Looking at python from the outside a lot of changes since GvR stepped down seem like stuff he'd not have been fond of.

I think this is a change longer in the making than that. Back when I started working with Python in the mid--late 2000s, the Zen was holy and it seemed very unlikely to ever see multiple ways to do "one thing". The Python community has since matured and realised that what they previously thought of as "one thing" were actually multiple different things with small nuances and it makes sense to support several of them…

One way to do the things. That's why there's 5000 ways to install a module.

Re: A tail calling interpreter for Python (already landed in CPython)

#40

Post by dataflow »

tomsmeding wrote: post #35
dataflow wrote: post #30

Earlier quoted context omitted.

> By that standard, any optimization that changes scaling in any dimension changes semantics That doesn't follow. This isn't like going from driving a car to flying an airplane. It's like going from driving a car to just teleporting instantly. (Except it's about space rather than time.) It's a difference in degree (optimization), yes, but by a factor of infinity (O(n) overhead to 0 overhead). At that point it's not u…

Modern C compilers are able to transform something like this: for (int i = 0; i To: a += n * (n+1) / 2; Is this an optimisation or a change in program semantics? I've never heard anyone call it anything slse than an optimisation.

This will get a bit pedantic, but it's probably worthwhile... so here we go.

> Is this an optimisation or a change in program semantics?

Note that I specifically said something can be both an optimization and a change in semantics. It's not either-or.

However, it all depends on how the program semantics are defined. They are defined by the language specifications. Which means that in your example, it's by definition not a semantic change, because it occurs under the as-if rule, which says that optimizations are allowed as long as they don't affect program semantics. In fact, I'm not sure it's even possible to write a program that would be guaranteed to distinguish them based purely on the language standard. Whereas with tail recursion it's trivial to write a program that will crash without tail recursion but run arbitrarily long with it.

We do have at least one optimization that is permitted despite being prohibited by the as-if rule: return-value optimization (RVO). People certainly consider that a change in semantics, as well as an optimization.

Post reply on HN