On 9/18/2010 2:29 AM, python-dev-requ...@python.org wrote:
Polymorphic best practices [was: (Not) delaying the 3.2 release]
If you're hung up on this, try writing the user-level documentation
first. Your target audience is a working-level Web programmer, not
someone who knows six programmin
On Fri, Sep 17, 2010 at 3:25 PM, Michael Foord wrote:
> On 16/09/2010 23:05, Antoine Pitrou wrote:
>
>> On Thu, 16 Sep 2010 16:51:58 -0400
>> "R. David Murray" wrote:
>>
>>> What do we store in the model? We could say that the model is always
>>> text. But then we lose information about the or
On 16/09/2010 23:05, Antoine Pitrou wrote:
On Thu, 16 Sep 2010 16:51:58 -0400
"R. David Murray" wrote:
What do we store in the model? We could say that the model is always
text. But then we lose information about the original bytes message,
and we can't reproduce it. For various reasons (ma
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
On Sep 17, 2010, at 12:10 PM, Antoine Pitrou wrote:
>Also, I don't understand why an application would want to assemble an
>e-mail by itself if it doesn't know how to do so, and produces wrong
>data. Why not simply let the application do:
>
>m = Message()
>m.add_header("From", "Accented Bàrry ")
>
Le jeudi 16 septembre 2010 à 22:51 -0400, R. David Murray a écrit :
> > > On disk, using utf-8,
> > > one might store the text representation of the message, rather than
> > > the wire-format (ASCII encoded) version. We might want to write such
> > > messages from scratch.
> >
> > But then the us
R. David Murray a écrit :
I'm trying one approach in email6:
Bytes and String subclasses, where the subclasses have an attribute
named 'literals' derived from a utility module that does this:
literals = dict(
empty = '',
colon = ':',
newline = '\n',
space = '
On Thu, 16 Sep 2010 23:45:12 -0400, 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 beca
On Thu, 16 Sep 2010 21:53:17 -0400, Barry Warsaw wrote:
> And of course, what happens if the original subject is in one charset and the
> prefix is in an incompatible one? Then you end up with a wire format of two
> RFC 2047 encoded words separated by whitespace. You have to keep those chunks
>
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. Th
On Fri, 17 Sep 2010 00:05:12 +0200, Antoine Pitrou wrote:
> On Thu, 16 Sep 2010 16:51:58 -0400
> "R. David Murray" wrote:
> >
> > What do we store in the model? We could say that the model is always
> > text. But then we lose information about the original bytes message,
> > and we can't reprod
On Fri, 17 Sep 2010 11:34:26 am R. David Murray wrote:
> Perhaps another difference is that in my mind *as an application
> developer*, the "real" email message consists of unicode headers and
> message bodies, with attachments that are sometimes binary, and that
> the wire-format is this formalize
On Sep 16, 2010, at 09:34 PM, R. David Murray wrote:
>Say we start with this bytes input:
>
>To: Glyph Lefkowitz
>From: "R. David Murray"
>Subject: =?utf-8?q?p=F6stal?=
>
>A simple message.
>
>Part of the responsibility of the email module is to provide that
>in text form on dema
On Thu, 16 Sep 2010 18:11:30 -0400, Glyph Lefkowitz
wrote:
> On Sep 16, 2010, at 4:51 PM, R. David Murray wrote:
>
> > Given a message, there are many times you want to serialize it as text
> > (for example, for presentation in a UI). You could provide alternate
> > serialization methods to get
On Sep 16, 2010, at 7:34 PM, Barry Warsaw wrote:
> On Sep 16, 2010, at 06:11 PM, Glyph Lefkowitz wrote:
>
>> That may be a handy way to deal with some grotty internal
>> implementation details, but having a 'decode()' method is broken. The
>> thing I care about, as a consumer of this API, is th
On Sep 16, 2010, at 06:11 PM, Glyph Lefkowitz wrote:
>That may be a handy way to deal with some grotty internal
>implementation details, but having a 'decode()' method is broken. The
>thing I care about, as a consumer of this API, is that there is a
>clearly defined "Message" interface, which giv
On Sep 16, 2010, at 4:51 PM, R. David Murray wrote:
> Given a message, there are many times you want to serialize it as text
> (for example, for presentation in a UI). You could provide alternate
> serialization methods to get text out on demandbut then what if
> someone wants to push that te
On Thu, 16 Sep 2010 16:51:58 -0400
"R. David Murray" wrote:
>
> What do we store in the model? We could say that the model is always
> text. But then we lose information about the original bytes message,
> and we can't reproduce it. For various reasons (mailman being a big one),
> this is not a
On Thu, 16 Sep 2010 17:40:53 +0200, Antoine Pitrou wrote:
> On Thu, 16 Sep 2010 11:30:12 -0400
> "R. David Murray" wrote:
> >
> > And then BaseHeader uses self.lit.colon, etc, when manipulating strings.
> > It also has to use slice notation rather than indexing when looking at
> > individual cha
On Thu, 16 Sep 2010 11:30:12 -0400
"R. David Murray" wrote:
>
> And then BaseHeader uses self.lit.colon, etc, when manipulating strings.
> It also has to use slice notation rather than indexing when looking at
> individual characters, which is a PITA but not terrible.
>
> I'm not saying this is
On Thu, 16 Sep 2010 09:52:48 -0400, Barry Warsaw wrote:
> On Sep 16, 2010, at 11:28 PM, Nick Coghlan wrote:
> >There are some APIs that should be able to handle bytes *or* strings,
> >but the current use of string literals in their implementation means
> >that bytes don't work. This turns out to b
21 matches
Mail list logo
