Python

Python is one of the most popular programming languages. Even big companies like Google, Dropbox, Netflix and Bloomberg rely on Python. Python focuses on code readability and is easy to learn and write.

Python is excellent for developing Minimal Viable Products (MVPs) and rapid prototyping and is very widely used in research organisations, the health and energy sectors, and in the media and publishing industries.

Together with Jupyter Notebooks, it quickly became the de facto working environment for data scientists. Following The State of the Octoverse, we see here the growth of Python, related tools and frameworks from a rapidly growing community of data scientists whose work is greatly simplified with Python. Among the most popular code sources are the Python libraries NumPy, SciPy, Scikit-Learn and TensorFlow.

Cusy is a long-time sponsor and organiser of the Python Users Berlin.

Consulting

We offer a comprehensive range of services for the entire lifecycle of your software, from software architecture, coding, code reviews and testing to CI/CD pipelines and DevOps.

Cooperation

We can either analyse requirements with you and design the appropriate software architecture or analyse an existing code base with you and refactor it if necessary, see also Software reviews – does high-quality software justify its cost? Finally, we can also advise you on the modernisation of your processes and infrastructures.

Training

We offer open and individual Python courses for data analysts, scientists and research software engineers. For more information and dates of open trainings, please visit the Python Trainings page. We have also created two online tutorials:

Get in touch

I will be happy to answer your questions and create a tailor-made offer for your Python project.

Portrait Veit Schiele
Veit Schiele
E-mail: info@cusy.io

I will also be happy to call you!

Request now

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.

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

Rust for cryptography

The programming language Rust [1] is becoming more and more popular and is increasingly used for cryptography. In Rust’s favour is the fact that the language promises very secure memory management, making errors such as buffer overflows and use-after-free less likely. Considering one of the best-known TLS vulnerabilities, the OpenSSL Heartbleed bug [2], which violates memory security, this development is not surprising.

For example, a new TLS backend with Rustls [3] was recently announced for the curl library [4]. Hyper [5], an HTTP library written in Rust, is also to be made available as a backend for curl [6].

The Internet Security Research Group (ISRG) [7] also announced that they will support a Rust-based TLS module for the Apache web server [8]. This is funded as part of Google’s and the ISRG’s efforts to move ports of critical open source software into memory-safe languages [9].

The move of the cryptography package from Python, however, led to heated discussions in the community, as especially some older platforms would no longer be supported without the Rust compiler [10]. The cryptography [#]_project has already started to reimplement parts of its ASN1 parsing code in Rust, [11] [12] as ASN1 parsers often had memory security vulnerabilities in the past.


[1]Rust
[2]The Heartbleed Bug
[3]Rustls
[4]curl supports rustls
[5]Hyper
[6]Rust in curl with hyper
[7]Internet Security Research Group
[8]A Memory Safe TLS Module for the Apache HTTP Server
[9]Google Security Blog: Mitigating Memory Safety Issues in Open Source Software
[10]Dependency on rust removes support for a number of platforms #5771
[11]github.com/pyca/cryptography
[12]Port a tiny tiny bit of the ASN.1 parsing to Rust
[13]Rust in pyca/cryptography

Cheat sheets for our Python seminars

For our Python training for analysts, scientists and engineers we have created cheat sheets that allow the course participants to quickly reuse what they have learned:

Python Cheat Sheet

Python Cheat Sheet Python Cheat Sheet 2

python-for-beginners-cheat-sheet.pdf, PDF, 70.4 KB

Pandas Cheat Sheet

Pandas Cheat Sheet Pandas Cheat Sheet 2

pandas-cheat-sheet.pdf, PDF, 52 KB

Git Cheat Sheet

Git Cheat Sheet Git Cheat Sheet 2

git-cheatsheet-web.pdf, PDF, 437 KB

And if you have any further questions about our training courses, please give us a call on +49 30 22430082 or send us an email to training@cusy.io.