[Python-Dev] Pervasive socket failures on Windows

Tim Peters tim.peters at gmail.com
Sat Feb 11 02:48:30 CET 2006


[Martin v. Löwis]
> I see. How does Py_SOCKET_FD_CAN_BE_GE_FD_SETSIZE help here?

By naming a logical condition as opposed to a list of
platform-specific symbols that aren't documented anywhere.  For
example, I have no idea exactly which compiler+OS combinations define
MS_WINDOWS, so "#ifdef MS_WINDOWS" is always something of a mystery. 
I don't want to see mystery-symbols inside modules -- to the extent
that they must be used, I want to hide them in .h files clearly
dedicated to wrestling with portability headaches (like pyconfig.h and
pyport.h).

> Does defining it in PC/pyconfig.h do the right thing?

That much would stop the test failures _I_ see, which is what I need
to get unstuck.  If POSIX systems simply ignore it, it would do the
right thing for them too.  Documentation in pyport.h would serve to
guide others (in the "Config #defines referenced here:" comments near
the top of that file).  I don't know what other systems need, so
assuming "we have to do something" _at all_ here, the best I can do is
provide documented macros and config symbols to deal with it.

I think the relationship between SIGNED_RIGHT_SHIFT_ZERO_FILLS and
pyport.h's Py_ARITHMETIC_RIGHT_SHIFT macro is a good analogy here. 
Almost everyone ignores SIGNED_RIGHT_SHIFT_ZERO_FILLS, and that's
fine, because almost all C compilers generate code to do
sign-extending right shifts.  If someone has a box that doesn't, fine,
it's up to them to get SIGNED_RIGHT_SHIFT_ZERO_FILLS #define'd in
their pyconfig.h, and everything else "just works" for them then.  All
other platforms can remain blissfully ignorant.

> I guess I'm primarily opposed to the visual ugliness of the define.

I don't much care how it's spelled.

> Why does it spell out "can be", but abbreviates
> "greater than or equal to"?

Don't care.  I don't know of a common abbrevation for "can be", but GE
same-as >= is in my Fortran-trained blood :-)

> What about Py_CHECK_FD_SETSIZE?

That's fine, except I think it would be pragmatically better to make
it Py_DONT_CHECK_FD_SETSIZE, since most platforms want to check it. 
The platforms that don't want this check (like Windows) are the
oddballs, so it's better to default to checking, making the oddballs
explicitly do something to stop such checking.

It's no problem to add a #define to PC/pyconfig.h, since that
particular config file is 100% hand-written (and always will be).


More information about the Python-Dev mailing list