Re: [Python-Dev] Multiprocessing maintenance
On Oct 23, 2010, at 8:10 PM, Martin v. Löwis wrote:
>> Who is doing multiprocessing maintenance these days? I thought Ask
>> Solem had been given commit privs for that, but I haven't seen any
>> activity from him; and Jesse is, mostly, absent. Is anyone working on
>> the multiprocessing issues?
>>
>> (no, I'm not planning to address them :-))
>
> You mean: actively feeling responsible for it? I guess nobody - as for
> many other modules in the standard library.
>
> Or do you mean: who is willing to work on it, in principle?
> The last committers are georg.brandl, gregory.p.smith,
> martin.v.loewis, and antoine.pitrou.
>
> Regards,
> Martin
Hey!
I do feel responsible, and I know Jesse do to.
I'm working on multiprocessing issues every week, though
not as much as I would like to.
I have quite a few patches ready, some in the tracker, some not.
My idea was to send those to Jesse last week for approval,
but for work related reasons I didn't manage to prepare them in
time.
If you have anything you want me to look at please forward it,
and if you already did then don't be afraid to nag me.
--
{Ask Solem,
+47 98435213 | twitter.com/asksol }.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Multiprocessing maintenance
> If you have anything you want me to look at please forward it, > and if you already did then don't be afraid to nag me. Please keep the release schedule in mind. After 3.2b1, no new features can be accepted (until after the 3.2 release). So there might be some urgency for some of the patches. Also, submitting many small changes is preferred over patch bombs. So it might be better to start committing what is complete, rather than first completing all work in progress. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] __setcall__
I was looking for a way to set a function being equal to another function: q(m+1) = q(m)+ ((-1)^m) * exp(lnanswer); I was hoping to use something like this: (q).__setcall__.(m+1) = (q).__setcall__.(m)+ ((-1)^m) * exp(lnanswer); As a work around. But I have not found the `__setcall__' built in being there. Here is the code block I'm working with: indvar = 200; q = 0; lnanswer = 0; for m = 1:150 lnanswer = (3 * m) * log(indvar) - log(factorial(3 * m)) ; q(m+1) = q(m)+ ((-1)^m) * exp(lnanswer); end lnanswer q Any help would be appreciated. Thank you ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __setcall__
2010/10/24 Bj Raz : > I was looking for a way to set a function being equal to another function: > q(m+1) = q(m)+ ((-1)^m) * exp(lnanswer); > I was hoping to use something like this: > (q).__setcall__.(m+1) = (q).__setcall__.(m)+ ((-1)^m) * exp(lnanswer); > As a work around. > But I have not found the `__setcall__' built in being there. > > Here is the code block I'm working with: > > indvar = 200; > q = 0; > lnanswer = 0; > for m = 1:150 > lnanswer = (3 * m) * log(indvar) - log(factorial(3 * m)) ; > q(m+1) = q(m)+ ((-1)^m) * exp(lnanswer); > end > lnanswer > q > > Any help would be appreciated. Please see python-list. This list is for the development of python. The SAGE math package can do something like this. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] 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] r85822 - python/branches/py3k/Modules/ossaudiodev.c
> Add casts (one needed, one for consistency). FWIW, I feel that these casts are misguided. Having function pointer casts means that type errors in the signature get suppressed. E.g. people using such casts for tp_hash will be unable to detect the change in the tp_hash return type that we have implemented for 3.2. It would be better, IMO, if these casts get avoided everywhere, even if that means that the functions get a line longer. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
