🌏 Coming to PyCon AU from overseas?
If you're traveling from outside Australia, now is the time to get your visa sorted!
We’ve just published updated information to help you prepare your visa application. Visa processing can take time, so check it out and don't be late!
Everyone’s loving the avatars @pycon — so I had to make one for our amazing Devs-in-Residence @ThePSF too. This photo? Epic.
@ambv @sethmlarson @miketheman #PyConUS #pycon2025
I turned my #pycon2025 poster about vector embeddings into a blog post:
https://blog.pamelafox.org/2025/05/a-visual-exploration-of-vector.html
Takeaways:
1. Your business code is sacred
2. Protect it from your tools
3. Write tests; get a better design
https://ox.cx/design for more!
And follow Hynek on YouTube at @THE_HYNEK
Whenever possible, start with the domain model, then start ✨engineering✨
"Complexity is not about how many keys I have to press -- it's about how difficult it is to reason about the consequences of what I'm doing"
- @hynek
If you follow this method, Hynek argues that you have lost control over your domain model and therefore over your business logic.
It's ok to have duplicative-looking types at the edges of your project! Like the web interface and the DB layer
You might have three (or more!) classes for the same thing and that's OK.
(with a h/t to Adam Montgomery)
There are multiple approaches to solving this tension!
I won't write down the first one because @hynek asked us not to.
But the next way (which is apparently worse?) is to use class-based validators and an ORM as the bread in a sandwich of your business logic
They do not make good bread and your domain model gets squeezed to death.
Conflicting goals exist in all meaningful apps
The Web API is dictated by what is best for the user, what's a good external standard, etc
The Database Schema is motivated by effective data storage, developer affordances, and performance
The Domain Model is dictated by the Business Requirement
All the shitty stuff should happen on the outside layer of your program.
Once it's inside, make it as nice as possible.
The shape of the data determines the shape of the code.
Next pressure: The Rising Sea.
The example here is a box-moving problem from Advent of Code.
Good solutions reflect a well-formulated Domain Model, a model of code and data that describes the domain of your business or problem
Good solutions often include The Darkness, the messy layer that connects the outside world to your Domain Model
This relates to how tightly coupled code is. Two pieces of code are coupled if they can only be understood by looking at both pieces
Testable code is better code for a number of reasons, but one of them is decoupling
This is the first pressure we're talking about, and it's a good one!
Business logic has consequences! User's lives can be affected or ended based on our code.
Canonical reference: Therac-25. Every programmer should look this up.
Business logic is the most important code in your application
This is where Design Pressure comes into play.
Why do we write software?
We write software to achieve a goal using tools. The core of what we're trying to accomplish is the "Business logic"
Business logic is the code that processes the data coming in to you application and does something with it to solve business needs
Starting with a hottake: ORMs and validation frameworks ruin your projects!
That's a hook to wake up the audience, what's the real story?
The _unreflected_ use of the above ruins a project.
We're not here to tell you to stop using your favorite tool. The emphasis is _unreflected_
It's time for another "Phildini liveblogs talks that already happened", this time being @hynek's #PyConUS talk:
Design Pressure: The Invisible Hand That Shapes Your Code
There will be more of these threads! I plan to go through a reasonable chunk of the #PyCon2025/#PyConUS videos from this year.
If you enjoyed this, the best way to support me right now is supporting @civicband, the civic transparency non-profit, which you can do at https://opencollective.com/civicband
✨
Common gotcha: trying to raise one Exception from an ExceptionGroup loses a bunch of the traceback and context! Treat ExceptionGroups like ExceptionGroups, not Exceptions.
ExceptionGroups don't have great tooling at the moment, and there are active PEPs to improve that.
Also new in #python 3.11 is the `except*` syntax.
except* can catch a bare error or the subset of an exception group that matches the types specified.
except* _always_ catches an ExceptionGroup, even if it's a single error specified
ExceptionGroups are designed for situations where multiple things went wrong concurrently.
They have: a message, and a list of other exceptions/exception groups
One example: testcase teardown. The teardown _must_ succeed, but you still want to know all the errors. This way, you can collect them and print them all at the end!
`err.add_note("note...")` can add more detail to an exception as it's going by, and you can then re-raise it if needed.
Very cool, the notes are just printed after the exception.
Now: exception groups.
