Skip to content. | Skip to navigation

solving complex IT problems!

Personal tools

You are here: Home / About us / Press

Press

Python Pattern Matching in Admin Magazine #63

The originally object-oriented programming language Python is to receive a new feature in version 3.10, which is mainly known from functional languages: pattern matching. The change is controversial in the Python community and has triggered a heated debate.
Python Pattern Matching in Admin Magazine #63

Admin Magazine #63

The originally object-oriented programming language Python is to receive a new feature in version 3.10, which is mainly known from functional languages: pattern matching. The change is controversial in the Python community and has triggered a heated debate.

Pattern matching is a symbol-processing method that uses a pattern to identify discrete structures or subsets, e.g. strings, trees or graphs. This procedure is found in functional or logical programming languages where a match expression is used to process data based on its structure, e.g. in Scala, Rust and F#. A match statement takes an expression and compares it to successive patterns specified as one or more cases. This is superficially similar to a switch statement in C, Java or JavaScript, but much more powerful.

Python 3.10 is now also to receive such a match expression. The implementation is described in PEP (Python Enhancement Proposal) 634. [1] Further information on the plans can be found in PEP 635 [2] and PEP 636 [3]. How pattern matching is supposed to work in Python 3.10 is shown by this very simple example, where a value is compared with several literals:

def http_error(status):
      match status:
          case 400:
              return "Bad request"
          case 401:
              return "Unauthorized"
          case 403:
              return "Forbidden"
          case 404:
              return "Not found"
          case 418:
              return "I'm a teapot"
          case _:
              return "Something else"

In the last case of the match statement, an underscore _ acts as a placeholder that intercepts everything. This has caused irritation among developers because an underscore is usually used in Python before variable names to declare them for internal use. While Python does not distinguish between private and public variables as strictly as Java does, it is still a very widely used convention that is also specified in the Style Guide for Python Code [4].

However, the proposed match statement can not only check patterns, i.e. detect a match between the value of a variable and a given pattern, it also rebinds the variables that match the given pattern.

This leads to the fact that in Python we suddenly have to deal with Schrödinger constants, which only remain constant until we take a closer look at them in a match statement. The following example is intended to explain this:

NOT_FOUND = 404
retcode = 200

match retcode:
    case NOT_FOUND:
        print('not found')

print(f"Current value of {NOT_FOUND=}")

This results in the following output:

not found
Current value of NOT_FOUND=200

This behaviour leads to harsh criticism of the proposal from experienced Python developers such as Brandon Rhodes, author of «Foundations of Python Network Programming»:

If this poorly-designed feature is really added to Python, we lose a principle I’ve always taught students: “if you see an undocumented constant, you can always name it without changing the code’s meaning.” The Substitution Principle, learned in algebra? It’ll no longer apply.

— Brandon Rhodes on 12 February 2021, 2:55 pm on Twitter [5]

Many long-time Python developers, however, are not only grumbling about the structural pattern-matching that is to come in Python 3.10. They generally regret developments in recent years in which more and more syntactic sugar has been sprinkled over the language. Original principles, as laid down in the Zen of Python [6], would be forgotten and functional stability would be lost.

Although Python has defined a sophisticated process with the Python Enhancement Proposals (PEPs) [7] that can be used to collaboratively steer the further development of Python, there is always criticism on Twitter and other social media, as is the case now with structural pattern matching. In fact, the topic has already been discussed intensively in the Python community. The Python Steering Council [8] recommended adoption of the Proposals as early as December 2020. Nevertheless, the topic only really boiled up with the adoption of the Proposals. The reason for this is surely the size and diversity of the Python community. Most programmers are probably only interested in discussions about extensions that solve their own problems. The other developments are overlooked until the PEPs are accepted. This is probably the case with structural pattern matching. It opens up solutions to problems that were hardly possible in Python before. For example, it allows data scientists to write matching parsers and compilers for which they previously had to resort to functional or logical programming languages.

With the adoption of the PEP, the discussion has now been taken into the wider Python community. Incidentally, Brett Cannon, a member of the Python Steering Council, pointed out in an interview [9] that the last word has not yet been spoken: until the first beta version, there is still time for changes if problems arise in practically used code. He also held out the possibility of changing the meaning of _ once again.

So maybe we will be spared Schrödinger’s constants.


[1]PEP 634: Specification
[2]PEP 635: Motivation and Rationale
[3]PEP 636: Tutorial
[4]https://pep8.org/#descriptive-naming-styles
[5]@brandon_rhodes
[6]PEP 20 – The Zen of Python
[7]Index of Python Enhancement Proposals (PEPs)
[8]Python Steering Council
[9]Python Bytes Episode #221

About us

Founding idea

The company was founded in 2015 to host web based software development tools for one of our customers, the German Society for Data Protection and Data Security (GDD e.V.), the german society for data protection and data security. They haven’t allowed us to process personal data outside of Germany and at that moment there was no other firm who offered the whole toolset we needed.

External starting conditions

At the end of the year 2015 the European Court of Justice invalidated the Safe Harbour Privacy Principles, so all european companies had to process their personal data in the European Union. Subsequently many new customers came to cusy. The growth weakend only when a new agreement called «Privacy Shield» was adopted in August 2016.

In 2017 we expanded our business area to the IT infrastructure for research and development. The background to this was, that one of our customers, the Fraunhofer Institute for solar energy, needed support in this area and at least we have knowledge in provisioning IT-infrastructure. Now we aquired knowledge in optimising data science workflows from gathering and exploring data to stable software suitable for production.

Later we also have worked for the Humboldt University, the Beuth University and Springer nature.

While many today struggle with Corona’s economic conditions, at Cusy the demand for solutions to work at home increased, especially for data protection-compliant tools for video conferencing and collaborative writing. We also provide the infrastructure for hackathons such as the one at the University of Lüneburg with around 500 participants.

On July 16, 2020, the European Court of Justice decided, that the agreement for transfering personal data from the European Union to the United States is not allowd again. Therefore, we get more inquires about our tool set hosted in Germany.

So far we have shown you the external conditions, in which we operate, but our internal organisation should also be interesting.

Internal organisation

From the beginning we work with agile methods to organise ourselves. So we try working together in the most effective way to achieve our goals as we get closer to the life we want to live.

How do we do that in detail?

So we worked remotely from different locations long before Corona.

  • We have not set working hours
  • we have unlimited vacation and no hierarchy
  • We work in self-organised groups
  • Our work depends on a lot of tools like video conferencing and chat for direct communication, Kanban boards for the joint work organisation and so on.

Because transparency is one of our strongest values, we like to be as open and honest as we can with each other, our community and also our clients.

As a result we believe in financial transparency giving our revenue streams including our wins and losses to our stakeholders. Also we try to include them in what we are doing, why we are doing and where we’re going.

Our salaries are as open as well: No one works in a permanent empoyment for cusy, all are freelancers or entrepreneurs working with multiple clients. Salaries are calculated from the uniform base value and the commitment.

Follow us on …