Ok - we're looking at a final release in 7 days time. I really, really, really
don't want to have to cut an rc3, so unless it's a seriously critical
brown-paper-bag bug, let's hold off on the checkins. Documentation, I don't
mind so much - particularly any formatting errors.
--
Anthony Baxter
[Dino Viehland]
> FYI I've opened a bug against the VC++ team to fix their round tripping on
> floating
> point values (doesn't sound like it'll make the next release, but hopefully
> it'll make it
> someday).
Cool! That would be helpful to many languages implemented in C/C++
relying on the pla
Thanks for the link - it's a good explanation.
FYI I've opened a bug against the VC++ team to fix their round tripping on
floating point values (doesn't sound like it'll make the next release, but
hopefully it'll make it someday).
-Original Message-
From: Tim Peters [mailto:[EMAIL PROTE
[Dino Viehland]
> We've noticed a strange occurance on Python 2.4.3 w/ the floating point
> value 1.79769313486232e+308 and how it interacts w/ a .pyc. Given x.py:
>
> def foo():
> print str(1.79769313486232e+308)
> print str(1.79769313486232e+308) == "1.#INF"
>
>
> The 1st time yo
We've noticed a strange occurance on Python 2.4.3 w/ the floating point value
1.79769313486232e+308 and how it interacts w/ a .pyc. Given x.py:
def foo():
print str(1.79769313486232e+308)
print str(1.79769313486232e+308) == "1.#INF"
The 1st time you run this you get the correct
Building Python with C and then linking in extensions written in or wrapped
with C++ can present problems, at least in some situations. I don't know if
it's kosher to build that way, but folks do. We're bumping into such
problems at work using Solaris 10 and Python 2.4 (building matplotlib, whic
On 9/12/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> On 9/12/06, Gustavo Carneiro <[EMAIL PROTECTED]> wrote:
> > On 9/12/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > > My previous mention of using a *single* flag may survive corruption
> > > simply because we can tolerate false positives. Signal h
On behalf of the Python development team and the Python
community, I'm happy to announce the second RELEASE
CANDIDATE of Python 2.5.
After the first release candidate a number of new bugfixes
have been applied to the Python 2.5 code. In the interests
of making 2.5 the best release possible, we've
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> Michael Hudson schrieb:
>>> According to [1], all python needs to do to avoid this problem is
>>> block all signals in all but the main thread;
>>
>> Argh, no: then people who call system() from non-main threads end up
>> running subprocesses with a
