[Python-Dev] Polymorphic best practices [was: (Not) delaying the 3.2 release]
barry at python.org
Fri Sep 17 17:00:49 CEST 2010
On Sep 16, 2010, at 11:45 PM, Terry Reedy wrote:
>Based on the discussion so far, I think you should go ahead and
>implement the API agreed on by the mail sig both because is *has* been
>agreed on (and thinking about the wsgi discussion, that seems to be a
>major achievement) and because it seems sensible to me also, as far as
>I understand it. The proof of the API will be in the testing. As long
>as you *think* it covers all intended use cases, I am not sure that
>abstract discussion can go much further.
>I do have a thought about space and duplication. For normal messages,
>it is not an issue. For megabyte (or in the future, gigabyte?)
>attachments, it is. So if possible, there should only be one extracted
>blob for both bytes and string versions of parsed messages. Or even
>make the extraction from the raw stream lazy, when specifically
This has been discussed in the email-sig. Many people have asked for an API
where message payloads can be stored on-disk instead of in-memory. Headers, I
don't think will every practically be so big as to not be storable in-memory.
But if your message has a huge mp3, the parser should have the option to leave
the bytes of that payload in a disk cache and transparently load it when
I think we should keep that in mind, but it's way down on the list of "gotta
haves" for email6.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: not available
More information about the Python-Dev