[Email-SIG] email breakage in 3.2 alpha

[lutz at rmi.net]

Truthfully, the tone of your reply illustrates much of my point.
I made the book's dependence on 3.1 email as clear as could be,
both in June and in later exchanges.  I did so for the sake of 100K
flesh-and-blood Python users, and seem to have come up short.  If
Python developers don't work for their users, who do they work for?

But you gotta do what you gotta do, and so do I.  So let's stick
to the constructive here.  I hope that you will keep the book's 
deep dependence on email in mind in future work; not for my sake, 
but for its readers, a user base clearly large enough to matter.

And for the sake of Python 3 itself, can we at least agree to not 
make further changes to the email package until after 3.2 is out?
I went to the trouble of porting from 3.1 to 3.2 alpha3, and would 
hate to have to tell the world that the pace of Python change is 
so brisk that stability cannot be relied on for even a few weeks. 

--Mark Lutz  (http://learning-python.com, http://rmi.net/~lutz)


> -----Original Message-----
> From: "R. David Murray" <rdmurray at bitdance.com>
> To: lutz at rmi.net
> Subject: Re: email breakage in 3.2 alpha
> Date: Mon, 08 Nov 2010 15:35:32 -0500
> 
> On Thu, 04 Nov 2010 12:56:34 -0000, lutz at rmi.net wrote:
> > Actually, nevermind.  I have to submit the QC book review to O'Reilly
> > today, so I must assume that the email changes in 3.2 are immutable
> > at this point.
> >
> > To accommodate, I made a last minute patch to the book and its examples
> > package, to special-case the mail sender's workaround code for the fact
> > that 3.2 now returns str instead of bytes:
> 
> There is no reason we should withdraw that fix.  It is a bug fix, and
> makes the code work as documented.  There are times when we don't fix
> bugs in a maintenance release because to fix it would break a significant
> amount of code "in the field" that depends on the bug being present,
> but such a consideration is given less weight for a major release.
> Otherwise we'd have to live with stupid bugs forever, and that would
> not be a service to our users.  As it is, "less weight" is not "no
> weight", and we do live with an awful lot of stupid bugs (especially
> design bugs) due to such considerations.
> 
> In this case, because the bug is so obviously a bug that no one should
> depend on it not getting fixed, the fix was also backported to 3.1 and
> will appear in 3.1.3.  You may consider this as putting a burden on
> the users, but we view it as *serving* the users:  making the code work
> as designed and documented...in other words, fulfilling the promise
> made by our documentation.
> 
> I told you that the fix would appear in 3.2 and 3.1.3 back at the
> beginning of June when I fixed it.  In fact, I made a specific effort
> to get that bug fixed well in advance of our projected release dates so
> that you would be able to reference it in your book.
> 
> A good strategy for you to have followed, when you found this bug while
> writing the program for your book, would have been to submit a bug report,
> and then have written your code from the start to work whether or not the
> bug was fixed, so that when it was fixed your code would continue to work.
> 
> > ..
> > text = msgobj.get_payload()       # bytes fails in email pkg on text gen
> > if isinstance(text, bytes):       # payload is bytes in 3.1, str in 3.2 alpha
> >     text = text.decode('ascii')   # decode to unicode str so text gen works
> > ..
> > 
> > With this, sends work under 3.2 too.  The workaround must still split up 
> > the base64 data into lines, though, or else emails send with one massive
> > line which does not play well with many text tools.  Other 3.2 "fixes" 
> 
> It would have been helpful if you had reported this bug in the tracker
> (and it would still be helpful).  I will take a look and see if I can
> reproduce it.
> 
> > seem to be compatible with my workarounds so far (at least with the 
> > limited testing I've been able to do).
> 
> Thanks for the testing and the report.
> 
> > In the end, this wasn't a big change on my end, though patching code 
> > in books just before publication is very error-prone.  The bigger 
> > issue to me is that Python core developers seems a bit too inclined
> > to delegate the consequences of their actions to their users.  I don't
> > mean this personally; it's a group-wide attitude that has escalated in
> > recent years.  In this case, it was left to me to accommodate recent
> > changes, or they would have broken a new 3.X book's major example.
> 
> Well, there are *always* changes in a major release.  We do try
> to minimize backward compatibility problems, but there is no perfect
> world.
> 
> > More to the point: if a fix made in the name of aesthetics breaks
> > working code, is it really a fix?  I don't think so, and perhaps 
> > we'll have to agree to disagree, but I hope this case serves as 
> > a data point for future email changes.
> 
> I suppose that depends on your definition of aesthetics.  To me this
> was not a matter of aesthetics, but of code not working as designed or
> documented.  I stand behind my decision to implement this fix; so, yes,
> I suppose we will just have to agree to disagree.
> 
> --
> R. David Murray                                      www.bitdance.com
>