Presse

erstellt von Veit Schiele zuletzt geändert 2020-08-25T14:45:55+02:00 © cusy GmbH, Berlin 2015–2020
  • gegründet im Juli 2015
  • Firmensitz in Berlin, Deutschland
  • press@cusy.io

Python Pattern Matching im Linux-Magazin 05/2021

erstellt von Veit Schiele zuletzt geändert 2021-08-20T21:57:20+02:00
Die ursprünglich objektorientierte Programmiersprache Python soll in der Version 3.10 ein neues Feature erhalten, das vor allem aus funktionalen Sprachen bekannt ist: Pattern Matching. Die Änderung ist in der Python-Community umstritten und hat eine hitzige Debatte ausgelöst.

Pattern Matching ist ein Verfahren zur Symbolverarbeitung, das anhand eines Musters diskrete Strukturen oder Teilmengen, z.B. Zeichenketten, Bäume oder Graphen, identifiziert. Dieses Verfahren findet sich in funktionalen oder logischen Programmiersprachen, in denen ein Match-Ausdruck verwendet wird, um Daten basierend auf ihrer Struktur zu verarbeiten, z. B. in Scala, Rust und F#. Eine match-Anweisung nimmt einen Ausdruck und vergleicht ihn mit aufeinanderfolgenden Mustern, die als ein oder mehrere Fälle angegeben sind. Dies ist oberflächlich gesehen ähnlich wie eine switch-Anweisung in C, Java oder JavaScript, aber viel mächtiger.

Python 3.10 soll nun auch einen solchen Match-Ausdruck erhalten. Die Implementierung ist im PEP (Python Enhancement Proposal) 634 beschrieben [1]. Weitere Informationen zu den Plänen finden Sie in PEP 635 [2] und PEP 636 [3]. Wie das Pattern-Matching in Python 3.10 funktionieren soll, zeigt dieses sehr einfache Beispiel, bei dem ein Wert mit mehreren Literalen verglichen wird:

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"

Im letzten Fall der match-Anweisung fungiert ein Unterstrich _ als Platzhalter, der alles abfängt. Dies hat unter Entwicklern für Irritationen gesorgt, da in Python üblicherweise ein Unterstrich vor Variablennamen verwendet wird, um diese für den internen Gebrauch zu deklarieren. Zwar wird in Python nicht so streng zwischen privaten und öffentlichen Variablen unterschieden wie in Java, aber es handelt sich dennoch um eine sehr weit verbreitete Konvention, die auch im Style Guide for Python Code [4] festgelegt ist.

Die vorgeschlagene match-Anweisung kann jedoch nicht nur Muster prüfen, d.h. eine Übereinstimmung zwischen dem Wert einer Variablen und einem gegebenen Muster feststellen, sondern auch die Variablen, die auf das gegebene Muster passen, neu binden.

Das führt dazu, dass wir es in Python plötzlich mit Schrödingers Konstanten zu tun haben, die nur so lange konstant bleiben, bis wir sie in einer Match-Anweisung näher betrachten. Das folgende Beispiel soll dies verdeutlichen:

NOT_FOUND = 404
retcode = 200

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

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

Dies führt zu der folgenden Ausgabe:

not found
Current value of NOT_FOUND=200

Dieses Verhalten führt zu harscher Kritik an dem Vorschlag von erfahrenen Python-Entwicklern wie Brandon Rhodes, Autor von «Foundations of Python Network Programming»:

Wenn diese schlecht durchdachte Funktion wirklich zu Python hinzugefügt wird, verlieren wir ein Prinzip, das ich meinen Studenten immer beigebracht habe: ›Wenn du eine undokumentierte Konstante siehst, kannst du sie immer benennen, ohne die Bedeutung des Codes zu verändern.‹ Das Substitutionsprinzip, gelernt in Algebra? Es wird nicht mehr gelten.

— Brandon Rhodes am 12. Februar 2021, 14:55 auf Twitter [5]

Viele langjährige Python-Entwickler murren aber nicht nur über das strukturelle Pattern-Matching, das in Python 3.10 kommen soll. Sie bedauern generell die Entwicklung der letzten Jahre, in denen immer mehr syntaktischer Zucker über die Sprache gestreut wurde. Ursprüngliche Prinzipien, wie sie im Zen von Python [6] niedergelegt sind, würden dabei vergessen und die funktionale Stabilität ginge verloren.

