#36383: Improve migration serialization of functools.partial and
functools.partialmethod
-------------------------------------+-------------------------------------
Reporter: Adam Johnson | Type:
| Cleanup/optimization
Status: new | Component:
| Migrations
Version: dev | Severity: Normal
Keywords: | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Currently, the migration serialization framework serializes
`functools.partial()` and `functools.partialmethod()` in a quite
confusing, hard-to-read way. For example, a source object constructed
with:
{{{#!python
functools.partial(datetime.timedelta, 1, seconds=2)
}}}
…is serialized as:
{{{#!python
functools.partial(datetime.timedelta, *(1,), **{'seconds': 2})
}}}
The source includes unnecessary unpacking of a tuple into positional
arguments and a dict into keyword arguments.
The tuple and dict are included even when arguments are empty, for
example:
{{{#!python
functools.partial(int)
}}}
…is serialized as:
{{{#!python
functools.partial(int, *(), **{})
}}}
The result is quite a advanced Python syntax, the kind that I believe
deters people from inspecting and understanding their migration files.
It seems partial serialization has been like this since support was added
in #25185.
I propose that we reuse the logic for deconstructible objects.
While working on this ticket, I realized one gap in this idea: the `**{}`
syntax allows keyword arguments that are not Python identifiers, but that
is not supported by the current deconstructable serialization. Therefore,
the associated PR also adds support for that.
--
Ticket URL: <
https://code.djangoproject.com/ticket/36383>
Django <
https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.