Python 622

A practical view of PEP 622

Python’s PEP-622 proposal seeks to add much needed pattern matching, sealed classes and algebraic data types to the language. This is a more practical criticism of the proposal, rather than a critique based on some abstract programming language theory.

Python’s place in the programming toolbox

Most people think of Python as a language to write a 50-100 line script to do something quick and dirty. Sort of how people used perl 20 years ago.

Executable pseudo-code is a happy place Python enjoys with emphasis on clean code and explicit deemphasis on performance.

It’s possible to write larger code bases in the language, but you end up with resistance from various programming factions.

1. Use Rust/Go/$fav_language - because Python doesn’t have algebraic data types. It’s type system is fragile and type checkers are slow.

2. Python has a GIL and pypy hasn’t made a dent after 10+ years of existence. If you care about performance, use something else.

3. Python has a closed development process that’s not welcoming of people with unconventional opinions. I don’t have all the details, but look up Zed A Shaw and David Beazely.

Another view of Python’s place in everyday programming

A practical take on Python is to use it to quickly translate ideas into testable code. Such code may not be very performant or production worthy.

But if you can force a widely used subset of python - say 10-20% of the current language spec, it could be transpiled into a more performant language.

py14, pyrs and static-python are a few efforts in this direction.

Pythonistas have a Pythonic world view

If you read PEP-622, somewhere in the middle is this paragraph:

Make it an expression

In most other languages pattern matching is represented by an expression, not statement. But making it an expression would be inconsistent with other syntactic choices in Python. All decision making logic is expressed almost exclusively in statements, so we decided to not deviate from this.

Similar sentiments can be seen in the python-dev mailing list discussion on the topic, where this discussion was shutdown without an explanation, presumably because it lead to controversies. But curious minds have no way of surfacing that discussion and educating themselves.

More practically, what this means is that if Python’s place in the world is to write code quickly, experiment and if successful, transpile into more performant languages, these type of decisions actively make that view untenable.

Full disclosure: I wrote a pattern match as an expression PEP, but didn’t publish it. The code is available if you want to hack on it.

Sealed with a kiss of inheritance

An equally interesting part of PEP-622 is the support for sealed classes - a concept I first noticed in Kotlin.

But Python’s sealed classes use the inheritance syntax, which could be problematic for the functional programming crowd.

There is a different syntax that’s possible which would not impose inheritance.

@sealed
class Node:
    EXPRESSION = Expression
    STATEMENT = Statement

@sealed
class Expression:
    NAME = Name
    OPERATION = Operation

@sealed
class Statement:
    ASSIGNMENT = Assignment
    ...

class OP(IntEnum):
     plus = 0
     minus,
     ...

@dataclass
class Operation:
    left: Expression
    op: OP
    right: Expression

Not much discussion of these ideas in the PEP or other places where I looked.

So what is Python’s place in the world?

Perhaps you disagree with this world view. Care to share yours?