On Oct 9, 2009, at 2:26 AM, Glenn Linderman wrote:
Then the Postel principle is un-Pythonic, and to be Pythonic any incorrect email should produce an error, and be unreadable. Again, I mentioned producing a defect report. That is not passing an error silently.
There's no conflict between principles here if you keep clear in your mind the two different patterns we're talking about. When parsing raw data, we soldier on in the face of errors as best we can, never raising exceptions, but recording defects. When manipulating the model, we throw exceptions as early as possible because these are application errors and the client controls the application.
The un-Pythonic thing is returning defect reports instead of raising errors. There is no way for a simple assignment interface to return an error, because the API for simple assignment doesn't have an in- band signaling mechanism.
This "assignment interface" falls under "manipulating the model". It does reveal an important point though: the parser may not be able to use the same API that model manipulation uses. It may need to use a lower-level (read: more permissive) interface to the model. The current parser mostly works well though because the current model doesn't do any standards checking. Wanna create a 10k Subject header? Fine! In practice this works well, so perhaps we need to think about how "RFC enforcement" can be overlaid on the model.
-Barry
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ Email-SIG mailing list Email-SIG@python.org Your options: http://mail.python.org/mailman/options/email-sig/archive%40mail-archive.com
