Re: [Python-Dev] Floor division
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 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 should be allowed to be complex too, though, it's hard to imagine. 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. Complex numbers are not just magic pairs with two numbers and have actual mathematical rules. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Floor division
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 should be allowed to be complex too, though, it's hard to imagine. [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 multiply complex numbers. (All of which you could have deduced from reading what I wrote, as it happens.) 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() to complain when passed two complex numbers would (1) notify users sooner when they have errors in their programs, (2) simplify the code, and (3) avoid the arguably broken behaviour Tim was remarking on, where complex(-0.0).real is +0 instead of -0. [1] For the avoidance of ambiguity: real is not synonymous with double-precision floating-point. Complex numbers are not just magic pairs with two numbers and have actual mathematical rules. Gosh, and there I was thinking that complex numbers were magic pairs where you just make stuff up at random. Silly me. -- Gareth McCaughan PhD in pure mathematics, University of Cambridge ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Floor division
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 multiply complex numbers. (All of which you could have deduced from reading what I wrote, as it happens.) 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() to complain when passed two complex numbers would (1) notify users sooner when they have errors in their programs, (2) simplify the code, and (3) avoid the arguably broken behaviour Tim was remarking on, where complex(-0.0).real is +0 instead of -0. Haven't looked in source code for complex constructor yet, but I think that if it changes sign of -0.0 then it just does something wrong and needs fixing without change in behaviour. Maybe it could check if numbers it got on input are real or complex and proceed accordingly so that it never gets to computing -0.0-(+0.0), i.e. when second argument is not a complex number it could just add it to imaginary part of first argument, but skip substracting inexistant 0.0 from first argument's real part. Change of behaviour like ignoring imaginary part of second argument seems bad to me, and that's my only point. Besides, documentation (at least for Python 2.4) clearly states that second argument can be a complex number: *complex*( [real[, imag]]) Create a complex number with the value *real + imag*j* or convert a string or number to a complex number. If the first parameter is a string, it will be interpreted as a complex number and the function must be called without a second parameter. The second parameter can never be a string. Each argument may be *any numeric type* (*including complex*). If imag is omitted, it defaults to zero and the function serves as a numeric conversion function like int(), long() and float(). If both arguments are omitted, returns 0j. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Floor division
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 how to multiply complex numbers. (All of which you could have deduced from reading what I wrote, as it happens.) 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() to complain when passed two complex numbers would (1) notify users sooner when they have errors in their programs, (2) simplify the code, and (3) avoid the arguably broken behaviour Tim was remarking on, where complex(-0.0).real is +0 instead of -0. Haven't looked in source code for complex constructor yet, but I think that if it changes sign of -0.0 then it just does something wrong and needs fixing without change in behaviour. Maybe it could check if numbers it got on input are real or complex and proceed accordingly so that it never gets to computing -0.0-(+0.0), i.e. when second argument is not a complex number it could just add it to imaginary part of first argument, but skip substracting inexistant 0.0 from first argument's real part. Change of behaviour like ignoring imaginary part of second argument seems bad to me, and that's my only point. Besides, documentation (at least for Python 2.4) clearly states that second argument can be a complex number: I'm not suggesting that it should ignore the imaginary part of the second argument, and I don't think anyone else is either. What might make sense is for passing a complex second argument to raise an exception. (I don't particularly object to the present behaviour either.) The fact that the documentation states explicitly that the second argument can be a complex number is probably sufficient reason for not changing the behaviour, at least before 3.0. -- g ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problem with signals in a single threaded application
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 signals support in python, so what can be done? 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. Inter alia, all of the following are likely to lead to lost signals: Two related signals received between two 'checkpoints' (i.e. when the signal is tested and cleared). You may only get one of them, and 'related' does not mean 'the same'. A second signal received while the first is being 'handled' by the operating system or language run-time system. A signal sent while the operating system is doing certain things to the application (including, sometimes, when it is swapped out or deep in I/O.) And there is more, some of which can cause program misbehaviour or crashes. You are also right that threading makes the situation a lot worse. 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 possible. Defending yourself against the other failures is an almost hopeless task, but luckily they are extremely rare except on specialist systems. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Complex constructors [was Re: Floor division]
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() to complain when passed two complex numbers would (1) notify users sooner when they have errors in their programs, (2) simplify the code, and (3) avoid the arguably broken behaviour Tim was remarking on, where complex(-0.0).real is +0 instead of -0. [1] For the avoidance of ambiguity: real is not synonymous with double-precision floating-point. Precisely. On this matter, does anyone know of an application where making that change would harm anything? I cannot think of a circumstance under which the current behaviour adds any useful function over the one that raises an exception if there are two arguments and either is complex. Yes, of course, SOME people will find it cool to write complex(a,b) when they really mean a+1j*b, but Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Object creation hook
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 kills the system. Our system is of a scale that makes this very risky.
2) There is no way to frame certain operations and get just those objects that
were created during their execution. In our case, we would like to get the
server cluster running, then frame a certain operation to get a callback for
all created objects, so that we could track that they were later destroyed
correctly. I have done this previously by storing the id()s of all objects
returned from gc.get_objects() and comparing them before and after but this
suffers from 1) above, and the ambiguity of id() in the face of objects being
created and destroyed.
Working with the metaclasses sounds reasonable if one has the luxury of
changing the entire codebase to use a different metaclass. It also doesn't
work with old style classes (plenty of those), c extensions, and builtins.
(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 :) but I digress...)
My latest attempt was to modify _PyObject_GC_TRACK(o) in objimpl.h, adding this
final line:
if (PyCCP_CreationHook) PyCCP_CreationHookFunc(o);\
The function then looks like this:
void PyCCP_CreationHookFunc(PyObject * obj)
{
if (PyCCP_CreationHook) {
PyObject *result, *tmp = PyCCP_CreationHook;
PyCCP_CreationHook = 0; //guard against recursion
result = PyObject_CallFunctionObjArgs(PyCCP_CreationHook, obj,
0);
Py_XDECREF(result);
if (!result)
PyErr_Clear();
PyCCP_CreationHook = tmp;
}
}
Doing this, and setting a no-op function as as the PyCCP_CreationHook, does
seem to work for a while in the interactive python shell, but it then crashes
and I haven't been able to work out the crash. In any case, doing stuff at the
point of GC list insertion is very hairy, especially in the face of __del__
methods and such (of which we don't have many)
I am waiting to get Rational Purify set up on my machine and then I'll maybe be
able to understand the crash case better.
Cheers,
Kristján
-Original Message-
From: Martin v. Löwis [mailto:[EMAIL PROTECTED]
Sent: 23. janúar 2007 23:32
To: Kristján V. Jónsson
Cc: 'python-dev@python.org'
Subject: Re: [Python-Dev] Object creation hook
Kristján V. Jónsson schrieb:
I am trying to insert a hook into python enabling a callback for all
just-created objects. The intention is to debug and find memory leaks,
e.g. by having the hook function insert the object into a WeakKeyDictionary.
I'd like to point out that this isn't a python-dev question, but more
appropriate for comp.lang.python (as it is of the how do I x with
Python? kind).
I would use a debug build, and use sys.getobjects to determine all
objects and find leaks.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] buildbot failure in amd64 gentoo 2.5
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 lowercase in this box: Type the branch name in this box: etc. It's easier than a normal CAPTCHA because its OK to assume a lot more knowledge on the part of the intended audience. ...and it works with text-based browsing. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ Help a hearing-impaired person: http://rule6.info/hearing.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] buildbot failure in amd64 gentoo 2.5
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 about simple ways to change that form to make it less vulnerable to the spambots, I'd be happy to incorporate them into Buildbot. I'd throw a CAPTCHA in. There are even some written in Python. I'd guess even the simplest thing would work: Type Python into this box: __ The approach (outlined here http://damienkatz.net/2007/01/negative_captch.html) of having a hidden field that is attractive to spam bots, but hidden from humans would seem to be as effective without the (slight) annoyances of filling in an extra field every time. -- Benji York ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problem with signals in a single threaded application
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 colleague of mine and he had a nice idea on how to fix this. We couldn't think of anything wrong with the solution, so I'm testing it right now and gonna write a test case afterwards. Thanks for contributing, No problem. :-) Regards, -- Ulisses ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problem with signals in a single threaded application
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 possible. Defending yourself against the other failures is an almost hopeless task, but luckily they are extremely rare except on specialist systems. I couldn't agree more. I might have misused the word reliably. At first glance I thought the signal was being lost but then I've discovered what was really happening. Regards, -- Ulisses ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problem with signals in a single threaded application
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 what is the current plan for signals support in python, so what can be done? 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. 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... -- Gustavo J. A. M. Carneiro The universe is always one step beyond logic. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problem with signals in a single threaded application
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, so I'm unable to comment whether it fixes the problem under discussion. I feel that this problem should find a much simpler solution. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problem with signals in a single threaded application
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 include test case. Ok. I was discussing this problem with a colleague of mine and he had a nice idea on how to fix this. We couldn't think of anything wrong with the solution, so I'm testing it right now and gonna write a test case afterwards. Here is the link for the bug with both the test program and first attempt to solve it. http://www.python.org/sf/1643738 Regards, -- Ulisses ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
