Tony Nelson writes:
> > > Custom code to extract a single header one time to send to someone?
> >
> >That is precisely why we want a simple readable short elegant API.
> >
> >Like str(msg['To']).
>
> Would that return the display-name (friendly name) for the listed mailboxes
> in one string, presumbably separated by commas? How would you get the
> addr-specs? How would you get both? Use bytes() to flatten all the data,
> or just the addr-specs?
Who knows? Who cares? AFAICS it's a SMOP. Are we not hackers?
We'll design the internal representation to be lossless, then flatten
it out in a simple, straightforward way, as a newline-less,
comma-separated string. The question at issue here is "how does an
email client request flattening to bytes? to str?" Not "how does
email do those things?"
> I was a bit sloppy. The tuples would be character string, byte string: in
> 2.x, unicode and string; in 3.x, string and bytes. Flattening to bytes
> (2.x: string) for export would be ._flatten().
You're still being sloppy. In this part of the thread we were talking
about a *text* representation ("extract a single header ... to send to
someone", where the header in question is intended to be
human-readable). Why are we suddenly using bytes?
> In practice, the display-names and addr-specs may have had "defects" when
> parsing the message.
So what? That is, yes, we all already know that, and you don't need
to repeat it unless you're going to tell us something new. Like, how
are we going to represent the choice of how to deal with them in the
API? What choices are we going to offer?
> You wouldn't like
>
> for name, addr in msg['To'] + msg['Cc'] + msg['Bcc']:
>
> instead?
Not necessarily, because that requires me to special-case situations
where name is None, at least, and maybe cases where addr is None (that
depends on what the parser does with a header like
To: m...@home.com, , y...@earth.li
of course.)
> >...People (by which I mean nobody participating
> >in this thread) think of email as text. ...
>
> No, they don't.
Will you please cut this out? Everything you say is true. The
problem is that you are inconsistently choosing half-truths for the
purpose of winning a debate, rather than trying to design a coherent
API. The latter is the purpose of this SIG, not the former.
I do not have a lot of confidence that I'm *right*. However, the idea
that bytes(object) gives wire format, str(object) gives a simple text
presentation, and more complex presentation requires either massaging
str(object) or direct access to the internal representation of object
is a unifying theme in my (so far partial) proposal.
You have no unity, just confidence that your API for Headers that are
structured as address lists is "right". If you continue with that
approach on a Header type by Header type basis, experience suggests
that you *will* end up with a horrid API.
> >What we need to do is come up with an API that respects all of those
> >aspects *simultaneously*, and allows us to elegantly but accurately
> >change the perspective we use to view this "whatever-it-really-is".
>
> That's why my proposal is so good, as it does this.
But only for the To: header. There's no generality to it, you will
propose a different representation for the "useful data" of other
headers, and you still don't deal with the fact that what's useful to
you may not serve the needs of others.
> >Hm. And here I was hoping that the email package would *implement*
> >the low level, leaving me free to think about high-level things.
>
> You have that now, and it is terribly hard to use.
So let's fix the implementation to be easy to use. I see no proof whatsoever
>
>
> > > When one does not understand, then the email package should lead
> > > the user in the right direction.
> >
> >No, thank you. Python is a double-opt-in language. We're all
> >consenting adults here. Programmers who don't understand the RFCs are
> >likely to be surprised in many places, but they asked for it, they got
> >it.
>
> Battery materials included! Build your own batteries if you can learn how!
> Some have done it in as little as two years.
>
> There are other languages competing with Python, and users can choose to
> use them instead. Python's email package needs to stop requiring years of
> study to use correctly.
The API you propose will require such study, I'm pretty sure. If you
want to convince me otherwise (and I believe I'm representative in
this), you need to show how your approach will lead to regularity and
coherence in the API for *all* headers, not just the example-du-jour.
_______________________________________________
Email-SIG mailing list
Email-SIG@python.org
Your options:
http://mail.python.org/mailman/options/email-sig/archive%40mail-archive.com
