Alok Singhal added the comment:
I think there is a small problem with the fix in changeset 268d13c7e939
(msg258029). It copies the string from the return value of _eintr_retry_call()
twice. I am attaching a trivial fix.
--
keywords: +patch
nosy: +AlokSinghal
Added file: http
Alok Singhal added the comment:
Hi Raymond, Martin,
I won't feel bad about this patch not making it into the final Python
distribution. I worked on this bug because it was the only "core C" bug at
PyCon US sprints for CPython. I learned a bit more about CPython while worki
Alok Singhal added the comment:
Yes, I signed it a few days ago.
--
___
Python tracker
<http://bugs.python.org/issue6305>
___
___
Python-bugs-list mailin
Alok Singhal added the comment:
Uploading another patch which is the same as the last patch but this one
applies cleanly after the latest islice changes for #21321.
--
Added file: http://bugs.python.org/file35205/islice_large_values-4.patch
Alok Singhal added the comment:
OK. Here is the first patch with a couple of bug fixes for "slow mode".
--
Added file: http://bugs.python.org/file34999/islice_large_values-3.patch
___
Python tracker
<http://bugs.python.
Alok Singhal added the comment:
This updated patch has support for starting in fast mode until the next count
would result in overflow in Py_ssize_t. The first patch started in slow mode
as soon as any of 'start', 'stop', or 'step' was outside of the range. With
Alok Singhal added the comment:
Here's a proposed patch. I need more tests for large values, but all the tests
I could think of take a long time to get to a long value. I added some tests
that don't take much time but work correctly for long values. If anyone has
any ideas for
Alok Singhal added the comment:
OK. I have written the "slow path" version and tested it a bit. I will add
the code to switch between the paths and also add test cases as well. Thanks!
--
___
Python tracker
<http://bugs.python.
Alok Singhal added the comment:
I started working on this bug as a part of PyCon US 2014 sprints. Should the
bugfix include a fast path (basically the current implementation) for when the
values involved can fit in an int, and a slow path for larger values? Or
should the bugfix just have
