Mark Dickinson added the comment:
For the refactoring, see issue #16451
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14794
___
___
Roundup Robot added the comment:
New changeset 9214f8440c44 by Mark Dickinson in branch 'default':
Issue #14794: slice.indices no longer returns OverflowError for out-of-range
start, stop, step or length.
http://hg.python.org/cpython/rev/9214f8440c44
--
nosy: +python-dev
Mark Dickinson added the comment:
Committed the patch. I'll open a new issue for the refactoring. Many thanks
to Serhiy Storchaka for the thorough reviews.
Now if only we could fix len, too... :-)
Python 3.4.0a0 (default:f02555353544, Nov 4 2012, 11:50:12)
[GCC 4.2.1 (Apple Inc. build
Serhiy Storchaka added the comment:
I don't understand what you mean---can you elaborate?
The Python implementation of this method only 40 lines length, including blank
lines, docstring and comments. The C implementation requires over 160 lines
and less clear. Are there ways to use in
Serhiy Storchaka added the comment:
The patch looks good to me. Now benchmarks and special casing for Py_ssize_t
values needed.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14794
___
Mark Dickinson added the comment:
Now benchmarks and special casing for Py_ssize_t values needed.
I thought about that, but I don't think it's worth it. I did some quick
timings, and as expected the new version of slice.indices is somewhat slower
than the original. But I think adding a
Serhiy Storchaka added the comment:
Look at compute_slice_indices() in Objects/rangeobject.c.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14794
___
Mark Dickinson added the comment:
Hmm: one more thing that needs to be fixed before this can be committed---the
error messages for maltyped start, stop and step are less informative than they
used to be.
Before the patch:
slice(0, 2.3, 4).indices(5)
Traceback (most recent call
Mark Dickinson added the comment:
New patch that fixes the error message for badly typed slice arguments.
Also tweaks a couple of other details:
- replace Py_GE with Py_GT, Py_LE with Py_LT in the out-of-range comparisons,
as suggested by Serhiy; this also makes it more closely match the
Serhiy Storchaka added the comment:
compute_slice_indices() and slice_indices() looks as partially duplicates. I
think the similar code should be merged and reused.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14794
Mark Dickinson added the comment:
Agreed.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14794
___
___
Python-bugs-list mailing list
Mark Dickinson added the comment:
Here's a patch.
--
keywords: +patch
stage: needs patch - patch review
type: behavior - enhancement
versions: -Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file27862/issue14794.patch
___
Mark Dickinson added the comment:
I should note that this patch fixes/changes one other aspect of slice.indices:
namely that it used to accept a negative length, and return essentially
meaningless results in that case:
slice(0, 10, 1).indices(-3)
(-3, -3, 1)
With the patch, it now
Mark Dickinson added the comment:
Updated patch (only cosmetic fixes with respect to the first patch). Thanks
Ezio Melotti for comments on #python-dev.
--
Added file: http://bugs.python.org/file27869/issue14794_v2.patch
___
Python tracker
Mark Dickinson added the comment:
Updated for Serhiy's comments on Rietveld:
- fix some refleaks in error cases
- streamline the C code somewhat following Serhiy's suggestions.
Serhiy: you made a comment on the slice_indices function in test_slice.py:
Can we use Python implementation for
Changes by Hynek Schlawack h...@ox.cx:
--
versions: +Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14794
___
___
Python-bugs-list
Serhiy Storchaka added the comment:
This should be an issue on 64-bit too.
slice(0,1,None).indices(sys.maxsize+1)
--
nosy: +serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14794
Changes by Mark Dickinson dicki...@gmail.com:
--
nosy: +mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14794
___
___
Mark Dickinson added the comment:
For 2.7, I don't see any problem with raising OverflowError for a length that's
sys.maxsize, since it's hard to have sequences larger than that anyway.
For 3.x, I'd also see this behaviour as reasonable, and not a bug. If it's
raising OverflowError for
Mark Dickinson added the comment:
If it's raising OverflowError for lengths *smaller* than sys.maxsize,
that's a bug.
Ah, reading Ned's comment, it looks like that's exactly what it's doing.
--
___
Python tracker rep...@bugs.python.org
Paul Upchurch added the comment:
For the concept of reasonable, it should be noted that this behaviour will
affect code that works with reasonably sized sequences despite the largeness of
the parameter.
Consider an extremely large array. To work with such an array, one would
typically break
Serhiy Storchaka added the comment:
I think the issue is than slice constructor accepts integer out of Py_ssize_t
range. And more, it accepts any objects, not only integers or None.
slice(3.4, 'a', {})
slice(3.4, 'a', {})
May be we should disallow creating of such doubtful slices and raise
Mark Dickinson added the comment:
Paul: I think you make good arguments that this should be fixed for 3.4. I do
however think that for versions earlier than 3.4 this 'fix' would be bordering
on a new feature; it's also likely to require significant new code and tests,
and so I'd be wary of
Mark Dickinson added the comment:
I'll look at creating a patch for 3.4
--
assignee: - mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14794
___
Paul Upchurch pau...@gmail.com added the comment:
That's true; it doesn't work with today's downloads from python.org. The
version I tested was win32 but I don't think that should matter. Python has
always supported large numbers on 32-bit OSs.
My observations:
[1] Debian Wheezy, python3.2,
Hynek Schlawack h...@ox.cx added the comment:
I did a little compiling party with official releases and all permutations of
Linux, OS X x 3.2.2, 3.2.3 worked. Both ran on 64bit (Linux in a VirtualBox).
Python 3.2.2 (default, May 13 2012, 21:24:38)
[GCC 4.6.3] on linux2
Type help, copyright,
Paul Upchurch pau...@gmail.com added the comment:
The pre-built 64-bit Windows binaries from python.org works.
Python 3.3.0a3 (default, May 1 2012, 16:46:00) [MSC v.1500 64 bit (AMD64)] on
win32
Type help, copyright, credits or license for more information.
Ned Deily n...@acm.org added the comment:
The problem you described is definitely still an issue with 32-bit builds.
$ /usr/local/bin/python3.3
Python 3.3.0a3 (v3.3.0a3:0b53b70a40a0, May 1 2012, 11:39:35)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type help, copyright, credits or
New submission from Paul Upchurch pau...@gmail.com:
To reproduce the error:
Python 3.2.2 (default, Sep 5 2011, 22:09:30)
[GCC 4.6.1] on linux2
Type help, copyright, credits or license for more information.
slice(0,9,None).indices(126)
Traceback (most recent call last):
File
Hynek Schlawack h...@ox.cx added the comment:
This seems to have been fixed as of 3.2.3 (as shipped with Ubuntu Precise):
Python 3.2.3 (default, Apr 12 2012, 19:08:59)
[GCC 4.6.3] on linux2
Type help, copyright, credits or license for more information.
slice(0,9,None).indices(126)
Paul Upchurch pau...@gmail.com added the comment:
Sorry. I didn't realize there was a 3.2.3 out. I'll close it as fixed.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14794
Éric Araujo mer...@netwok.org added the comment:
This seems to have been fixed as of 3.2.3 (as shipped with Ubuntu Precise)
Just a note: you can’t really trust the behavior of Python shipped by Debian or
derivative systems because doko (the Debian Python maintainer) backports
changes to
32 matches
Mail list logo
