On Apr 10, 2009, at 3:04 PM, Stephen J. Turnbull wrote:
Shouldn't this thread move lock stock and .signature to email-sig?
Yep. I'll try to be more conscientious about removing python-dev from
the CC.
Idempotency? I'm not sure what that means in the context of the
email package ...
At 10:11 -0400 04/13/2009, Barry Warsaw wrote:
On Apr 10, 2009, at 11:08 AM, James Y Knight wrote:
Until you write a parser for every header, you simply cannot decode
to unicode. The only sane choices are:
1) raw bytes
2) parsed structured data
The email package does not need a parser for
On Apr 9, 2009, at 11:59 PM, Tony Nelson wrote:
Thinking about this stuff makes me nostalgic for the sloppy happy
days
of Python 2.x
You now have the opportunity to finally unsnarl that mess. It is
not an
insurmountable opportunity.
No, it's just a full time job wink. Now where did I
On approximately 4/10/2009 9:56 AM, came the following characters from
the keyboard of Barry Warsaw:
On Apr 10, 2009, at 1:19 AM, gl...@divmod.com wrote:
On 02:38 am, ba...@python.org wrote:
So, what I'm really asking is this. Let's say you agree that there
are use cases for accessing a
On Apr 10, 2009, at 2:00 PM, Glenn Linderman wrote:
If one name has to be longer than the other, it should be the bytes
version. Real user code is more likely to want to use the text
version, and hopefully there will be more of that type of code than
implementations using bytes.
I'm not
On Apr 10, 2009, at 2:06 PM, Michael Foord wrote:
Shouldn't headers always be text?
/me weeps
PGP.sig
Description: This is a digitally signed message part
___
Email-SIG mailing list
Email-SIG@python.org
Your options:
Shouldn't this thread move lock stock and .signature to email-sig?
Barry Warsaw writes:
It does seem to make sense to think about headers as text header
names and text header values.
I disagree. IMHO, structured header types should have object values,
and something like
On Apr 9, 2009, at 11:55 AM, Daniel Stutzbach wrote:
On Thu, Apr 9, 2009 at 6:01 AM, Barry Warsaw ba...@python.org wrote:
Anyway, aside from that decision, I haven't come up with an elegant
way to allow /output/ in both bytes and strings (input is I think
theoretically easier by sniffing
On Apr 9, 2009, at 11:21 PM, Nick Coghlan wrote:
Barry Warsaw wrote:
I don't know whether the parameter thing will work or not, but you're
probably right that we need to get the bytes-everywhere API first.
Given that json is a wire protocol, that sounds like the right
approach
for json as
Barry Warsaw writes:
There are really two ways to look at an email message. It's either an
unstructured blob of bytes, or it's a structured tree of objects.
Indeed!
Those objects have headers and payload. The payload can be of any
type, though I think it generally breaks down into
10 matches
Mail list logo
