> To revive this issue, I tried to write a unit test to verify the behaviour.
> Onfurtunately, the test doesn't work and I don't understand why. I hope,
> someone here is more enlightend than me...

The semantic of listen's backlog argument has always been unclear, so
different implementations apply some "fudge factor" to the value
passed, see for example
http://books.google.com/books?id=ptSC4LpwGA0C&lpg=PA108&ots=Kq9FQogkTr&dq=berkeley%20listen%20backlog%20ack&pg=PA108#v=onepage&q=berkeley
listen backlog ack&f=false

Most of the time, passing <backlog> means that the kernel will queue
at least <backlog> requests.
Under the kernel I'm using (2.6.32), the maximum number of queued
requests is actually backlog + 1, and it seems to be the same on
FreeBSD (I guess one of the reason is to cope with backlog == 0).
Note that under Linux, there's another setting coming into play,
net.ipv4.tcp_abort_on_overflow:
"""
If listening service is too slow to accept new connections, reset
them. Not enabled by default. It means that if overflow occurred due
to a burst, connection will recover.
Enable this option only if you are really sure that listening daemon
cannot be tuned to accept connections faster. Enabling this option can
harm clients of your server.
"""

The goal is to avoid dropping connection requests because of a temporary burst.
So if you change your script to make as many connections as possible
with the default value, you'll probably be able to go well above
listen's backlog.
To deactivate it, you can use:
# sysctl  net.ipv4.tcp_abort_on_overflow=1

(But it's not a good idea in a production setting).

As for the test, you should add it to Lib/test/test_socket.py (just
creating a socket, binding it and passing a backlog of 0 should be
more than enough).