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 _______________________________________________ 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
