Opened 4 months ago
Closed 4 months ago
#36383 closed Cleanup/optimization (fixed)
Improve migration serialization of functools.partial and functools.partialmethod
Reported by: | Adam Johnson | Owned by: | Adam Johnson |
---|---|---|---|
Component: | Migrations | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Ready for checkin | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
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:
functools.partial(datetime.timedelta, 1, seconds=2)
…is serialized as:
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:
functools.partial(int)
…is serialized as:
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.
Change History (7)
comment:1 by , 4 months ago
Owner: | set to |
---|---|
Status: | new → assigned |
comment:2 by , 4 months ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:3 by , 4 months ago
Triage Stage: | Accepted → Ready for checkin |
---|
Thank you for the suggestion. I think this is a desirable clean up which makes the serialization logic more consistent