On Fri, 10 Jun 2011 19:00:32 +0200, <mer...@netwok.org> wrote:
> The first cent is about subclassing builtins. I read in your article
> that your code uses subclasses of str and list; canât that lead to
> problems caused by fast paths for built-in types in CPython code? (if I
> understand http://bugs.python.org/issue10977 correctly)
The problems there arise from C code calling (or, rather, not calling)
methods on the subclass. But in email headers act *just like* strings,
but they have *extra* methods. So there should be no problem. Anything
that doesn't know about the extra methods will treat the header just
like a string, which is exactly what we want for backward compatibility
reasons.
The one place where this might bite us is in the proposed support for +=
and -=. I haven't tested that yet, and if it does work I'm not sure
that there won't be obscure corners in which will turn out to be broken.
> The second cent is about naming. Does a Mailbox represent an email
> address? The confusion with mailbox.Mailbox would be a problem.
Well, that is an issue. I'm not entirely happy about the name, but I
haven't thought of a better one. The problem is that we have to deal
both with a full 'mailbox' and the 'addr-spec' subpart, and I don't know
of *any* other name (other than 'addr-spec') for the addr-spec part.
(Well, 'address', but you can see the problem with using that for both
meanings...) Perhaps it would be better to use that (or rather
addr_spec), and use 'address' for the address-with-display-name
('mailbox').
I'm open to suggestions for better naming in the API.
> Dare I say it? PEP 8 would advise rfc822parser for the name, or parser
> (but I donât know how you plan to deprecate/replace the existing
> email.parser module).
Good point. rfc822parser is completely distinct from 'parser', which
probably won't get deprecated. On the other hand, once I add RFC2047
support to it, perhaps I should rename it rfcparser (or, at least at
first, _rfcparser). Or perhaps _headerparser, though it doesn't
contain *all* of the header parsing machinery.
> Iâm sorry for your family stuff.
Thanks.
--
R. David Murray http://www.bitdance.com
_______________________________________________
Email-SIG mailing list
Email-SIG@python.org
Your options:
http://mail.python.org/mailman/options/email-sig/archive%40mail-archive.com
