Stephen J. Turnbull <stephen <at> xemacs.org> writes: > > I hate to break it to you, but most stages of mail processing have > very little to do with SMTP. In particular, processing MIME > attachments often requires dealing with file names.
AFAIK, the file name is only there as an indication for the user when he wants to save the file. If it's garbled a bit, no big deal. > The point is that Martin's proposal is not just a solution > to the problem he posed. But you haven't concretely demonstrated it with actual use cases. The problems that the PEP tries to solve, conversely, /have/ been experienced. > And the APIs won't be killable until > Python 4000. Which APIs? The PEP doesn't propose any new API, it just enhances the implementation of current APIs so that they work out of the box in all cases. > Specifically, if the return values were bytes, ... it would make Windows support worse. > or (better for 2.x, > where bytes are strings as far as most programmers are concerned) as a > new data type, I'm -1 on any new string-like type (for file paths or whatever else) with custom encoding/decoding semantics. It's the best way to ruin the clean str/bytes separation that 3.x introduced. Besides, the goal is also to makes things easier for the programmer. Otherwise, we'll have the same situation as in 2.x where many English-centric programmers produced code that was incapable of dealing with non-ASCII input, because they didn't care about the distinction between str and unicode. Regards Antoine. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
