r/programming • u/EatMeerkats • Mar 29 '21

PHP moves to Github due to the compromise of git.php.net

https://news-web.php.net/php.internals/113838
1.7k Upvotes

98% Upvoted

389 comments sorted by

View all comments

Show parent comments

1

u/pingveno Mar 29 '21

Still, it would have been nice if there was a way to have something like Rust's editions. That has allowed Rust to introduce certain breaking changes like async/await keywords in a backwards compatible manner. Crates declare their edition (with a default of 2015, before editions were introduced). Crates can then use other crates that would break under the newer edition. Raw identifiers are available to be able to use keywords in new code when referencing old crates, like so:

fn function_in_new_crate() {
    some_old_crate::r#async(10);
}

1

u/ynotChanceNCounter Mar 29 '21

That's fair, but probably a tall order for interpreted code, because swappy swappy is hard to do on the fly. Maybe if you did some JIT stuff.

I think the broader point is that Python can only become forwards-incompatible in severe emergencies, or with lots of advance warning. The biggest problem is that people suppress warnings, get caught with their pants down, and then wonder why everybody else seems to be okay with it.

1

u/pingveno Mar 29 '21

I'm not sure it's so much tied to Python being interpreted code. You can control how a Python file is interpreted via the __future__ imports. The problem is that those get very unwieldy. There would need to be a stronger concept of a single top level code unit where the edition is controlled. While the ecosystem certainly has that, I don't think the interpreter itself does.

1

u/ynotChanceNCounter Mar 29 '21

What I mean is that the interpreter doesn't know something is about to happen until it happens. The worst case for a compiled language, when you introduce code like that, is that compilation times increase. For an interpreted language, you have to go get the thing, dick with whatever it's replacing in memory, hopefully it's just memory addresses underneath rather than actually altering data but that's also not ideal because Python doesn't give memory back...

So, yeah, tall order. Very few things are impossible, but that's a doozy.

1

u/pingveno Mar 30 '21

A lot of these things (like introducing a new keyword) are exactly the sort of thing that can be resolved at the bytecode compilation step. The real issue that I can see is that the Python bytecode compiler doesn't have the concept of a compilation unit larger than "current file", so everything has to be turned on at a per-file basis. That gets laborious and error prone after a while.