Barry Warsaw writes: > I would proposal a radical suggestion: we treat backward compatibility > the way Python 3 did. Nice to keep, but we can throw it over the side > in order to fix the warts. We'll worry about migration strategy later.
+1 > Aside: I would really like to have a much more @property based API > where appropriate. +1 > E.g. Message.get_content_type() would be Message.content_type. And > in this case we'd probably have message.payload_bytes or some such. > Decoding may require additional parameters so it will probably be a > method. Maybe, but in general those parameters can be deduced from the metadata. If we can use those defaults often enough, then the default-decoded version can be a property too. We would have to provide alternatives, though. I've seen Shift JIS encoded Japanese labelled "ISO-2022-JP", and apparently many Japanese MUAs actually decode that to Japanese! Not suggesting that we should do the same, but probably the generic function that is used to decode should be exposed as a method so that clients who encounter such nonsense can deal with it, and override any of the metadata. _______________________________________________ Email-SIG mailing list Email-SIG@python.org Your options: http://mail.python.org/mailman/options/email-sig/archive%40mail-archive.com