Mads Kiilerich <[EMAIL PROTECTED]> added the comment: Testing that email.message doesn't use the "wrong" casing email.Generator isn't enough. That would just test that this patch has been applied. It must also be tested that no other modules uses the wrong casing of email.Generator. Or other email packages. Or any other packages at all.
IMHO the "right" test would be to test that modulefinder can find all relevant modules in all cases. The problem is that it gives irrelevant warnings. I tested with some shell hacking to find all modulefinder failures which could be found with another casing: find * -name '*.py'|sed 's,\.py$,,g;s,/,.,g;s,\.__init__$,,g' > /tmp/all_fs_modules for a in $(find * -name '*.py'); do echo $a; python -m modulefinder $a; echo; done > /tmp/all_referenced_modules for a in $(grep ^? /tmp/all_referenced_modules|sed 's,^\? \(.*\) imported from .*,\1,g'|sort|uniq); do grep -i "^$a"'$' /tmp/all_fs_modules; done > /tmp/referenced_existing_ignorecased email.base64mime email.charset email.encoders email.errors email.generator email.header email.iterators email.message email.parser email.quoprimime email.utils ftplib - where the last hit comes from bogus regexp matching. The test takes long time to run as it is. That could probably be improved. But still I think this is to be compared with "lint"-like tools which should be run reguarly but isn't suitable for unit tests. I feel ashamed for arguing against introducing a test. I think I do that because I think that this isn't a "normal" bug and thus isn't suitable for unit testing. The email module itself really is fully backwards compatible. And modulefinder does a good job doing what it does and can't be blamed for not figuring the email hackery out. The problem comes when a third external modules puts things together and they doesn't fit together as one could expect. Also, currently both casings works and should work. Using the old casing isn't a "bug bug", but it has consequences which IMHO is enough to call it a bug and fix it. Perhaps Python could have a standard way markup of deprecated functions so that it could be checked that the standard librarary didn't use them. __________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2622> __________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
