Patch / Bug Summary
___
Patches : 421 open ( -2) / 3549 closed (+10) / 3970 total ( +8)
Bugs: 943 open (-17) / 6471 closed (+25) / 7414 total ( +8)
RFE : 260 open ( +2) / 250 closed ( +1) / 510 total ( +3)
New / Reopened Patches
__
rlcomplet
Short of using a memory debugger such as Valgrind or Purify, have you
considered looking for reference leaks? These may be the cause and
can be checked with pure python code. See how Lib/test/regrtest.py
handles the -R option.
n
--
On 1/24/07, Kristján V. Jónsson <[EMAIL PROTECTED]> wrote:
> Th
Kristján V. Jónsson wrote:
> (I was a bit dismayed that I couldn't assign to object.__init__
> post-hoc from a python script, I'm fairly sure that is possible in Ruby :)
It wouldn't do you much good anyway, because no existing
subclass of object having its own __init__ method would
call it.
-
Nick Maclaren wrote:
> This one looks like an oversight in Python code, and so is a bug,
> but it is important to note that signals do NOT work reliably under
> any Unix or Microsoft system.
That's a rather pessimistic way of putting it. In my
experience, signals in Unix mostly do what they're
me
Martin v. Löwis wrote:
> Please
> try to come up with a patch (e.g. by putting a while(is_tripped) loop
> around the for loop).
That isn't going to fix it. What's needed is to somehow
atomically test and clear is_tripped at the beginning.
You can put a while loop around it as well if you want,
bu
[Nick Maclaren]
> ...
> 2) _PyLong_FromByteArray and _PyLong_AsByteArray aren't in
> the API
They're not in the public API, which is equivalent to that their names
begin with a leading underscore. They're in the private API :-)
> and have no comments.
The behavior of these functions, including
Nick Maclaren schrieb:
>> I personally consider *very* important that hash(5.0) == hash(5) (and
>> that 5.0 == 5, of course).
>
> It gets a bit problematic with floating-point, when you can have
> different values "exactly 5.0" and "approximately 5.0". IEEE 754
> has signed zeroes. And so it goe
Having looked into the answers a bit more deeply, I am afraid that
I am still a bit puzzled.
1) As I understand it, PyMem_Malloc won't cause trouble, but won't
be automatically freed, either, as it doesn't return a new reference.
I don't think that immediately following it by PyCObject_FromVoidPtr
On Fri, Jan 26, 2007, Giovanni Bajo wrote:
> On 26/01/2007 17.03, Thomas Wouters wrote:
>>
>> There's no strict requirement that equal objects must have equal
>> hashes,
>
> Uh? I thought that was the *only* strict requirement of h
Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> See _PyLong_FromByteArray and _PyLong_AsByteArray .
Oops! Thanks very much.
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email: [EMAIL PROTECTED]
Tel.: +44 1223 3
Giovanni Bajo <[EMAIL PROTECTED]> wrote:
>
> I personally consider *very* important that hash(5.0) == hash(5) (and
> that 5.0 == 5, of course).
It gets a bit problematic with floating-point, when you can have
different values "exactly 5.0" and "approximately 5.0". IEEE 754
has signed zeroes. And
Nick Maclaren <[EMAIL PROTECTED]> wrote:
>
> Oops. Something else fairly major I forgot to ask. Python long.
> I can't find any clean way of converting to or from this, and
> would much rather not build a knowledge of long's internals into
> my code. Going via text is, of course, possible - bu
On 26/01/2007 17.03, Thomas Wouters wrote:
> How critical is the 'numeric' property of the nb_hash function? I
> can certainly honour it, but is it worth it?
>
> [...]
> There's no strict requirement that
> equal objects must have equal hashes,
Uh? I thought that was the *only* strict
Oops. Something else fairly major I forgot to ask. Python long.
I can't find any clean way of converting to or from this, and
would much rather not build a knowledge of long's internals into
my code. Going via text is, of course, possible - but is not very
efficient, even using hex/octal.
Rega
Thanks very much! That answers most things. Yes, I had got many
of my answers from searching the source, but there is clearly some
history there, and it isn't always clear what is current. Here are
a few responses to the areas of confusion:
> nb_invert is used for bitwise inversion (~) and PyNu
On 1/26/07, Nick Maclaren <[EMAIL PROTECTED]> wrote:
Does Python use classic division (nb_divide) and inversion (nb_invert)
or are they entirely historical? Note that I can very easily provide
the latter.
nb_divide is used for the division operation (/) when not using 'from
__future__ import
Nick, I didn't write that; Tim did. If you're going to enter into a
pedantic discussion, at least get your attributions right,
On 1/26/07, Nick Maclaren <[EMAIL PROTECTED]> wrote:
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> >
> > "(int)float_or_double" truncates in C (even in K&R C) /provide
I have a fair amount of my binary floating-point model written,
though even of what I have done only some is debugged (and none
has been rigorously tested). But I have hit some things that I
can't work out, and one query reduced comp.lang.python to a
stunned silence :-)
Note that I am not intendi
"Tim Peters" <[EMAIL PROTECTED]> wrote:
>
> OTOH, I am a fan of analyzing FP operations as if the inputs were in
> fact exactly what they claim to be, which 754 went a long way toward
> popularizing. That largely replaced mountains of idiosyncratic
> "probabilistic arguments" (and where it seemed
[Tim Peters]
>> ...
>> [it would be possible for float.__divmod__ to return the exact
>> quotient], but who would have a (sane) use for a possibly 2000-bit
>> quotient?
[Nick Maclaren]
> Well, the 'exact rounding' camp in IEEE 754 seem to think that there
> is one :-)
>
> As you can gather, I can'
"Tim Peters" <[EMAIL PROTECTED]> wrote:
>
> [Tim (misattributed to Guido)]
Apologies to both!
> > C90 is unclear about its intent,
>
> But am skeptical of that. I don't have a copy of C90 here, but before
> I wrote that I checked Kernighan & Ritchie's seminal C book, Harbison
> & Steele's genera
[Tim (misattributed to Guido)]
>> "(int)float_or_double" truncates in C (even in K&R C) /provided that/
>> the true result is representable as an int. Else behavior is
>> undefined (may return -1, may cause a HW fault, ...).
[Nick Maclaren]
> Actually, I have used Cs that didn't, but haven't seen
"Tim Peters" <[EMAIL PROTECTED]> wrote:
>
> It could, but who would have a (sane) use for a possibly 2000-bit quotient?
Well, the 'exact rounding' camp in IEEE 754 seem to think that there
is one :-)
As you can gather, I can't think of one. Floating-point is an inherently
inaccurate representati
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
>
> "(int)float_or_double" truncates in C (even in K&R C) /provided that/
> the true result is representable as an int. Else behavior is
> undefined (may return -1, may cause a HW fault, ...).
Actually, I have used Cs that didn't, but haven't seen any
24 matches
Mail list logo
