homepage

there's probably a better way to do this (or a better reason), but
LONG_MIN and LONG_MAX end up as the wrong constant types when compiling
python2.5.2 under wine (don't ask...)
PyObject *
PyInt_FromSsize_t(Py_ssize_t ival)
{
 if ((long)ival >= (long)LONG_MIN && (long)ival <= (long)LONG_MAX)
 {
 return PyInt_FromLong((long)ival);
 }
 return _PyLong_FromSsize_t(ival);
}

Interesting. How many of those casts are actually necessary to make 
things work? Have you figured out more precisely why this is failing?
E.g., is it somehow that LONG_MIN ends up being an unsigned constant?
It seems to me that a better fix would be to fix LONG_MIN and LONG_MAX 
somewhere in the configuration files; there are bound to be more uses of 
LONG_MIN and LONG_MAX in the source that are going to cause problems.
P.S. Looking at your python-dev messages, does len([1, 2]) really return 
1L? Not 2L?

oh, duh - 2L not 1L yes you're right :)
yeh i believe it's likely to be because in PC/pyconfig.h LONG_MAX is
#defined to 7fffffff not 7fffffffL i'll double-check.
you're right that would make life a looot easier.

.... hmmm... noo, it's already #defined to 0x7fffffffL in
both PC/pyconfig.h _and_ in /usr/include/wine/msvcrt/limits.h
so .... this works (Include/pyports.h)
#ifdef __WINE__ /* weird: you have to typecast 0x7fffffffL to long */
#undef LONG_MAX
#undef LONG_MIN
#define LONG_MAX ((long)0x7FFFFFFFL)
#define LONG_MIN ((long)(-LONG_MAX-1))
#else
#ifndef LONG_MAX
#if SIZEOF_LONG == 4
#define LONG_MAX 0X7FFFFFFFL
#elif SIZEOF_LONG == 8
#define LONG_MAX 0X7FFFFFFFFFFFFFFFL
#else
#error "could not set LONG_MAX in pyport.h"
#endif
#endif
#ifndef LONG_MIN
#define LONG_MIN (-LONG_MAX-1)
#endif
#endif /* __WINE__ */

I think you should study the preprocessor output to find out what
LONG_MAX really expands to, at the point where it is used.
In any case, I'm tempted to close this as "works for me" - 0x7FFFFFFFL
is definitely a long constant in all compilers I know of.

It seems likely that this is a wine bug rather than a Python bug.