Steven D'Aprano writes:
> I don't think anyone has ever suggested change for change's sake. If
> they have, I'd love to read the PEP for it.
Not to mention the BDFL's pronouncement message!
___
Python-Dev mailing list
Python-Dev@python.org
http://mai
On Wed, 13 Oct 2010 03:01:57 am l...@rmi.net wrote:
> So my point is just this: Change for change's sake is truly not
> what most Python users want. If Python core developers want 3.X
> to become as popular as 2.X, they should be less concerned with
> posts on this list or hands at a conference, t
rmi.net/~lutz)
> Date: Fri, 8 Oct 2010 14:20:32 -0400
> From: Barry Warsaw
> To: python-dev@python.org
> Subject: Re: [Python-Dev] Patch making the current email package (mostly)
> support bytes
>
> On Oct 08, 2010, at 03:44 PM, l...@rmi.net wrote:
>
> >Ultimately,
Barry Warsaw writes:
> On Oct 09, 2010, at 02:48 AM, Stephen J. Turnbull wrote:
>
> >Right. That's where I was going with my comment to Barry about the
> >Received headers. Even if email isn't going to serve clients working
> >with wire format, it needs to deal with those headers. But wher
On Sat, 09 Oct 2010 02:48:23 +0900, "Stephen J. Turnbull"
wrote:
> R. David Murray writes:
> > On Sat, 09 Oct 2010 01:06:29 +0900, "Stephen J. Turnbull"
> wrote:
> > > That mess is entirely unnecessary in Python 3. Text and wire format
> > > can be easily distinguished with three different
On Oct 09, 2010, at 02:48 AM, Stephen J. Turnbull wrote:
>Right. That's where I was going with my comment to Barry about the
>Received headers. Even if email isn't going to serve clients working
>with wire format, it needs to deal with those headers. But where I
>think the headers defined by RF
On Oct 08, 2010, at 03:44 PM, l...@rmi.net wrote:
>Ultimately, development in the open source world is driven by the
>very few with time to show up, rather than by the very many who
>depend on it. This can unfortunately lead to the perception
>of thrashing by end users. Some even come to see t
R. David Murray writes:
> On Sat, 09 Oct 2010 01:06:29 +0900, "Stephen J. Turnbull"
> wrote:
> > That mess is entirely unnecessary in Python 3. Text and wire format
> > can be easily distinguished with three different representations of
> > email: Unicode for the conceptual RFC 822 layer (o
On Fri, 08 Oct 2010 12:37:38 +0900, "Stephen J. Turnbull"
wrote:
> *If* you have an 8-bit value of unknown encoding on input, this will
> appear in the Header's value as a surrogate. Hm, OK, I see the
> problem ... as usual, it's that the only efficient thing to do is
> encode using surrogate-es
On Fri, 08 Oct 2010 23:55:37 +0900, "Stephen J. Turnbull"
wrote:
> I should think you *want* addresses and suchlike structured headers
> (Content-Type with several RFC 2231 parameters, anyone?) to line up
> nicely, too. So generic folding algorithms are really only applicable
> to unstructured t
On Fri, 08 Oct 2010 15:44:45 -, l...@rmi.net wrote:
> Thanks for both your reply and work, David. I'm going to have
> to test my email clients under the 3.2 patch when it gels. It's
> good to hear that email5 API support remains a goal.
I just landed the patch (though without the MIME encodi
On Sat, 09 Oct 2010 01:06:29 +0900, "Stephen J. Turnbull"
wrote:
> That mess is entirely unnecessary in Python 3. Text and wire format
> can be easily distinguished with three different representations of
> email: Unicode for the conceptual RFC 822 layer (of course this is an
> extension, becaus
On Fri, 08 Oct 2010 15:51:45 -, l...@rmi.net wrote:
> For my part, one week from now I'll be standing up again in front
> of a group of 20 Python beginners, and basically apologizing for
> both the present and ongoing 3.X changes they must conform to in
> the near future. Python may not be
Barry Warsaw writes:
> On Oct 07, 2010, at 04:40 AM, Stephen J. Turnbull wrote:
> I'm fairly certain that most of the modern causes of [Unicode
> errors in Mailman] are post-parse modifications of the message.
> IOW, in Mailman's architecture, we try to parse the raw data into a
> Message obj
t will break their code.
(Yes, sarcasm intended.)
--Mark Lutz (http://learning-python.com, http://rmi.net/~lutz)
> -Original Message-
> From: "Stephen J. Turnbull"
> To: l...@rmi.net
> Subject: Re: [Python-Dev] Patch making the current email package
> (most
ally given the still tentative state of 3.X, stability matters.
--Mark Lutz (http://learning-python.com, http://rmi.net/~lutz)
> -Original Message-
> From: "R. David Murray"
> To: l...@rmi.net
> Subject: Re: [Python-Dev] Patch making the current email package (mo
Barry Warsaw writes:
> Header wrapping sucks even more because it's supposed to take the
> semantic context into account, which means that a generic Header
> wrapping algorithm cannot work for everything. E.g. Received:
> headers are supposed to wrap after the semicolon.
Received headers are
On Oct 08, 2010, at 12:37 PM, Stephen J. Turnbull wrote:
>Ouch. RFC 822 line wrapping is a bytes->bytes transformation, and the
>client shouldn't see it at all unless it inspects the wire format.
Header wrapping sucks even more because it's supposed to take the semantic
context into account, whi
l...@rmi.net writes:
> To put that more strongly, the Python user base is much larger than
> this list's readership.
Agreed. Nevertheless, this is the channel (not "channel") that the
developers listen on, and substantial effort is made to let Python
users know that. I think they do know it,
R. David Murray writes:
> > The MIME-charset = UNKNOWN dodge might be a better way of handling
> > this.
>
> That is a very interesting idea. It is the *right* thing to do, since it
> would mean that a message parsed as bytes could be generated via Generator
> and passed to, say, smtplib w
On Oct 07, 2010, at 04:40 AM, Stephen J. Turnbull wrote:
> > And the email API currently promises not to raise during parsing,
> > which is a contract my patch does not change.
>
>Which is a contract that has historically been broken frequently.
>Unhandled UnicodeErrors have been one of the most c
On Thu, 07 Oct 2010 16:03:18 -, l...@rmi.net wrote:
> I'm forwarding a link to the code of these clients to David by
> private email in case they might be useful as a test case (O'Reilly
> has already posted them ahead of the book, but they may be a bit too
> heavy for use in formal testing).
Stephen J. Turnbull wrote (giving me an opening to jump in here):
> R. David Murray writes:
> > In other words, my proposed patch only makes email5 1/8 to 1/4
> > broken, instead of half broken as it is now. But not un-broken
> > enough for Mailman, it sounds like.
>
> IMO, not in the long run. B
On Thu, 07 Oct 2010 15:00:04 +0900, "Stephen J. Turnbull"
wrote:
> R. David Murray writes:
>
> > > But that's not interesting; you did that with Python 3. We want to
> > Of course I did it with Python3. It's the Python3 email codebase
> > I'm working with (and have to work *around*).
>
> S
Stephen J. Turnbull xemacs.org> writes:
> R. David Murray writes:
> > We're (in the current patch) not punting on handling non-conforming
> > email, we're punting on handling non-conforming bytes *if the headers
> > that contain them need to be modified*. The headers can still be
> > modified
On Thu, 07 Oct 2010 03:31:34 +0900, "Stephen J. Turnbull"
wrote:
> R. David Murray writes:
>
> > 5. Return the content, with non-ASCII bytes replaced with ?
> > characters.
>
> That hadn't occurred to me (and it makes me sick to contemplate it).
>
> That said, this is probably good enou
R. David Murray writes:
> So the only parsing issue is if Mailman cares about *the non-ASCII
> bytes* in the headers it cares about. If it has to modify headers that
> contain non-ASCII bytes (for example, addresses and Subject) and cares
> about preserving the non-ASCII bytes, then there is
R. David Murray writes:
> 5. Return the content, with non-ASCII bytes replaced with ?
> characters.
That hadn't occurred to me (and it makes me sick to contemplate it).
That said, this is probably good enough for Mailman-like apps to limp
along for "most" users. It's certainly good enoug
On Wed, 06 Oct 2010 22:55:00 +0900, "Stephen J. Turnbull"
wrote:
> R. David Murray writes:
>
> > version of headers to the email5 API, but since any such data would
> > be non-RFC compliant anyway, [access to non-conforming headers by
> > reparsing the bytes] will just have to be good enough
On Wed, 06 Oct 2010 12:22:18 +0900, "Stephen J. Turnbull"
wrote:
> Nick Coghlan writes:
>
> > - if you pass in bytes data and know what you are doing, then you can
> > access that raw bytes data and do your own decoding
>
> At what level, though?
>
> To take an interesting example I used to
R. David Murray writes:
> version of headers to the email5 API, but since any such data would
> be non-RFC compliant anyway, [access to non-conforming headers by
> reparsing the bytes] will just have to be good enough for now.
But that's potentially unpleasant for, say, Mailman. AFAICS, what
Nick Coghlan writes:
> - if you pass in bytes data and know what you are doing, then you can
> access that raw bytes data and do your own decoding
At what level, though?
To take an interesting example I used to see frequently:
From: t...@tokyo.jp
(Taro Yamada in 8-bit Shift JIS)
So I g
On Tue, 05 Oct 2010 22:05:33 +1000, Nick Coghlan wrote:
> On Tue, Oct 5, 2010 at 3:41 PM, Stephen J. Turnbull
> wrote:
> > R. David Murray writes:
> > > Only if the email package contains a coding error would the
> > > surrogates escape and cause problems for user code.
> >
> > I don't think it i
On Tue, Oct 5, 2010 at 3:41 PM, Stephen J. Turnbull wrote:
> R. David Murray writes:
> > Only if the email package contains a coding error would the
> > surrogates escape and cause problems for user code.
>
> I don't think it is reasonable to internalize surrogates that way;
> some applications
R. David Murray writes:
> On Mon, 04 Oct 2010 12:32:26 -0400, Scott Dial
> wrote:
> > On 10/2/2010 7:00 PM, R. David Murray wrote:
> > > The clever hack (thanks ultimately to Martin) is to accept 8bit data
> > > by encoding it using the ASCII codec and the surrogateescape error
> > > handle
On Oct 02, 2010, at 07:00 PM, R. David Murray wrote:
>The advantage of this patch is that it means Python3.2 can have an
>email module that is capable of handling a significant proportion of
>the applications where the ability to process binary email data is
>required.
Like others, I'm concerned
On Mon, 04 Oct 2010 12:32:26 -0400, Scott Dial
wrote:
> On 10/2/2010 7:00 PM, R. David Murray wrote:
> > The clever hack (thanks ultimately to Martin) is to accept 8bit data
> > by encoding it using the ASCII codec and the surrogateescape error
> > handler.
>
> I've seen this idea pop up in a nu
On 10/2/2010 7:00 PM, R. David Murray wrote:
> The clever hack (thanks ultimately to Martin) is to accept 8bit data
> by encoding it using the ASCII codec and the surrogateescape error
> handler.
I've seen this idea pop up in a number of threads. I worry that you are
all inventing a new kind of du
On Sun, Oct 3, 2010 at 9:00 AM, R. David Murray wrote:
> I do not propose that this is a *good* API, since it has the classic
> problem that if there are coding bugs in the email module strings may
> "escape" that have surrogates in them and we end up with programs that
> work most of the time
On Sat, 02 Oct 2010 19:15:57 -0500, Benjamin Peterson
wrote:
> 2010/10/2 R. David Murray :
> > Regardless of whether or not this patch or a descendant thereof is
> > accepted I still intend to continue working on email6. =C2=A0There are ma=
> ny
> > other bugs in the current email package that re
2010/10/2 R. David Murray :
> Regardless of whether or not this patch or a descendant thereof is
> accepted I still intend to continue working on email6. There are many
> other bugs in the current email package that require a rewrite of parts
> of its infrastructure, and the email-sig is agreed th
A while back on some issue or another I remember telling someone that
if there was any sort of clever hack that would allow the current email
package (email5) to work with bytes we would have implemented it.
Well, I've come up with a clever hack.
The idea came out of a conversation with Antoine.
42 matches
Mail list logo
