Mark Dickinson dicki...@gmail.com added the comment:
Yes, okay---that makes some sense; I'm happy to leave floats as they are
(i.e., DeprecationWarning for small floats; TypeError for larger floats) and
just fix use of __int__ for non-floats.
I'll look at the patch.
--
assignee:
Mark Dickinson dicki...@gmail.com added the comment:
The backport looks fine. Applied in r80917. Thanks, Alexander.
--
resolution: accepted - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker
Mark Dickinson dicki...@gmail.com added the comment:
I've never done a maintenance branch backport, but here is my attempt:
[...]
Yes, that sounds about right. But after all that, you'll still need to modify
the patch somewhat, since the requirements are different for 2.6: floats
should
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
the requirements are different for 2.6: floats should give a
DeprecationWarning rather than a TypeError.
I thought about it, but the comment in test_builtin.py,
# Reject floats when it would require PyLongs
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
Removed file: http://bugs.python.org/file17231/issue1533-release26-maint.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1533
___
Mark Dickinson dicki...@gmail.com added the comment:
Perfect! Committed in r80836 (py3k); fixed that one test and comment in
r80842 in trunk.
Alexander, do you want to tackle the 2.6 backport?
BTW, I think in most cases it's unnecessary to add Python 3.3 to the Versions
field above, since
Mark Dickinson dicki...@gmail.com added the comment:
Bah. That's r80841, not r80842.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1533
___
Changes by Mark Dickinson dicki...@gmail.com:
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1533
___
___
Python-bugs-list mailing list
Mark Dickinson dicki...@gmail.com added the comment:
That should have been r80839, not r80842.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1533
___
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Alexander, do you want to tackle the 2.6 backport?
I've never done a maintenance branch backport, but here is my attempt:
1. Checkout release26-maint
2. Apply 80757:80758 diff, fix rejected NEWS patch
3. Ignore
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
--
keywords: +26backport
versions: -Python 2.7, Python 3.1, Python 3.2, Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1533
Mark Dickinson dicki...@gmail.com added the comment:
Thanks for the fixes. The latest patch looks good to me.
Alexander, is it okay for me to commit this?
--
resolution: - accepted
___
Python tracker rep...@bugs.python.org
Alexander Belopolsky alexander.belopol...@gmail.com added the comment:
On May 4, 2010, at 7:27 AM, Mark Dickinson rep...@bugs.python.org
wrote:
Mark Dickinson dicki...@gmail.com added the comment:
Thanks for the fixes. The latest patch looks good to me.
Alexander, is it okay for me to
Mark Dickinson dicki...@gmail.com added the comment:
Hi Alexander,
I took the liberty of messing with your patch slightly; I didn't want to ask
you to make further changes since the patch was fine, and my messing was mostly
just to satisfy my own fussiness (only the first two items were
Mark Dickinson dicki...@gmail.com added the comment:
Re emacs:
C-c . python
should set a python 2.x-friendly indentation mode.
There's also a python-new style floating around somewhere on the web (not part
of emacs as standard), suitable for the 4-space indent style that's supposed to
be
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Tue, May 4, 2010 at 8:34 AM, Mark Dickinson rep...@bugs.python.org wrote:
..
I took the liberty of messing with your patch slightly; I didn't want
to ask you to make further changes since the patch was fine, and my
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
--
assignee: belopolsky - mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1533
___
Mark Dickinson dicki...@gmail.com added the comment:
[Some of the Alexander's questions about procedures aren't really related to
this issue; I've answered those offline. Here are the answers to the others.]
- initialize low to NULL, to match the Py_XDECREF(low) (could change
that
Mark Dickinson dicki...@gmail.com added the comment:
Applied to trunk in r80758.
Do people want this to go into 2.6 as well? The patch would need to be
modified to produce a warning for floats instead of giving a TypeError (and the
tests would need to be modified to test for that warning).
Alexander Belopolsky alexander.belopol...@gmail.com added the comment:
On Tue, May 4, 2010 at 12:32 PM, Mark Dickinson rep...@bugs.python.org wrote:
Mark Dickinson dicki...@gmail.com added the comment:
Applied to trunk in r80758.
Do people want this to go into 2.6 as well?
Also, should
Mark Dickinson dicki...@gmail.com added the comment:
+1 for forward-porting/adapting relevant tests to py3k.
--
assignee: mark.dickinson - belopolsky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1533
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
I am attaching a py3k patch that adds new tests. Since there are no end user
visible changes, I don't believe a Misc/NEWS entry is needed. A commit message
may read:
Issue #1533: Tests only. Added tests for consistency
Mark Dickinson dicki...@gmail.com added the comment:
Thanks---the new patch looks good. Pulling the argument conversion out into a
separate function makes the whole thing much cleaner.
I still have a couple of nits:
- Please add a comment before get_range_argument indicating
what it's
Mark Dickinson dicki...@gmail.com added the comment:
Thinking about it a bit more, I really would prefer get_range_argument not to
steal a reference. If I'm reading a bit of C code and encounter something like:
obj = transform(obj);
if (obj == NULL) ...
my hindbrain immediately starts
Mark Dickinson dicki...@gmail.com added the comment:
BTW, I've changed the various nb_int should return int object error messages
in Objects/intobject.c to the more meaningful and accurate message: __int__
method should return an integer, in r80695.
--
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Attached patch, issue1533.diff, simplifies reference acrobatics at the expense
of extra local variables. For the first time the first compilation did not
have reference counting errors!
--
Added file:
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
Removed file: http://bugs.python.org/file9543/bltinmodule.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1533
___
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
Removed file: http://bugs.python.org/file17176/bltinmodule4.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1533
___
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
Removed file: http://bugs.python.org/file17171/bltinmodule3.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1533
___
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Sun, May 2, 2010 at 4:37 AM, Mark Dickinson rep...@bugs.python.org wrote:
..
- Please could you also add a test for small arguments for each test
class?
Working on it ...
--
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
- Please could you also add a test for small arguments for each test
class?
Done.
--
Added file: http://bugs.python.org/file17190/issue1533.diff
___
Python tracker
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
Removed file: http://bugs.python.org/file17189/issue1533.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1533
___
Mark Dickinson dicki...@gmail.com added the comment:
Alexander: range *does* still accept such arguments (in 2.7); just not floats:
from decimal import Decimal
range(Decimal(20), Decimal(20))
[]
range(Decimal('1e100'), Decimal('1e100'))
Traceback (most recent call last):
File stdin, line
Alexander Belopolsky alexander.belopol...@gmail.com added the comment:
On Sat, May 1, 2010 at 3:50 AM, Mark Dickinson rep...@bugs.python.org wrote:
Mark Dickinson dicki...@gmail.com added the comment:
Alexander: range *does* still accept such arguments (in 2.7); just not
floats:
from
Mark Dickinson dicki...@gmail.com added the comment:
Decimal is behaving in exactly the same way as MyInt, isn't it? What do you get
for range(MyInt(20), MyInt(20))?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1533
Alexander Belopolsky alexander.belopol...@gmail.com added the comment:
On Sat, May 1, 2010 at 10:59 AM, Mark Dickinson rep...@bugs.python.org wrote:
Mark Dickinson dicki...@gmail.com added the comment:
Decimal is behaving in exactly the same way as MyInt, isn't it?
What do you get for
Robert Bradshaw rober...@math.washington.edu 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
Alexander Belopolsky alexander.belopol...@gmail.com added the comment:
Robert,
Your patch segfaults on Lib/test/test_builtin.py, but I agree with the
approach. I'll see if it is easy to fix.
--
___
Python tracker rep...@bugs.python.org
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
--
assignee: - belopolsky
nosy: +belopolsky -Alexander.Belopolsky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1533
___
Mark Dickinson dicki...@gmail.com added the comment:
Hmm, maybe there is a 2.7 bug here after all:
Yes, indeed! Which is why I was suggesting 'wont fix' rather than 'out of
date' :)
The bltinmodule2.diff patch from Robert causes a segfault in test_builtin on my
system; I haven't looked at
Changes by Mark Dickinson dicki...@gmail.com:
--
resolution: out of date -
status: closed - open
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1533
___
Mark Dickinson dicki...@gmail.com added the comment:
A couple of suggestions regarding the patch:
(1) I'd suggest leaving the first part of handle_range_longs intact, up to and
including the /* ilow and ihigh correct now; do istep */ block. Then build
out the three if (!PyInt_Check(...)) ...
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
I am attaching a patch which does not crash or leak (as tested with -R :) and
adds a unit test for OP's case.
The problem, however is that it does not work if new style classes are used in
the test case. See disabled
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Mark,
I did not see your last comment before uploading the last patch. I think your
suggestion to bypass PyNumber_Long will fix the new/old style classes
discrepancy.
--
___
Mark Dickinson dicki...@gmail.com added the comment:
Alexander, I think it should be as simple as replacing the if
(!PyInt_Check(ilow) ...) block with something like this:
if (!PyInt_Check(ilow) !PyLong_Check(ilow)) {
PyNumberMethods *nb = Py_TYPE(ilow)-tp_as_number;
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
This patch, bltinmodule4.diff, seems to work for all cases.
Mark,
It looks like I came up with almost the same logic as you did. The only
difference that I can see is that your code does not check that nb_int returns
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
Added file: http://bugs.python.org/file17176/bltinmodule4.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1533
___
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
Removed file: http://bugs.python.org/file17175/bltinmodule4.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1533
___
Mark Dickinson dicki...@gmail.com added the comment:
As far as I can tell there's no bug in 3.x: the 3.x range happily accepts an
instance of a class that defines __index__.
--
versions: -Python 3.1, Python 3.2
___
Python tracker
Mark Dickinson dicki...@gmail.com added the comment:
Currently, in trunk, I get:
range(0.0, 11.0, 1.1)
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: range() integer start argument expected, got float.
But with Alexander's patch on trunk, I get:
range(0.0,
Mark Dickinson dicki...@gmail.com added the comment:
IIRC, it was a very deliberate choice not to allow float arguments to range
Ignore this bit. IDRC. It was a deliberate choice not to let something
range(0.0, 1.0, 0.1) work to give [0.0, 0.1, ...], since the usual
floating-point
Alexander Belopolsky alexander.belopol...@gmail.com added the comment:
I agree that this issue should be closed with no further action, but for
historical accuracy the resolution should be out of date rather than won't
fix. The original bug was about range() behavior when it get arguments
Changes by Martin v. Löwis mar...@v.loewis.de:
--
resolution: wont fix - out of date
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1533
___
Changes by Mark Dickinson dicki...@gmail.com:
--
nosy: +mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1533
___
___
Python-bugs-list
Changes by Brian Curtin cur...@acm.org:
--
priority: - normal
type: crash - behavior
versions: +Python 3.1, Python 3.2 -Python 3.0
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1533
___
Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
--
assignee: rhettinger -
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1533
___
Martin v. Löwis [EMAIL PROTECTED] added the comment:
This change is out of scope for 2.5.3 (plus, the desired behavior still
seems to be debated)
--
nosy: +loewis
versions: -Python 2.5, Python 2.5.3
___
Python tracker [EMAIL PROTECTED]
Akira Kitada [EMAIL PROTECTED] added the comment:
I'm just curious to know which is the right behavior.
# Python 3.0
Traceback (most recent call last):
File bad_range.py, line 7, in module
print(range(MyInt(2**3), MyInt(2**3+10)))
TypeError: 'MyInt' object cannot be interpreted as an
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
Akira Kitada [EMAIL PROTECTED] added the comment:
Updating versions.
--
versions: +Python 2.5.3, Python 2.6, Python 2.7, Python 3.0
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1533
___
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
Rafael Zanella added the comment:
According to the documentation
(http://docs.python.org/dev/library/functions.html) The arguments must
be plain integers, so I think the wrong thing here is to run the
object's __int__() under the range()'s hood. I think the right thing to
do would be to
Alexander Belopolsky added the comment:
This is related to issue1540617 and issue1546078.
issue1540617 contains a simple patch that extend acceptable range of
argument to +/-2**63
issue1546078 contains a complete long integer support implementation and
was accepted in Py3k.
It looks like
Christian Heimes added the comment:
I'm -10 on the patch in issue1540617 ( +/-2**63).
Reason: It's a good thing that the range of range is limited since it
returns a list of integers. range(2**32) allocates (2**32)*16 bytes +
small overhead for ints plus the space for the list (probably
Alexander Belopolsky added the comment:
Christian,
I was probably a bit sloppy using range instead of xrange, but issue1540617
is limited to xrange only. Are you still -10 on extending
xrange on 64-bit platforms to +/- 2**63? If so, what is your position
on backporting py3k's unlimited
Alexander Belopolsky added the comment:
So far the memory for the ints is *never* returned
to the system. I'm working on the problem.
Christian,
Are you working on the memory problem or on this issue? I think I have a
solution to OP's problem, but don't want to duplicate your effort.
Christian Heimes added the comment:
I'm working on the memory problem. See #2039 and #2013.
xrange is a totally different story. I'm +0 on changing xrange. Is
Python 3.0's range function compatible with xrange? If the answer is
yes, we may reuse the code for an unlimited xrange.
Alexander Belopolsky added the comment:
Attached patch addresses OP's issue:
$ ./python.exe bad_range.py
[8, 9, 10, 11, 12, 13, 14, 15, 16, 17]
here
[18446744073709551616L, 18446744073709551617L, 18446744073709551618L,
18446744073709551619L, 18446744073709551620L, 18446744073709551621L,
Rafael Zanella added the comment:
FWIW, using xrange() it seems to give the proper error message:
Traceback (most recent call last):
File bad_range.py, line 12, in module
print xrange(MyInt(2**64), MyInt(2**64+10))
OverflowError: long int too large to convert to int
--
nosy:
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
Changes by Raymond Hettinger:
--
assignee: - rhettinger
nosy: +rhettinger
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1533
__
___
Python-bugs-list mailing list
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
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
__
73 matches
Mail list logo
