Skip to content

Instantly share code, notes, and snippets.

@c-cube
Last active April 13, 2020 15:12
Show Gist options
  • Select an option

  • Save c-cube/98e4ef3c0ae7cb6fb2704f7ee09b7170 to your computer and use it in GitHub Desktop.

Select an option

Save c-cube/98e4ef3c0ae7cb6fb2704f7ee09b7170 to your computer and use it in GitHub Desktop.
my totally uninformed opinion on what python4 should be

Python4

We all have in mind the painful transition from python2 to python3. I argue python4 should be a priviledged subset of python3 that is still compatible with it, so that the transition is frictionless. At the same time, python4 should address some of the biggest limitations of python3:

  • the very low performance
  • the high memory overhead of default constructs
  • the GIL
  • the packaging mess

However, I don't think this can be fixed without breaking everything:

  • scoping

So I think python4 should really be subset where type annotations (or type inference) is mandatory through the whole module, and is relied on for generating efficient performance. Objects would not be dictionaries anymore but use __slots__ automatically, runtime type checks would be inserted only at the interface with py3 modules, and the language would be a bit more static (actual variables, not a local __dict__ lookup). The GIL would be acquired when interpreting code from a python3 module, but would not necessarily be required otherwise.

Tooling should become more opinionated, with a standard packaging system with lockfiles (thing "cargo") and the ability to compile a pure python4 project into an executable.

Performance is important, and some newer languages (nim, crystal, D, Go) try to provide some of the convenience of dynamic languages but in a much more efficient way. Crystal in particular is an impressive improvement on ruby.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment