Neal Norwitz added the comment:
I looked over the new patch Christian uploaded and I think I understand
what's going on. I didn't do a through comparison, but if all the tests
pass, I think that's good enough. Good work!
Here are the issues I would like to see fixed before check in (all small
and easy):
* Fix the format nits. There were missing spaces around = and ==.
* Remove the comment that says:
+ * XXX TypeError doesn't seem right for this,
+ * maybe create an ArgumentError ???
+ * XXX Arg positions currently reported as
+ * 1-based, contrary to most things in
+ * python ???
The first line of that comment should stay.
* Expand the comment that says: Maybe skip this in debug build ?
Add a XXX or TODO and explain why. I think it's just that it would
give extra testing. I'm not sure it's worth it since that would be
added code, but it's a valid question.
* Verify that it's faster by compiling python in a release build (ie,
optimized, not debug with assertions) and do something that would
trivially execute the code. For example:
* ''.split()
* ''.split('', 1)
* (1,).index(1)
* (1,).index(1, 0, 1)
That might be a decent set. I just grepped for PyArg_ParseTuple
Objects/*.c and found some common cases where this code would be used.
It would be great to add the timing info from the test cases above (as
well as the pybench results) to the check in message.
* In the test do a single import at the top of the file.
* Use raise Error('') instead of raise Error, '' in the test. Actually
instead of raising an exception, call self.fail(error_message)
----------
resolution: -> accepted
_____________________________________
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1691070>
_____________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
