PyParis is a community-organised conference on all topics around the Python programming language. The expected target group are primarily practitioners and researchers in the greater capital region of France, but also international engineers and language advocates. At Zurich University of Applied Sciences, Python is taught as automation and statistics application language to more than 200 business engineering, aviation and traffic engineering undergraduates per year. It is furthermore used a lot in research, including several prototypes resulting from the Service Prototyping Lab. Therefore, it was consequential for us to attend the conference and to contribute an in-depth tutorial on one of our research topics, Function-as-a-Service, to its attendees.
PyParis took place in the Pôle Universitaire Léonard de Vinci in the business district La Défense. The place usually hosts an Institute of Internet and Multimedia, an engineering school, and a research centre, and thus offered the right scale and atmosphere. For two days, it hosted PyParis which was booked out with around 300 people and therefore promised an intense exchange of ideas, knowledge and business cards.
The conference opening highlighted the increased importance of stable and predictable programming language ecosystems. Both the event itself and several Python-related organisations appear to have a growing number of sponsors to whom a healthy ecosystem with tools, projects and services is important. This was pointed out in the opening and in the first keynote alike. Among them is NumFocus, a non-profit dedicated to high-level languages in science, and of course the Python Software Foundation.
The keynote, delivered by Silvain Corlay whose roots are in University Paris VI and Columbia University, pointed out the need to get more actively and early involved in open source software development to reap the multiplier benefits. Many relevant projects now form the backbone of scientific computing and offer a common infrastructure, although more collaboration between similar languages (R, Python, Julia) is still necessary. The second keynote, given with a large portion of French Catalan humour by Ludovic Gasc, asked the rhetoric question whether Python is still production-ready, considering that it almost dates back to the half-time of COBOL history. Among his slides was one which contributed a useful definition: A production service is one which makes you receive calls if it goes down. Among the more serious remarks were the ones about avoiding over-engineering, focusing on the right scale (not everybody needs Google scale which inevitably comes with Google complexity), and listening to future users instead of following technology trends.
An interesting talk was given by Alexandre Abadie about Python for the Internet of Things, evolving around software interfaces to the two protocols CoAP and MQTT and their support for restricted devices on top of Riot OS. Thanks to a question from the audience, the motivation for not using Micropython due to certain hardware-agnostic features were made clear by the speaker.
Another talk on topic for the Service Prototyping Lab has been on using the AsyncIO module for microservice development, presented by Joir-dan Gumbs who flew in from San Francisco. Some of the sample code shown referred quite explicitly to OpenWhisk actions which means that this code is useful for certain Function-as-a-Service implementations. Microservices and FaaS were also prominently featured in other talks such as the ones by Benjamin Talmard on serverless architectures in Python with Azure Functions and by Harjinder Mistry on cloud-native applications. A promising talk on RESTful hypermedia APIs, alas, had to be cancelled due to health reasons.
From the education perspective, the second day keynote Nicholas Tollervey from the UK about Python in education was extremely bright. It focused on cheering up school kids with simple-to-program devices such as the BBC micro:bit and related gadgets, including a radio-controlled robot with speech synthesis, which cherish creativity over strictly business software engineering methodologies, with remembrances to the Acorn times.
From a pure programming point of view, Burkhard Kloss offered a nice overview about profiling and performance tuning, including the important statement that no performance optimisation should be done without answering the question of how fast is fast enough for a certain context. Nevertheless, software speed is losing importance to the speed in time to market, which means that future software evaluations should consider fitness for rapid prototyping as similarly important metric.
In addition to the many talks in up to four parallel tracks, several 90-minute tutorials were offered, including ours on a Pythonic perspective on ‘serverless’ computing, or function-as-a-service offerings. In the first part, it presented the broader view on what exists and how Python support (especially versions 2 and 3 of the language) evolved in the commercial and open source runtimes, and gave hands-on opportunities with some of the software available, although evidently none of it seems to be tuned for zero-configuration use in such educational scenarios. In the second part, our own creations (Lambada, Snafu) were presented which obviously cover this need. The participants were highly motivated and, according to the feedback received, appreciated the objective and practical introduction into the topic.
As part of our quality commitment, we make both the tutorial slides and the transcript of commands for reproducible learning experience available online on our publications page.
Overall, PyParis was a great conference, despite Paris being in hard to navigate shape due to infrastructural constructions and intense security theatre. We look forward to local events such as the next Swiss Python Summit in early 2018 and other events dedicated to programming and application software engineering. Cloud computing is still hard to get right from the application engineering and provisioning perspective, and we work hard to overcome the limitations.
