RetroSearch Browse

Wed Dec 29 19:34:31 CET 2010 · https://mail.python.org/pipermail/python-dev/2010-December/107095.html

Am 29.12.2010 18:54, schrieb Jesse Noller:
> On Wed, Dec 29, 2010 at 10:28 AM, "Martin v. Löwis" <martin at 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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2010-December/107095.html below:

[Python-Dev] Issue #10348: concurrent.futures doesn't work on BSD