[issue30477] tuple.index error message improvement

New submission from Joe Jevnik: The old error of tuple.index(x): x not in tuple seemed very confusing to me. It was also harder to quickly understand what the program was doing wrong. This saves people a second pass through the program under the debugger because they can just see what the

[issue30477] tuple.index error message improvement

Joe Jevnik added the comment: I agree, "%R in tuple" is enough information for me. This would also remove the need to manually repr the object. -- type: enhancement -> ___ Python tracker <http://bugs.pytho

[issue30477] tuple.index error message improvement

Joe Jevnik added the comment: As a more meta question: I have noticed that many error messages in the stdlib use PyErr_SetString, or choose to use the type name instead of the repr of the object. Is there a reason for this? I normally try to fill the error message with as much context as

[issue13349] Non-informative error message in index() and remove() functions

Changes by Joe Jevnik : -- pull_requests: +1919 ___ Python tracker <http://bugs.python.org/issue13349> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue28638] Optimize namedtuple creation

Joe Jevnik added the comment: I added a benchmark suite (using Victor's perf utility) to cnamedtuple. The results are here: https://github.com/ll/cnamedtuple#benchmarks To summarize: type creation is much faster; instance creation and named attribute access are a bit f

[issue23926] skipitem() in getargs.c still supports 'w' and 'w#', and shouldn't

Change by Joe Jevnik : -- pull_requests: +7754 ___ Python tracker <https://bugs.python.org/issue23926> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue23927] getargs.c skipitem() doesn't skip 'w*'

Change by Joe Jevnik : -- pull_requests: +7946 ___ Python tracker <https://bugs.python.org/issue23927> ___ ___ Python-bugs-list mailing list Unsubscribe:

<    1   2