Python is a general-purpose language whose readability makes it possible to express a rule quickly, but that apparent simplicity does not remove the need to design data structures, assign responsibilities, and handle errors.
Technical skillsIntermediate
I
Definition
Python is a general-purpose language whose readability makes it possible to express a rule quickly, but that apparent simplicity does not remove the need to design data structures, assign responsibilities, and handle errors. I use it mainly in Odoo, where it powers ORM models, computed fields, constraints, scheduled actions, controllers, migration scripts, and tests. The code runs within a rich framework: understanding inheritance, decorators, recordsets, and context is as important as knowing the language syntax.
My practice aims for explicit business code. I separate settings from algorithms, avoid fixed values, operate on recordsets rather than volume assumptions, and account for transactions and permissions. When documentation is insufficient, I read standard implementations to identify the method actually called and reproduce the pattern expected by the Odoo version in use.
I also follow language evolution, while distinguishing Python innovations from what is available and relevant in the ERP's specific environment. A recent feature is valuable only when it remains compatible with the product's runtime, conventions, and migration cycle.
Python 3.14 officially supported free-threaded mode and added deferred annotations, template strings, and multiple interpreters in the standard library. Following these changes helps distinguish new language capabilities from what remains compatible with Odoo's specific runtime constraints.
The overdue-reminder module uses Python to select invoices, calculate their position relative to the due date, apply exclusions, and trigger the action matching the current stage. Early values were too fixed. I restructured the code so intervals, email templates, recipients, attachments, and blocking thresholds come from configuration. The algorithm retains responsibility for applying the rule, while authorized users select business values from Odoo.
Result — Daily processing automatically covers the relevant invoices. The code can evolve without duplicating a module version for every accounting rule; the time savings remain to be measured.
Between Odoo 16 and Odoo 19, methods, models, fields, and signatures changed. I reviewed internal modules at each intermediate release, identified calls that had become invalid, searched for new implementations in the source code, and adapted scripts when data had to be transformed. Progressing from 16 to 17, 17 to 18, and then 18 to 19 avoided combining three possible causes in the same error and made each fix attributable to a specific change.
Result — The sixteen useful modules were retained on Odoo 19 and the ERP restarted with no permanent data loss. This migration strengthened my ability to read Python written by other developers and distinguish a framework incompatibility from a local business error.
Margin calculation and certain accounting views required me to go beyond the module's own code. I traced computed fields, dependencies, and ORM calls to identify what triggered expensive recomputation. For security matters, I checked groups, ACLs, and record rules at model and record level instead of relying on a hidden menu. This framework investigation remains cautious: I favor controlled extension over direct modification of the standard engine, which would complicate official fixes and future migrations.
Result — Margin indicators are available during the financial year, and permissions remain handled through Odoo's intended mechanisms. Performance still needs improvement, but optimization is being conducted through measurement without weakening the standard engine.
The evidence items describe specific episodes. This synthesis places them back in the complete case studies: context, my contribution, and outcome show what this skill made possible, while keeping the appropriate level of caution for each result.
In summer 2025, 1UP Distribution's Odoo 16 ERP, used by 20 internal users, needed to move beyond its support period with 16 custom modules and third-party extensions.
My contribution
I independently handled preparation, the three successive migrations, testing, production release, and post-cutover fixes.
Established outcome
The ERP and required modules were migrated to Odoo 19 while preserving data, useful business functions, and the intended service continuity.
I independently designed 16 Odoo modules, from requirements analysis through development, testing, deployment, and user support.
Established outcome
The modules automate business tasks, structure shared data, and make functions such as reminders, documents, and B2B synchronization manageable within the ERP.
I assess myself as intermediate. I use Python daily for modules, migrations, APIs, and scheduled tasks, and I can read framework portions to diagnose a problem. My experience remains strongly concentrated on Odoo; I still need to deepen language use outside ERP, typing, asynchronous programming, and more advanced profiling tools.
b.
Importance in my profile
Python is the central language of my Odoo specialization. Improving in the language directly improves the quality of my models, integrations, and diagnostics, while also helping me distinguish general good practices from framework-specific conventions.
c.
Hindsight and advice
My advice is not to learn Python in Odoo solely by imitating existing modules. Recordsets, decorators, and transactions must be understood, then patterns verified in the standard code of the target release. Readable Python can still be expensive or incorrect if it ignores how the ORM loads, computes, and secures records.
Reach an advanced level by consolidating typing, testing, profiling, and internal language mechanisms, then applying that knowledge to Python projects beyond Odoo alone.
b.
Current or upcoming training
I continue reading Odoo source code and open-source Python projects, as well as studying language evolution. The future Business Intelligence service should provide a complementary setting for working with data processing, APIs, and observability in Python.