Skills
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, responsibilities, and 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.
Read the source: Python Software FoundationThe 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 and saves around half a working day each week. The code can evolve without duplicating a module version for every accounting rule.
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.
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.
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.
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.
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.