Author ncoghlan
Recipients benjamin.peterson, jnoller, mishok13, ncoghlan
Date 2008-07-14.22:25:51
SpamBayes Score 4.34043e-05
Marked as misclassified No
Message-id <>
At this stage I'm still inclined to skip the warnings completely - at
the very least, any eventual removals will go through a full deprecation
cycle in 2.7/3.1 before being removed in 2.8/3.2.

It's also much easier to be sure we aren't adversely affecting
performance of the old methods that way (with a
PendingDeprecationWarning, performance of the deprecated methods is
going to suffer a bit since the warnings machinery will still have to be
invoked to discover that the warning has been filtered out). That said,
the methods we're changing aren't likely to be something one invokes in
speed critical sections of an application, so I wouldn't object if the
old names emitted PDW in both 2.6 and 3.0.

Regarding the additional get/set properties on multiprocessing.Process,
it depends on whether or not they are cheap to calculate and whether or
not they involve any I/O operations. auth_key looked like it may be
expensive to set (since I assume there is a crypto calculation involved
there), exit_code may involve waiting for the other process to finish,
and get_ident may involve waiting for it to start. So my initial
reaction is that these are OK to keep as methods rather than trying to
turn them into properties.

The following pretty undesirable behaviour should probably be discussed
on python-dev before beta3 (if not beta2):

Python 2.6b1+ (trunk:64945, Jul 14 2008, 20:00:46)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import multiprocessing as mp
>>> isinstance(mp.Lock(), mp.Lock)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: isinstance() arg 2 must be a class, type, or tuple of classes
and types
>>> mp.Lock.__name__
>>> mp.Lock.__module__
>>> mp.Lock().__class__.__name__
>>> mp.Lock().__class__.__module__

The delayed import functions in multiprocessing.__init__ look like a
serious misfeature to me. I'd be inclined to replace them with "from
.synchronize import *" and "from .process import *" (leaving anything
which isn't covered by those two imports to be retrieved directly from
the relevant mp submodule)
Date User Action Args
2008-07-14 22:25:55ncoghlansetspambayes_score: 4.34043e-05 -> 4.34043e-05
recipients: + ncoghlan, benjamin.peterson, jnoller, mishok13
2008-07-14 22:25:54ncoghlansetspambayes_score: 4.34043e-05 -> 4.34043e-05
messageid: <>
2008-07-14 22:25:53ncoghlanlinkissue3352 messages
2008-07-14 22:25:51ncoghlancreate