Nick Coghlan wrote:
> Nick Coghlan wrote:
>> Armin Rigo wrote:
>>> Hi,
>>>
>>> There is an oversight in the design of __index__() that only just
>>> surfaced :-( It is responsible for the following behavior, on a 32-bit
>>> machine with >= 2GB of RAM:
>>>
>>> >>> s = 'x' * (2**100) # wor
Nick Coghlan wrote:
>
>
> One possibility would be to invert the sense of that flag and call it
> "typeerror", which probably more accurately reflects what it's intended for -
> it's a way of telling the function "if this object does not have the correct
> type, tell me by setting this flag in
All, please decide without me.
On 8/1/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Nick Coghlan wrote:
> > Travis Oliphant wrote:
> >>> Probably the most interesting thing now would be for Travis to review
> >>> it, and see whether it makes things easier to handle for the Numeric
> >>> scalar typ
Nick Coghlan wrote:
> Travis Oliphant wrote:
>>> Probably the most interesting thing now would be for Travis to review
>>> it, and see whether it makes things easier to handle for the Numeric
>>> scalar types (given the amount of code the patch deleted from the
>>> builtin and standard library d
Travis Oliphant wrote:
>> Probably the most interesting thing now would be for Travis to review
>> it, and see whether it makes things easier to handle for the Numeric
>> scalar types (given the amount of code the patch deleted from the
>> builtin and standard library data types, hopefully the b
Nick Coghlan wrote:
> Armin Rigo wrote:
>> Hi,
>>
>> There is an oversight in the design of __index__() that only just
>> surfaced :-( It is responsible for the following behavior, on a 32-bit
>> machine with >= 2GB of RAM:
>>
>> >>> s = 'x' * (2**100) # works!
>> >>> len(s)
>> 2
Nick Coghlan wrote:
> The other benefit is that the logic to downconvert to Py_ssize_t that
> was formerly invoked by long's __index__ method is now instead invoked
> by PyNumber_Index and PyNumber_SliceIndex. This means that directly
> calling an __index__() method allows large long results t
Armin Rigo wrote:
> Hi,
>
> There is an oversight in the design of __index__() that only just
> surfaced :-( It is responsible for the following behavior, on a 32-bit
> machine with >= 2GB of RAM:
>
> >>> s = 'x' * (2**100) # works!
> >>> len(s)
> 2147483647
>
> This is becaus
Hi Guido,
On Fri, Jul 28, 2006 at 11:31:09AM -0700, Guido van Rossum wrote:
> No time to look through the code here, but IMO it's acceptable (at
> least for 2.5) if (2**100).__index__() raises OverflowError, as long
> as x[:2**100] silently clips. __index__() is primarily meant to return
> a value
Martin v. Löwis wrote:
> Travis Oliphant wrote:
>> I say it's a bug that should be fixed. Don't clear the error, raise it.
>
> Several people have said this, but I don't think it can work.
>
> If you raise an OverflowError in __index__, the slicing code cannot know
> whether this meant as overfl
Guido van Rossum wrote:
> In my recollection I tried to avoid this exact behavior. I wanted
> __index__() to just return the unclipped int or long value, but have a
> C API that clipped it for use in slice operations.
So is there still a chance to fix it?
--
Greg
Tim Peters wrote:
> So, e.g., plain a[i] shouldn't use __index__ either if i is already
> int or long. I don't see any justification for invoking nb_index in
> sequence_repeat(), although if someone thinks it should, then as for
> plain indexing it certainly shouldn't invoke nb_index if the incom
Armin Rigo wrote:
> This is because PySequence_Repeat(v, w) works by applying w.__index__ in
> order to call v->sq_repeat.
Why does it do that? Shouldn't __index__ only be used for
numbers which are going to be used as an index?
> However, __index__ is defined to clip the
> result to fit in a Py
Martin v. Löwis wrote:
> Travis Oliphant wrote:
>
>>I say it's a bug that should be fixed. Don't clear the error, raise it.
>
> Several people have said this, but I don't think it can work.
>
> If you raise an OverflowError in __index__, the slicing code cannot know
> whether this meant as over
Travis Oliphant wrote:
> I say it's a bug that should be fixed. Don't clear the error, raise it.
Several people have said this, but I don't think it can work.
If you raise an OverflowError in __index__, the slicing code cannot know
whether this meant as overflow or underflow (in a signed sense).
Nick Coghlan wrote:
> David Hopwood wrote:
>> Armin Rigo wrote:
>>> Hi,
>>>
>>> There is an oversight in the design of __index__() that only just
>>> surfaced :-( It is responsible for the following behavior, on a 32-bit
>>> machine with >= 2GB of RAM:
>>>
>>> >>> s = 'x' * (2**100) # wo
[Tim]
>>> ...
>>> This is a mess :-)
[Nick Coghlan]
>> I've been trawling through the code a bit, and I don't think it's as bad as
>> all that.
[also Nick, but older & wiser ;-)]
> Damn, it really is a mess. . . nb_index returns the Pyssize_t directly,
Bingo. It's a /conceptual/ mess. Best I c
On 7/28/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Nick Coghlan wrote:
> > Tim Peters wrote:
> >> OTOH, in the long discussion about PEP 357, I'm not sure anyone except
> >> Travis was clear on whether nb_index was meant to apply only to
> >> sequence /slicing/ or was meant to apply "everywhere
Nick Coghlan wrote:
> Tim Peters wrote:
>> OTOH, in the long discussion about PEP 357, I'm not sure anyone except
>> Travis was clear on whether nb_index was meant to apply only to
>> sequence /slicing/ or was meant to apply "everywhere an object gets
>> used in an index-like context". Clipping ma
Tim Peters wrote:
> OTOH, in the long discussion about PEP 357, I'm not sure anyone except
> Travis was clear on whether nb_index was meant to apply only to
> sequence /slicing/ or was meant to apply "everywhere an object gets
> used in an index-like context". Clipping makes sense only for the
> f
Argh.
I also find it a bug.
I also feel responsible because I reviewed the patch. :-(
In my recollection I tried to avoid this exact behavior. I wanted
__index__() to just return the unclipped int or long value, but have a
C API that clipped it for use in slice operations. It looks like I
failed
[Armin Rigo]
> There is an oversight in the design of __index__() that only just
> surfaced :-( It is responsible for the following behavior, on a 32-bit
> machine with >= 2GB of RAM:
>
> >>> s = 'x' * (2**100) # works!
> >>> len(s)
> 2147483647
>
> This is because PySequence_Rep
Michael Hudson wrote:
> David Hopwood <[EMAIL PROTECTED]> writes:
>
>> Armin Rigo wrote:
>>> Hi,
>>>
>>> There is an oversight in the design of __index__() that only just
>>> surfaced :-( It is responsible for the following behavior, on a 32-bit
>>> machine with >= 2GB of RAM:
>>>
>>> >>> s =
David Hopwood wrote:
> Armin Rigo wrote:
>> Hi,
>>
>> There is an oversight in the design of __index__() that only just
>> surfaced :-( It is responsible for the following behavior, on a 32-bit
>> machine with >= 2GB of RAM:
>>
>> >>> s = 'x' * (2**100) # works!
>> >>> len(s)
>>
David Hopwood <[EMAIL PROTECTED]> writes:
> Armin Rigo wrote:
>> Hi,
>>
>> There is an oversight in the design of __index__() that only just
>> surfaced :-( It is responsible for the following behavior, on a 32-bit
>> machine with >= 2GB of RAM:
>>
>> >>> s = 'x' * (2**100) # works!
>
Armin Rigo wrote:
> Hi,
>
> There is an oversight in the design of __index__() that only just
> surfaced :-( It is responsible for the following behavior, on a 32-bit
> machine with >= 2GB of RAM:
>
> >>> s = 'x' * (2**100) # works!
> >>> len(s)
> 2147483647
>
> This is becaus
Hi,
There is an oversight in the design of __index__() that only just
surfaced :-( It is responsible for the following behavior, on a 32-bit
machine with >= 2GB of RAM:
>>> s = 'x' * (2**100) # works!
>>> len(s)
2147483647
This is because PySequence_Repeat(v, w) works by apply
27 matches
Mail list logo