Obwohl Python mit den Python Enhancement Proposals (PEPs) [7] einen ausgefeilten Prozess definiert hat, mit dem die Weiterentwicklung von Python kollaborativ gesteuert werden kann, gibt es auf Twitter und anderen sozialen Medien immer wieder Kritik, so auch jetzt beim Structural Pattern Matching. Tatsächlich wurde das Thema in der Python-Community bereits intensiv diskutiert. Der Python Steering Council [8] empfahl, die Vorschläge bereits im Dezember 2020 zu verabschieden. Dennoch ist das Thema erst mit der Verabschiedung der Proposals so richtig aufgekocht. Der Grund dafür ist sicherlich die Größe und Vielfalt der Python-Community. Die meisten Programmierer sind wahrscheinlich nur an Diskussionen über Erweiterungen interessiert, die ihre eigenen Probleme lösen. Die anderen Entwicklungen werden übersehen, bis die PEPs angenommen sind. Dies ist wahrscheinlich der Fall beim strukturellen Mustervergleich. Es eröffnet Lösungen für Probleme, die vorher in Python kaum möglich waren. Zum Beispiel erlaubt es Datenwissenschaftlern, passende Parser und Compiler zu schreiben, für die sie bisher auf funktionale oder logische Programmiersprachen zurückgreifen mussten.

Mit der Verabschiedung des PEP ist die Diskussion nun in die breitere Python-Gemeinschaft getragen worden. Brett Cannon, ein Mitglied des Python Steering Councils, wies übrigens in einem Interview [9] darauf hin, dass das letzte Wort noch nicht gesprochen ist: Bis zur ersten Betaversion sei noch Zeit für Änderungen, falls Probleme im praktisch genutzten Code auftreten. Er stellte auch in Aussicht, die Bedeutung von _ noch einmal zu ändern.

Vielleicht bleiben uns also Schrödingers Konstanten erspart.


