On 1/24/07, Gareth McCaughan [EMAIL PROTECTED] wrote:
complex(complex(1.0, 2.0), complex(10.0, 20.0))
(-19+12j)
WTF? In any case, that's also what's destroying the sign of the
imaginary part in complex(1.0, -0.0).
It seems pretty clear what it thinks it's doing -- namely,
defining
On Wednesday 24 January 2007 08:39, Alexey Borzenkov wrote:
[me, about complex():]
It seems pretty clear what it thinks it's doing -- namely,
defining complex(a,b) = a + ib even when a,b are complex.
And half of why it does that is clear: you want complex(a)=a
when a is complex. Why b
On 1/24/07, Gareth McCaughan [EMAIL PROTECTED] wrote:
[Alexey:]
I think that's the right thing to do, because that is mathematically
correct. j is just an imaginary number with a property that j*j = -1. So
(a+bj) + (c+dj)j = (a-d) + (b+c)j.
Yes, thanks, I know what j is, and I know how to
On Wednesday 24 January 2007 10:20, Alexey Borzenkov wrote:
I think that's the right thing to do, because that is mathematically
correct. j is just an imaginary number with a property that j*j = -1.
So
(a+bj) + (c+dj)j = (a-d) + (b+c)j.
Yes, thanks, I know what j is, and I know
On Tue, Jan 23, 2007, Ulisses Furquim wrote:
I've read some threads about signals in the archives and I was under
the impression signals should work reliably on single-threaded
applications. Am I right? I've thought about a way to fix this, but I
don't know what is the current plan for
Gareth McCaughan [EMAIL PROTECTED] wrote:
... The question is whether
it makes sense to define complex(a,b) = a+ib for all a,b
or whether the two-argument form is always in practice going
to be used with real numbers[1]. If it is, which seems pretty
plausible to me, then changing complex()
Thanks, but the question is really, how do I build a better debug hook than
sys.getobjects? so I argue this is a valid python-dev question.
We have been using gc.get_objects() but it has several problems:
1) It returns all objects in the system. This results in a list so long that
it often
On Tue, Jan 23, 2007, Nick Coghlan wrote:
Allowing a project to define a question answer should do the trick -
essentially a password like Skip suggested, but with a reminder right
there on the page:
Type this project's name in lowercase in this box: _
Type the BDFL's first name in
Michael Hudson wrote:
Giovanni Bajo [EMAIL PROTECTED] writes:
On 23/01/2007 10.20, Brian Warner wrote:
Do I miss something here, or is the buildbot hit by spammers now?
It looks like it is. If that continues, we have to disable the web
triggers.
Good grief. If anyone has any bright ideas
On 1/24/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
I agree it's a bug, and I agree with your proposed analysis. Please
try to come up with a patch (e.g. by putting a while(is_tripped) loop
around the for loop). Also make sure you include test case.
Ok. I was discussing this problem with a
On 1/24/07, Nick Maclaren [EMAIL PROTECTED] wrote:
Obviously, Unix and Microsoft systems depend on signals, so you
can't simply regard them as hopelessly broken, but you can't assume
that they are RELIABLE. All code should be designed to cope with
the case of signals getting lost, if at all
On 1/24/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
Ulisses Furquim schrieb:
I've read some threads about signals in the archives and I was under
the impression signals should work reliably on single-threaded
applications. Am I right? I've thought about a way to fix this, but I
don't know
Gustavo Carneiro schrieb:
What about http://www.python.org/sf/1564547 ? It tries to solve a
different problem, but I think it also fixes this one; at least as much
as possible with the braindead unix signal programming interface...
I'm sceptical. It is way too much code for me to review,
On 1/24/07, Ulisses Furquim [EMAIL PROTECTED] wrote:
On 1/24/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
I agree it's a bug, and I agree with your proposed analysis. Please
try to come up with a patch (e.g. by putting a while(is_tripped) loop
around the for loop). Also make sure you
14 matches
Mail list logo
