[issue1533] Bug in range() function for large values
Robert Bradshaw added the comment: Thank you Alexander. Yes, there is still an issue for large operands, and the attached patch does fix it. Floats are explicitly checked for and rejected by PyArg_ParseTuple for the "l" format (as called by builtin_range) so to preserve this behavior we can explicitly check in the argument parsing of handle_range_longs as well. This all goes away in Py3 due to the unification of int and long. (And I agree that using __index__ rather than __int__ fits better there). -- Added file: http://bugs.python.org/file17169/bltinmodule2.diff ___ Python tracker <http://bugs.python.org/issue1533> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1533] Bug in range() function for large values
New submission from Robert Bradshaw: Range accepts arguments coerce-able into ints via __int__, but rejects arguments coerce-able into longs but to large to fit into an int. The problem is in handle_range_longs in bltinmodule.c:1527-1541. If they type is not an int or long, it should try to make it so before failing (for consistency with smaller values at least). Attached is a file that reproduces this bug. -- components: Interpreter Core, Library (Lib) files: bad_range.py messages: 58034 nosy: robertwb severity: normal status: open title: Bug in range() function for large values type: crash versions: Python 2.5 Added file: http://bugs.python.org/file8839/bad_range.py __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1533> __ bad_range.py Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1533] Bug in range() function for large values
Robert Bradshaw added the comment: Yes, that is a workaround, but range(MyInt(n), MyInt(n+10)) should work for any valid value of n, not just some of them. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1533> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1533] Bug in range() function for large values
Robert Bradshaw added the comment: Yes, the error for xrange is more illustrative of the problem, but just shows that xrange has this a too. Why should xrange be invalid for non-word sized values (especially as range works)? Incidentally, just a week ago I had to write my own iterator for a project because xrange couldn't handle large values. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1533> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1533] Bug in range() function for large values
Robert Bradshaw added the comment: Alexander Belopolsky's patch looks like the right fix for range() to me. The xrange limits still hold, but that should probably be a separate issue/ticket. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1533> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1533] Bug in range() function for large values
Robert Bradshaw <[EMAIL PROTECTED]> added the comment: I think *both* behaviors are wrong, the 3.0 one is backwards incompatible, and the 2.7 one is inconsistent (accepting MyInt if it's < 32 bits, rejecting it for > 64 bits). For our particular use case, it is very annoying to not be able to use non-ints. It goes against the principle duck typing by simply defining the __int__ and __index__ methods. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1533> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16202] sys.path[0] security issues
Robert Bradshaw added the comment: Alternatively, one could fix distutils.util.byte_compile() to execute the script in safe, empty temp directory. Running scripts in /tmp remains, as it has always been, a bad idea. Trying to determine if an import is "safe" can be arbitrarily complicated (e.g. what if the group-write bit is set, but you're the only member of that group, or there are special allow or deny ACLs for other users that aren't detected here). What notion of safeness belongs in the spec? -- nosy: +robertwb ___ Python tracker <http://bugs.python.org/issue16202> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16202] sys.path[0] security issues
Robert Bradshaw added the comment: Here's a fix to distutils. I think at least a warning is in order for running scripts from insecure directories, and ideally some happy medium can be found. -- Added file: http://bugs.python.org/file27542/fix_distutils.patch ___ Python tracker <http://bugs.python.org/issue16202> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16202] sys.path[0] security issues
Robert Bradshaw added the comment: Good point about cleanup, patch updated. -- Added file: http://bugs.python.org/file27543/fix_distutils.patch ___ Python tracker <http://bugs.python.org/issue16202> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
