This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author josh.r
Recipients cool-RR, josh.r, rhettinger
Date 2014-07-03.22:19:43
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
TypeError also should be more specific because it can occur for a multitude of reasons; along with stuff like AttributeError, it's one of those exceptions that could arise from multiple causes on a single line of code, none of them obvious. For the specific case of passing the wrong number of arguments, that's usually a result of programmer error, not input errors to a valid program, so it's not a case worth optimizing. For control flow uses of TypeError (e.g. using duck typing to choose code paths), performance loss is a valid point.

ImportError requires disambiguation for similar reasons (since a single import statement could error because the target module is missing, or because one of its dependencies fails to import; you need to be able to tell the difference, and a line number doesn't help). Beyond that, there is little cost to making fully detailed ImportErrors; if you're risking ImportErrors in your program's hot paths, something is wrong with your design.

As for needing a use case: Every feature starts at minus 100 points (ref: ). There is a limited amount of development and testing resources, more code means more opportunity for errors and increased disk and memory usage, etc.

I agree that KeyError is a relevant comparison, though you'd be surprised how much cheaper indexing a sequence is relative to dictionary access; hashing and collision chaining are usually tripling or quadrupling the work relative to a simple integer lookup in a sequence. The more expensive the non-exceptional operation, the less you need to worry about the expense of the exceptional case, simply because the code was never going to run that quickly anyway.
Date User Action Args
2014-07-03 22:19:44josh.rsetrecipients: + josh.r, rhettinger, cool-RR
2014-07-03 22:19:44josh.rsetmessageid: <>
2014-07-03 22:19:44josh.rlinkissue21911 messages
2014-07-03 22:19:43josh.rcreate