[Email-SIG] [Python-Dev] email package status in 3.X

[lutz at rmi.net]

Replying en masse to save bandwidth here...

Barry Warsaw <barry at python.org> writes:
> We know it, we have extensively discussed how to fix it, we have IMO a good
> design, and we even have someone willing and able to tackle the problem.  We
> need to find a sufficient source of funding to enable him to do the work it
> will take, and so far that's been the biggest stumbling block.  It will take a
> focused and determined effort to see this through, and it's obvious that
> volunteers cannot make it happen.  I include myself in the latter category, as
> I've tried and failed at least twice to do it in my spare time.

All understood, and again, not to disparage anyone here.  My 
comments are directed to the development community at large
to underscore the grave p/r problems 3.X faces.

I realize email parsing is a known issue; I also realize that
most people evaluating 3.X today won't care that it is.  Most
will care only that the new version of a language reportedly 
used by Google and YouTube still doesn't support CGI uploads 
a year and a half after its release.  As an author, that's a 
downright horrible story to have to tell the world.


"Stephen J. Turnbull" <stephen at xemacs.org> writes:
> Email, of course, is a big wart.  But guess what?  Python 2's email
> module doesn't actually work! 

Yes it does (see next point).

> If you live in Kansas, sure, you can concentrate on dodging tornados
> and completely forget about Unicode and MIME and text/bogus content.
> For the rest of the world, though, the problem is not Python 3

Yes it is, and Kansas is a lot bigger than you seem to think.

I want to reiterate that I was able to build a feature rich
email client with the email package as it exists in 3.1.  This
includes support on both the receiving and sending sides for HTML,
arbitrary attachments, and decoding and encoding of both text 
payloads and headers according to email, MIME, and Unicode/I18N
standards.  It's an amazingly useful package, and does work as is
in 3.X.  The two main issues I found have been recently fixed.  
It's unfortunate that this package is also the culprit behind CGI
breakage, but it's not clear why it became a critical path for so
much utility in the first place.

The package might not be aesthetically ideal, but to me it 
seems that an utterly incompatible overhaul of this in the name
of supporting potentially very different data streams is a huge
functional overload.  And to those people in Kansas who live 
outside the pydev clique, replacing it with something different 
at this point will look as if an incompatible Python is already 
incompatible with releases in its own line.  Why in the world 
would anyone base a new project on that sort of thrashing?

For my part, I've had to add far too many notes to the upcoming
edition of Programming Python about major pieces of functionality
that worked in 2.X but no longer do in 3.X.  That's disappointing
to me personally, but it will probably seem a lot worse to the
book's tens of thousands of readers.  Yet this is the reality 
that 3.X has created for itself.

> Should Python 3 have been held back until email was fixed?  Dunno, but
> I personally am very glad it was not; where I have a choice, I always
> use Python 3 now, and have yet to run into a problem. 

I guess we'll just have to disagree on that.  IMHO, Python 3 shot
itself in the foot by releasing in half-baked form.  And the 3.0 
I/O speed issue (remember that?) came very close to blowing its 
leg clean off.

The reality out there in Kansas today is that 3.X is perceived as 
so bad that it could very well go the way of POP4 if its story does
not improve.  I don't know what sort of Python world will be left
behind in the wake, but I do know it will probably be much smaller.


Steve Holden <steve at holdenweb.com> writes:
> Lest the readership think that the PSF is unaware of this issue, allow
> me to point out that we have already partially funded this effort, and
> are still offering R. David Murray some further matching funds if he can
> raise sponsorship to complete the effort (on which he has made a very
> promising start).
> 
> We are also attempting to enable tax-deductible fund raising to increase
> the likelihood of David's finding support. Perhaps we need to think
> about a broader campaign to increase the quality of the python 3
> libraries. I find it very annoying that the #python IRC group still has
> "Don't use Python 3" in it's topic.  They adamantly refuse to remove it
> until there is better library support, and they are the guys who see the
> issues day in day out so it is hard to argue with them (and I don't
> think an autocratic decision-making process would be appropriate).

I'm all for people getting paid for work they do, but with all
due respect, I think this underscores part of the problem in 
the Python world today.  If funding had been as stringent a 
prerequisite in the 90s, I doubt there would be a Python today.
It was about the fun and the code, not the bucks and the 
bureaucracy.  As far as I can recall, there was no notion of 
creating a task force to get things done.

Of course, this may just be the natural evolutionary pattern of 
human enterprises.  As it is today, though, the Python community 
has a formal diversity statement, but it still does not have a 
fully functional 3.X almost two years after the fact.  I doubt
that I'm the only one who sees the irony in that.

Again, I mean no disrespect to people contributing to Python 
today on so many fronts, and I have no answers to offer here. 
For better or worse, though, this is a personal issue to me too.
After spending much of the last 2 years updating the best selling 
Python books for all the changes this group has seen fit to make, 
I believe I can say with some authority that 3.X still faces a
very uncertain future.

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