[Email-SIG] email breakage in 3.2 alpha

[R. David Murray]

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