On Wed, Dec 29, 2010 at 1:34 PM, "Martin v. Löwis" <mar...@v.loewis.de> wrote: > Am 29.12.2010 18:54, schrieb Jesse Noller: >> On Wed, Dec 29, 2010 at 10:28 AM, "Martin v. Löwis" <mar...@v.loewis.de> >> wrote: >>>>> I would like to know if it should be considered as a release blocker. >>>>> Georg Brandl said yes on IRC. >>>> >>>> Under the condition that it is within reason to fix it before the >>>> release. >>> >>> What *should* be possible is to disable building >>> SemLock/multiprocessing.synchronize on FreeBSD. As a consequence, >>> multiprocessing locks would stop working on FreeBSD, and concurrent >>> futures; the tests would recognize this lack of features and get >>> skipped. >>> >>> Regards, >>> Martin >> >> The multiprocessing test suite already skips the tests which use the >> (broken) functionality on BSD correctly. This logic needs to be added >> to the concurrent.futures library. > > I'm not so sure that skipping the test is the right approach. Doesn't > that mean that the code will still fail at runtime with > difficult-to-explain messages? I'd rather prefer if the functionality > wasn't available in the first place. > > Also, what specific test are you referring to? > > Regards, > Martin >
If the functionality is not supported then users get an import error (within multiprocessing). However, RDM's understanding is correct, and the test is creating more than supported. _______________________________________________ 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
