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
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
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
Changes by Joe Jevnik :
--
pull_requests: +1919
___
Python tracker
<http://bugs.python.org/issue13349>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
Change by Joe Jevnik :
--
pull_requests: +7754
___
Python tracker
<https://bugs.python.org/issue23926>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Joe Jevnik :
--
pull_requests: +7946
___
Python tracker
<https://bugs.python.org/issue23927>
___
___
Python-bugs-list mailing list
Unsubscribe:
101 - 107 of 107 matches
Mail list logo