If I were in charge of Python development, here are a few things I would do:
- Add (optional) tail recursion. This would make it easier to write pure functional code. It would also make it possible to effectively program in continuation passing style. Making tail recursion optional should placate those that feel that stack traces are important for debugging.
- Add macros. I am thinking of Lisp-like macros that do code transformation, not C-like macros that simply do token substitution. A good macro system would allow advanced users to create new syntactic forms for the language and provide a way to abstract boilerplate.
- Allow a way to use statements inside expressions, or beef up the expression syntax to have exception expressions, loop expressions, etc. This, too, would make it easier to write pure functional code.
- Optional end-of-block markers. These would allow you to automatically fix indentation errors and recover indentation when it is lost.
- Use true lexical scoping. Changing this might break legacy code that depends on the current scoping quirks, though.
- Use modern interpretation techniques to get the performance up to a more reasonable level. Performance doesn't matter that much, but Python is notably slow.
- Get rid of the global interpreter lock so that multithreading works better. Probably easier said than done.
I don't believe any of these necessarily involve fundamental changes to the language. They'd just make the language more flexible, though I'm sure many people would disagree with me.
But, perhaps for the best, they're not going to put me in charge.
3 comments:
You've more-or-less just described Julia:
* Lisp-like macros (including a class of intermediate-compliation-stage macros that can specialize on types, but not values)
* Everything is an expression
* End-of-block markers required for multi-line method bodies, but also a alternate single-line function definition syntax
* Sane scoping
* Highly performant
* True multi-threading (as well as cooperative multi-tasking)
The only thing missing is tall-call elimination, for which it seems the language designers are open to proposals: https://github.com/JuliaLang/julia/issues/4964#issuecomment-961932928
That would be bad because there would be fewer reasons to switch to Lisp and we would be stuck with Worse Is Better forever.
Some of those things (e.g. macros) you get when you are using Hy instead of Python:
https://hylang.org/
https://hylang.org/hy/doc/v0.29.0
https://github.com/hylang/hy
https://leanpub.com/hy-lisp-python
just my 2c.
Post a Comment