because bytes was really str in xthoughbecause base returns bytesthe normal mail encoder in email also leaves the payload as byteseven though it' been encoded to base text form this in turn breaks email text generationbecause it assumes the payload is text in this caseand requires it to be str as is common in large-scale software systemsthe effects of some changes may have been difficult to anticipate or accommodate in full by contrastparsing binary attachments (as opposed to generating text for themworks fine in xbecause the parsed message payload is saved in message objects as base encoded str stringnot bytesand is converted to bytes only when fetched this bug seems likely to also go away in future python and email package (perhaps even as simple patch in python )but it' more serious than the other unicode decoding issues described herebecause it prevents mail composition for all but trivial mails the flexibility afforded by the package and the python language allows such workaround to be developed external to the packagerather than hacking the package' code directly with open source and forgiving apisyou rarely are truly stuck late-breaking newsthis section' bug is scheduled to be fixed in python making our workaround here unnecessary in this and later python releases this is per communications with members of python' email special interest group (on the "email-sigmailing listregrettablythis fix didn' appear until after this and its examples had been written ' like to remove the workaround and its description entirelybut this book is based on python both before and after the fix was incorporated so that it works under python alphatoothoughthe workaround code ahead was specialized just before publication to check for bytes prior to decoding moreoverthe workaround still must manually split lines in base databecause still does not workaroundmessage composition for non-ascii text parts is broken our final email unicode issue is as severe as the prior onechanges like that of the prior section introduced yet another regression for mail composition in shortit' impossible to make text message parts today without specializing for different unicode encodings some types of text are automatically mime-encoded for transmission unfortunatelybecause of the str/bytes splitthe mime text message class in email now requires different string object types for different unicode encodings the net effect is that you now have to know how the email package will process your text data when making text message objector repeat most of its logic redundantly for exampleto properly generate unicode encoding headers and apply required mime encodingshere' how we must proceed today for common unicode text typesemailparsing and composing mail content