4 ms·

If someone would make a Python 2.8 (or call it Python 5=2+3 if you like), I would pay for it. It must run basically every python 2.7 (or 2.6) program without ch

If someone would make a Python 2.8 (or call it Python 5=2+3 if you like), I would pay for it. It must run basically every python 2.7 (or 2.6) program without changes. It should backport as many features as possible. The meaning of "str" and string literals (bytes or unicode) should be configurable on a per-file basis. It should have a print statement. Finally, it should be able to use all the binary modules from 2.7 (maybe after recompilation). Currently at our work (in physics research), I have the feeling that people are giving up on Python. It's not worth the trouble to port to python 3 - especially because we can't switch all code at once; we'd have to support both versions for years. C++ which is also heavily used here is getting much nicer, with proper tooling it is even more pleasant to work in (code completion etc). We are mostly using Python for a) configuration files and b) quick and dirty scripts. For these cases, Python 2.7 will be good enough forever. If someone does something more complex, they'd probably use Python 3 - but they treat it like it's a completely different language rather than a new version of Python 2.

SpaceManNabs 11y ago
Likewise, one of my previous advisors has stopped doing any quick and dirty math in python. I am seeing Julia a lot more (for astrophysics and ML) and more C++ (physics) for the more important simulations.
- rspeer 11y ago
  Julia seems like an odd thing to bring up on the topic of "avoiding backward-incompatible language changes".
jamesdutc 11y ago
You'd have to pay a lot. Jokes of mine like https://github.com/dutc/rwatch https://github.com/dutc/rwatch and https://github.com/dutc/didyoumean https://github.com/dutc/didyoumean and https://bitbucket.org/dutc/astexpr https://bitbucket.org/dutc/astexpr are examples of adding major features to the CPython interpreter at run-time. It works fairly well in practice. It ends up looking like a `__future__`-import pragma that has interpreter lifetime scope rather than file scope. `__future__` imports cannot be undone within the same file -- after all, they're pragmas scoped at the file level, not actual imports -- and it would make sense for these backported features to behave similarly, though at the scope of the interpreter's lifetime. That might not do what you want. As you'd expect, the most superficial of Python 3's new features (syntax changes, `raise from`, &c.) would be easiest to backport. The bulk of the difficulty would be in merging those changes into Python 2.7. Making the result hot-loadable would be just as easy as in `dutc-rwatch`, though being able to toggle features on-and-off independently would require combinatoric effort with the naïve approach. You'd need to do something smarter. All in all, it's wholly possible to do what you want, and you probably have the skill to even do it yourself. I'd happily do the work myself, but only for lots of money. Unfortunately, the burden of both certifying the resulting interpreter as correct and of maintaining this fork would be large. And then when you're on-boarding some fresh new post-grad you've just hired into your research group: "Oh, we use Python 2.8 here. That's what we call Python 2.7 with an unsupported collection of modules that mutate the currently running interpreter to backport features from Python 3. Don't worry; it only breaks in ways that no one outside of this office will ever have a chance of ever understanding or helping you debug."
- jamesdutc 11y ago
  Oh, I should also mention that I found a way to embed Python interpreters within themselves. I have a couple of different ways to do it. Here's one: https://gist.github.com/dutc/eba9b2f7980f400f6287 https://gist.github.com/dutc/eba9b2f7980f400f6287 Here's another: https://gist.github.com/dutc/2866d969d5e9209d501a https://gist.github.com/dutc/2866d969d5e9209d501a I've given, like, a million conference talks about this. Better than creating some horrible Python 2.8 hybrid would be funding (or convincing me to volunteer to do) the work of completing this bridge. This involves writing 2/3 and 3/2 PyObject shims and figuring out some GIL and GC issues. Then, within a given host interpreter, you'd be able to execute modules within a guest interpreter of whatever Python version you want. With the shims and the bridge work, you'd be able to interact with these objects seamlessly from host-to-guest and guest-to-host.
- fernly 11y ago
  Aren't there issues at the bytecode level? I've been studying bytecode and ceval.c and I know there are significant differences in the bytecode set, as well as in the code object and function object. So what would a "Python 2.8" compile phase generate? Would the huge switch statement in ceval.c have to have a whole new layer of if-logic in it?

SpaceManNabs 11y ago

Likewise, one of my previous advisors has stopped doing any quick and dirty math in python. I am seeing Julia a lot more (for astrophysics and ML) and more C++ (physics) for the more important simulations.

rspeer 11y ago
Julia seems like an odd thing to bring up on the topic of "avoiding backward-incompatible language changes".

jamesdutc 11y ago

You'd have to pay a lot. Jokes of mine like https://github.com/dutc/rwatch https://github.com/dutc/rwatch and https://github.com/dutc/didyoumean https://github.com/dutc/didyoumean and https://bitbucket.org/dutc/astexpr https://bitbucket.org/dutc/astexpr are examples of adding major features to the CPython interpreter at run-time. It works fairly well in practice. It ends up looking like a `__future__`-import pragma that has interpreter lifetime scope rather than file scope. `__future__` imports cannot be undone within the same file -- after all, they're pragmas scoped at the file level, not actual imports -- and it would make sense for these backported features to behave similarly, though at the scope of the interpreter's lifetime. That might not do what you want. As you'd expect, the most superficial of Python 3's new features (syntax changes, `raise from`, &c.) would be easiest to backport. The bulk of the difficulty would be in merging those changes into Python 2.7. Making the result hot-loadable would be just as easy as in `dutc-rwatch`, though being able to toggle features on-and-off independently would require combinatoric effort with the naïve approach. You'd need to do something smarter. All in all, it's wholly possible to do what you want, and you probably have the skill to even do it yourself. I'd happily do the work myself, but only for lots of money. Unfortunately, the burden of both certifying the resulting interpreter as correct and of maintaining this fork would be large. And then when you're on-boarding some fresh new post-grad you've just hired into your research group: "Oh, we use Python 2.8 here. That's what we call Python 2.7 with an unsupported collection of modules that mutate the currently running interpreter to backport features from Python 3. Don't worry; it only breaks in ways that no one outside of this office will ever have a chance of ever understanding or helping you debug."

jamesdutc 11y ago
Oh, I should also mention that I found a way to embed Python interpreters within themselves. I have a couple of different ways to do it. Here's one: https://gist.github.com/dutc/eba9b2f7980f400f6287 https://gist.github.com/dutc/eba9b2f7980f400f6287 Here's another: https://gist.github.com/dutc/2866d969d5e9209d501a https://gist.github.com/dutc/2866d969d5e9209d501a I've given, like, a million conference talks about this. Better than creating some horrible Python 2.8 hybrid would be funding (or convincing me to volunteer to do) the work of completing this bridge. This involves writing 2/3 and 3/2 PyObject shims and figuring out some GIL and GC issues. Then, within a given host interpreter, you'd be able to execute modules within a guest interpreter of whatever Python version you want. With the shims and the bridge work, you'd be able to interact with these objects seamlessly from host-to-guest and guest-to-host.
fernly 11y ago
Aren't there issues at the bytecode level? I've been studying bytecode and ceval.c and I know there are significant differences in the bytecode set, as well as in the code object and function object. So what would a "Python 2.8" compile phase generate? Would the huge switch statement in ceval.c have to have a whole new layer of if-logic in it?