= 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: 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) msgid_singular (needs explicit initialization to None if not present) msgid_plural (needs explicit initialization to None if not present) is_current (the recife work renames this to is_current_ubuntu) is_imported (the recife work renames this to is_current_upstream) ['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) 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.