Message Representations with __slots__
We have three classes for representing translatable messages and their translations on import/export:
TranslationMessageData
VPOExport
VPOTExport
These are close to C struct types: just dumb collections of data, without ORM backing. The VPOExport and VPOTExport ones are old and redundant; we should be using TranslationMessageData instead.
To figure out what's really in these classes, I tried adding __slots__ to them and running the test suite. The branch is lp:~jtv/launchpad/slots.
TranslationMessageData contains:
- context
- msgid_singular
- msgid_plural
- singular_text
- plural_text
- _translations
- comment
- source_comment
- file_references
- file_references_list
- flags
- sequence
- nplurals
- is_obsolete
VPOExport contains:
languagepack (may not be needed nowadays since we export one POFile at a time)
potemplate (may not be needed nowadays since we export one POFile at a time)
pofile (may not be needed nowadays since we export one POFile at a time)
- potmsgset_id
- potmsgset
- sequence
- context
msgid_singular (needs explicit initialization to None if not present)
msgid_plural (needs explicit initialization to None if not present)
- comment
- source_comment
- file_references
- flags_comment
is_current (the recife work renames this to is_current_ubuntu)
is_imported (the recife work renames this to is_current_upstream)
- diverged
['translation%d' for form in range TranslationConstants.MAX_PLURAL_FORMS]
VPOTExport contains:
potemplate (may not be needed nowadays since we export one POFile at a time)
- potmsgset
- sequence
- context
- msgid_singular
- msgid_plural
- comment
- source_comment
- file_references
- flags_comment
- template_header
On a sidenote, adding __slots__ may improve import/export performance a bit by avoiding Python's massive object-creation overhead, and this proves that it can be done.