Wiadomość napisana przez Martin v. Löwis w dniu 2010-12-30, o godz. 10:16:
> Am 30.12.2010 04:45, schrieb Brian Quinlan:
>
>> So skipping the test is probably the way to go.
>
> I'm still -1 on that proposal.
I agree with Martin, explanation follows.
In general, I'm trying to think as the user: someone wrote a program and said
it requires Python 3.2. I expect it to work on Python 3.2 available on my
platform. Doesn't matter if it's bundled with the OS or custom built.
When a module is not available, this should fail loudly and as fast as
possible. This is currently the case with conditionally built modules like
curses, sqlite3, tkinter and others. From the user's perspective: the import
fails. From the administrator's perspective: the build reports skipped modules.
The admin can then alter the environment to make the build behave as expected,
and then run the tests to confirm it works. From an OS maintainer perspective
it's even better: a module can be made available optionally with explicitly set
dependencies and required configuration.
In our specific case a bunch of things should be determined first:
1. Does it still fail on FreeBSD 7.3+?
2. Why is the semaphore limit so low in the first place?
3. What is a reasonable number for that limit? That should include situations
where people run multiple applications.
4. What other configuration should be done to ensure the module won't break on
runtime.
Some answers Philip gave already. Knowing all these things would let us decide
whether switching the module off on systems that don't meet the requirements is
okay and can we get away with just documenting how to make it work. One problem
is that the administrator can make the OS compatible/incompatible on runtime
(with sysctl).
ISTM concurrent.futures was included a bit too early in the distribution. The
module has problems not only on BSD [1]. Fortunately, there is visible action
from Brian, Philip and David to make the problems go away. I'm sure it will be
fixed pretty soon. Ultimately I also agree with Martin that an implementation
using SysV IPC would probably be better from the user's perspective. As he
said, even if the underlying code is not as pretty as with the POSIX APIs, once
it's written and tested nobody cares because it's not exposed. However, it's
far too late to change that now for 3.2.
[1] On RedHat/CentOS the test freezes badly (issue 10517).
--
Best regards,
Łukasz Langa
tel. +48 791 080 144
WWW http://lukasz.langa.pl/
_______________________________________________
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
