The Orobix team shares their experience.

16 June 2023

Reading time: 8 minutes

2023 was the third year for Orobix at Pycon IT and also the year when we tried to get out of our comfort zone and return, after PyconX (Orobix: AI gets to work!), to share some of our experience with other developers.


Pycon proves to be a conference of great interest and educational value in many aspects: technical, creative, social.

The community is more active than ever. Feeling welcomed each year by familiar faces, opening up to the possibility of meeting new ones, is one of the main strengths of this event. ❤️ But we cannot fail to mention the high professional profile of the speakers, which allows the complexity of technological topics to be abstracted, bringing the speeches to a level that is not necessarily advanced, but captures everyone’s attention. The goal of providing a contamination of technological insights, best practices, libraries, tools, and in general ensuring a fertile context for collaborations and ideas is fully achieved.


We are pleased with the appreciation received for our two talks given by our colleagues Federico Belotti and Refik Can Malli. The affluence and the questions asked by the audience encourage us to continue on this path of communication and continuous improvement. 🙏

We hope that the community came out as enriched as we did trying to learn as much as possible each year, but more importantly to convince colleagues who stayed home to join us in future events.

After all, even our manifesto says so, "WE ARE at our best together, when we share visions and circulate knowledge." 
It is also for them that we thought we would summarize some of the talks we enjoyed most and think are worth listening to again.

1 - Robyn: A fast async Python web framework with a Rust runtime - Sanskar Jethi - by Franco Parodi

Sanskar Jethi is the author of Robyn, a Python web framework with Rust runtime. It is one of the fastest Python web frameworks, so much so that it allows near-native performance while maintaining the ease of writing Python code. It raises a lot of interest as it allows for:

  • high performance
  • ease of developments
  • multithreaded, asynchronous functions.

An additional feature that makes it interesting is the fact that it does not require any expertise on web technologies (reactjs, vue, angular… ) as it is sufficient to know Python, i.e., in favor of autonomy in the implementation of web solutions (no fullstack figures are needed). Some of the main features that set it apart:

  • written in Rust
  • multithreaded runtime
  • simple API
  • synchronous/asynchronous function support
  • constant development and support.


2 - Don't just test, my friend, test better - Cheuk Ting Ho - by Mattia Federici

Have you ever been stuck in lines of tests that looks all the same? Did you spend some time thinking about all the possible list of integer that you can test?Maybe Cheuk Ting Ho has some tips for you!

By default Pytest has a large quantity of tools specifically created to test different scenarios that they deviate somewhat from the base cases.

Let’s see them:

  • Parameterize: allow test parametrization, giving the option to run the same test code with N different input.
  • Hypotesis: it is based on the properties of the inputs treated in a generic way according to ‘strategies’. For example, the List of Integers strategy generates edge cases such as empty lists, very large integers, zeros, or negatives in a repeatable pseudo-random fashion during testing.
  • Fixture: this decorator allows to keep elements ‘constant and unchanged’ during the execution of the tests. You can add a fixture validity context such as module, class, session, or package to limit its scope.
  • Markxfail: knowing in advance that a test will fail on a certain operating system or due to a known bug, markxfail allows you to skip a test elegantly.


3 - Rust is easy - Luca Baggi - by Marco Bignotti

What happens if we write Python code inside a rust program? Literally, what happens if we put this function:

def hello(name):
return "Hello " + name

into a file and run cargo run? It looks crazy, but the result can be surprising. No, the code will not compile, should anyone be wondering about it. But here is the error message that we receive:

help: write `fn` instead of `def` to declare a function

Then why do we not simply subsitute def with fn, compile again, and see what happens?

This is the clever intro given by Luca Baggi to motivate his introductory talk about Rust. The idea is that one should be able to write valid, however simple, Rust code, by simply start writing Python code and looking at the error messages one at a time.

Indeed, with only a few iterations, Luca managed to write a valid rust function that successfully compiles. All without ever looking at the official documentation, online courses, MOOCs, Copilot, StackOverflow, or whatever online/offline resource you might think of. Just by looking at the error messages.

But what’s the point? Why are we talking about Rust at a Python conference? And why should we, as Python developers, be interested in a low level language like rust?

Well, for years we have heard people saying that Python is easy. And that’s true, but not totally accurate. We should rather say that Python is accessible. What’s the difference? Well, the syntax is beautiful and easy to grasp, but nothing prevents you from making the same mistakes that (junior?) developers always make over time (myself included). To name a few: writing interfaces that are hard to respect and understand, do not respect and API just because, well, we can, do not respect types, ignore design patterns where appropriate…

Rust took a different path, and prevents many of these issues by construction, often at compile time. Python doesn’t have all this nice tooling built in. Yet, given its dynamic nature, nothing prevents us from adopting the very same patterns and good practices that made rust such a popular language.


4 - Creating an AI-Python Infrastructure that works with a reasonable scale - Andrea Guzzo - by Refik Can Malli

Andrea Guzzo talked about why many AI projects don’t end up being used and shared tips on how to create AI products using modern technologies and Python as the main programming language. He explained that it’s possible to build valuable AI products without needing the resources of a big tech company.

He described a full stack of a Python framework that can run completely on-premise and showed examples that have also UI components for interacting with NLP Tasks. Since the NLP field moving so fast, he briefly explained current trend of large language models and gave examples for their deployment scenarios. He continued on real-world cases by mentioning MLOps maturity levels and their specifications. Finally, he introduced a template library for Python development named Bear.


5 - Remote Teams are autistic - Miriam Perrone - by Lisa Lozza

Not all talks at Pycon deal with programming, the topics are heterogeneous, and I tend to take advantage of the variety precisely to get up to speed on technical topics, but also to learn more from a softskill or management perspective.

The title I considered most engaging and contemporary this year was Miriam Perrone’s talk, “Remote Teams are Autistic.” Miriam was able, from her experience as an autism consultant, to analyze remote teams to find some interesting tips on their management. Miriam explains what are the similarities between people with autism spectrum and remote teams, mainly focusing on the issue of communication. A person with autism may not be able to understand the difference between two tones of voice or interpret body language, thus focusing only on pure words. Similarly, the communication systems we use more since the spread of remote working (chat and email) can lead each of us to have difficulty interpreting the simplest communications. Hence the importance of being aware of these difficulties, of not making assumptions, but making sure that there is understanding of the information shared, trying to be as clear as possible in communication.

The talk also reminded me how critical it is to remember that everyone is different, we need to engage in recognizing which modes of communication are more effective and which are less so, for each member of the team. I think this can be considered one of the secrets to building a knowledgeable, engaged, and high-performing team.


6 - Code Debugging and Refactoring with OpenBugger: a Python Library for Self-Supervised AI Debuggers - Tommaso Furlanello - by Federico Belotti

Tommaso Furlanello explore the bright new world of LLMs as code-assistants focusing on “the observation that GPT reaches its limit not when it outputs bugged code, but when it fails at fixing it“. Going through the recent reserach advancements on LLMs, Tommaso noted that to finetune such big models (like OpenAssistant) one needs both a huge amount of data and compute, and when GPUs lack, then creative ideas must be found to generate good data in a synthetic manner. Tommaso then explained how he was able to generate a reasonable amount of data to finetune an LLM to reason about code, spot bugs and fix them: 2K LeetCode python exercises with solutions were parsed to obtain the Concrete Syntax Tree (CST) representation, then using its own OpenBugger he injected invertible bugs into the CST representation obtaining 20K examples of bugged code alongside debugging traces, which were finally used to generate Question-Answering-like prompts to be fed to the LLMs upon finetuning.