Amaury Forgeot d'Arc gmail.com> writes:
>
> I corrected this with r65341.
> But this prebuilt MemoryError has another nasty consequence:
> when PyErr_NoMemory is raised, the traceback is attached to the
> prebuilt object,
> and all local variables of the failing procedure are still referenced
> a
2008/7/21 Georg Brandl <[EMAIL PROTECTED]>:
b"a"*sys.maxsize
> Traceback (most recent call last):
> File "", line 1, in
> MemoryError
> [41297 refs]
b"a"*sys.maxsize
> Traceback (most recent call last):
> File "", line 1, in
> File "", line 1, in
> MemoryError
> [41317 refs]
b"
On Thu, Jul 31, 2008 at 10:32 AM, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> On Wed, Jul 30, 2008 at 9:36 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> On Tue, Jul 29, 2008 at 10:07 PM, "Martin v. Löwis" <[EMAIL PROTECTED]>
>> wrote:
+1 OverflowErrors should probably by reserved for numer
On Wed, Jul 30, 2008 at 9:36 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 29, 2008 at 10:07 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>>> +1 OverflowErrors should probably by reserved for numeric overflows.
>>
>> In a sense, passing sys.maxsize as a string size *is* a numeri
Antoine Pitrou wrote:
Perhaps a bit less legitimate but still :)
r = range(n)
len(r)
Traceback (most recent call last):
File "", line 1, in
OverflowError: Python int too large to convert to C ssize_t
Speaking of which, http://bugs.python.org/issue2690 (« Precompute range length
», which ha
Guido van Rossum python.org> writes:
>
> FWIW, are there any legitimate occurrences of OverflowError in Py3k
> now that ints have unlimited range?
Legitimate:
>>> n = 2 ** 16384
>>> float(n)
Traceback (most recent call last):
File "", line 1, in
OverflowError: Python int too large to convert
On Wed, Jul 30, 2008 at 11:36 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> FWIW, are there any legitimate occurrences of OverflowError in Py3k
> now that ints have unlimited range?
I believe not being able to convert an int to Py_ssize_t with
PyNumber_AsSsize_t is a valid use.
>
> --
> --Gu
On Tue, Jul 29, 2008 at 10:07 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> +1 OverflowErrors should probably by reserved for numeric overflows.
>
> In a sense, passing sys.maxsize as a string size *is* a numeric
> overflow - the size can't be represented in the available variable.
I'm sure
> +1 OverflowErrors should probably by reserved for numeric overflows.
In a sense, passing sys.maxsize as a string size *is* a numeric
overflow - the size can't be represented in the available variable.
Regards,
Martin
___
Python-3000 mailing list
Pytho
On Tue, Jul 29, 2008 at 7:05 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Did anyone come up with a fix for these?
>
> It's true that OverflowError and MemoryError are returned pretty
> randomly when we detect that an allocation is not going to fit. I
> think MemoryError is better though, so p
Did anyone come up with a fix for these?
It's true that OverflowError and MemoryError are returned pretty
randomly when we detect that an allocation is not going to fit. I
think MemoryError is better though, so perhaps those uses of
OverflowError should be fixed. I doubt that there are any apps (e
In a debug-build 3k, do this (32-bit machine):
Python 3.0b2+ (py3k:65171M, Jul 21 2008, 20:08:20)
[GCC 4.2.4 (Gentoo 4.2.4 p1.0)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> "a"*10
instinstTraceback (most recent call last):
File "", line 1, in
M
12 matches
Mail list logo