[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

»Versionskontrolle für Machine-Learning-Projekte« in Informatik Aktuell vom 11. August 2020

erstellt von Veit Schiele zuletzt geändert 2021-08-22T16:26:16+02:00

Cusy schreibt in Informatik Aktuell in loser Reihe Artikel über Data Science Workflows. Als erster Beitrag ist nun Versionskontrolle für Machine-Learning-Projekte am 11. August 2020 erschienen.

In diesem Artikel erfahrt ihr, wie die Modellentwicklung für maschinelles Lernen (ML) systematisch organisiert werden kann. So kann die Leistung eines Modells verbessert werden, wenn ihr die Parameter feiner abgestimmt oder wenn mehr Trainingsdaten verfügbar werden. Um die Verbesserung messen zu können, sollte nachverfolgt werden können, welche Daten für das Training in welcher Modelldefinition und -konfiguration (Parameter etc.) verwendet und welche Modellleistungen damit erzielt wurden. Dabei werden sowohl die Daten wie auch der zugehörige Programmcode in einer Version erfasst werden.

DVC-Workflow

DVC-Workflow

Anhand eines Beispielprojekts führt der Artikel durch die folgenden Phasen:

  1. Repositories erstellen
  2. Datenpipelines definieren
  3. Reproduzieren
  4. Pipeline visualisieren
  5. Daten teilen

Unser Fazit ist ,dass mit DVC sprachunabhängig reproduzierbare ML-Pipelines definiert und zusammen mit den zugehörigen Trainingsdaten, Konfigurationen, Leistungsmetriken usw. versioniert gespeichert werden können. Dabei arbeitet DVC mit allen modernen Versionsverwaltungen zusammen und unterstützt viele verschiedene Speicherarten wie S3, Google Cloud, Azure, SSH usw. DVC strukturiert so nicht nur die Datenhaltung, sondern durch einzelne, atomare Phasen der DVC-Pipeline bleiben Änderungen in den Daten auch transparent und nachvollziehbar. Insgesamt erleichtert und effektiviert dies die Arbeit an ML-Projekten erheblich.

Cusy DevOps­-Toolchain as a Service in der iX extra 04/2020

erstellt von Veit Schiele zuletzt geändert 2020-12-20T19:51:14+02:00

Cusy wird im Extra Hosting für Entwickler der Zeitschrift iX 04/2020 besprochen. Insebsondere werden in diesem Heft zwei Entwicklertrends hervorgehoben: Microservices und DevOps. Dies sind auch Schwerpunkte unserer Arbeit, über die wir immer wieder berichten, z.B. in unserem Blog:

Beim Beispiel einer DevOps-Toolchain bezieht sich der iX-Artikel dann auch direkt auf uns:

Entwickleraufgabe Softwaretool
Projektmanagement Jira-Software
Dokumentenmanagement Confluence
Versionsverwaltung Gitblit
Code-Review Gerrit
Testen/Deployment Jenkins
Log-Management und -Analyse Sentry
Helpdesk Jira Service Desk
Webanalyse Matomo

Auch am Ende des Artikels wird Cusy noch einmal mit einem Alleinstellungsmerkmal erwähnt – die DevOps-Tools lassen sich leicht integrieren und verfügen über eine einheitliche Benutzerverwaltung:

Ganz auf Entwicklerwerk­zeuge hat sich Cusy spezialisiert. Alle Tools lassen sich einzeln als virtuelle Maschinen buchen, kön­nen aber über ein integriertes LDAP-­Directory zusammenarbei­ten.

Über uns

erstellt von Veit Schiele zuletzt geändert 2021-01-01T14:12:24+02:00 © cusy GmbH, Berlin 2015–2020

Gründungsidee

Das Unternehmen wurde 2015 gegründet um Web-basierte Software-Entwicklungswerkzeuge für einen unserer Kunden, die Gesellschaft für Datenschutz und Datensicherheit (GDD e.V.) bereitzustellen. Personenbezogene Daten sollten ausschließlich in Deutschland verarbeitet werden und zu diesem Zeitpunkt gab es kein anderes Unternehmen, dass das gesamte Toolset anbot.

Äußere Startbedingungen

Ende 2015 kippte der Europäische Gerichtshof das Safe Harbour-Abkommen zwischen der EU und den USA (→ Safe-Harbor Abkommen endgültig ausgelaufen). In der Folge kamen viele neue Kunden zu cusy. Das Wachstum verringerte sich erst, als ein neues Abkommen, «Privacy Shield» genannt, im August 2016 verabschiedet wurde.

2017 erweiterten wir unseren Geschäftsbereich auf die IT-Infrastruktur für Forschung und Entwicklung. Der Hintergrund hierfür war, dass einer unserer Kunden, das Fraunhofer Institut für Solarenergie, Unterstützung in diesem Bereich benötigte und wir unsere Erfahrung in der Bereitstellung von IT-Infrastruktur einbringen konnten. Wir erweiterten unser Wissen um die Verbesserung wissenschaftlicher Arbeitsabläufe vom Erheben und Erkunden der Daten bis hin zur Entwicklung robuster Software für die Produktion.

Kurze Zeit später brachten wir unsere Erfahrungen auch in Projekte mit der Humboldt Universität, der Beuth Hochschule und Springer nature ein.

Während viele heute mit den wirtschaftlichen Folgen von Corona zu kämpfen haben, stieg bei cusy die Nachfrage nach Lösungen für das Home-Office, insbesondere für datenschutzkonforme Videokonferenzen und Kollaborationswerkzeuge (→ Datenschutz in Zeiten von Covid-19). Seit dieser zeit bieten wir auch die Infrastruktur für Hackathons an, wie z.B. denjenigen der Universität Lüneburg mit rund 500 Teilnehmern.

Am 16. Juli 2020 hat der Europäische Gerichtshof dann entschieden, dass auch das Privacy Shields-Abkommen unzulässig ist (→ EuGH kippt Privacy Shield). In der Folge wuchs die Nachfrage nach unseren datenschutzkonform in Deutschland betriebenen Web-Applikationen.

Bisher haben wir Euch die äußeren Bedingungen gezeigt, unter denen wir arbeiten, aber auch unsere interne Organisation dürfte interessant sein.

Interne Organisation

Von Anfang an arbeiten wir mit agilen Methoden, um uns zu organisieren. Wir versuchen so effektiv wie möglich zusammenzuarbeiten, um unsere Ziele zu erreichen und dem Leben, das wir leben wollen, näher kommen.

Wie machen wir das im Detail?

  • Wir haben bereits lange vor Corona von verschiedenen Standorten aus zusammengearbeitet.
  • Wir haben keine Arbeitszeiten festgelegt
  • Wir haben unbegrenzten Urlaub und keine Hierarchie
  • Wir arbeiten in selbstorganisierten Gruppen
  • Unsere Arbeit basiert auf vielen Tools, wie Videokonferenzen und Chat für die direkte Kommunikation, Kanban-Boards für die Arbeitsorganisation und so weiter.

Weil Transparenz einer unserer stärksten Werte ist, möchten wir so offen und ehrlich wie möglich sein, untereinander, mit unserer Community und auch mit unseren Kunden.

Aus diesem Grund glauben wir auch an finanzielle Transparenz, die unsere Einnahmen, unsere Gewinne und Verluste für unsere Stakeholder offenlegt. Wir beziehen sie auch ein, in das, was wir tun, warum wir es tun und wohin wir wollen.

Unsere Honorare sind ebenso offen: Niemand arbeitet in einer ständigen Beschäftigung für cusy, alle sind Freiberufler oder Unternehmer, die mit mehreren Kunden arbeiten. Die Honorare ergeben sich aus einem einheitlichen Grundwert und dem Leistungsumfang.

Fogt uns auf –