[Python-Dev] Addition of "pyprocessing" module to standard lib.

[Ulrich Berning]

Brett Cannon wrote:

>On Mon, May 19, 2008 at 2:03 AM, Ulrich Berning
><ulrich.berning at denviso.de> wrote:
>  
>
>>Gregory P. Smith wrote:
>>
>>    
>>
>>>On Fri, May 16, 2008 at 1:32 AM, Ulrich Berning
>>><ulrich.berning at denviso.de> wrote:
>>>
>>>      
>>>
>>>>As long as the ctypes extension doesn't build on major Un*x platforms
>>>>(AIX,
>>>>HP-UX), I don't like to see ctypes dependend modules included into the
>>>>stdlib. Please keep the stdlib as portable as possible.
>>>>
>>>>        
>>>>
>>>Nice in theory but ctypes already works on at least the top 3 popular
>>>platforms.  Lets not hold Python's stdlib back because nobody who uses
>>>IBM and HP proprietary stuff has contributed the necessary support.
>>>Making nice libraries available for other platforms is a good way to
>>>encourage people to either pitch in and add support or consider their
>>>platform choices in the future.
>>>
>>>-gps
>>>
>>>
>>>      
>>>
>>It's not my platform choice, it's the choice of our customers. I'm not using
>>these platforms just for fun (in fact it isn't fun compared to Linux or
>>Windows).
>>
>>If porting libffi to AIX, HP-UX, IRIX, Solaris... (especially using vendor
>>compilers) would be an easy job, I'm sure it would have been done already.
>>    
>>
>
>Well, ctypes isn't simple. =)
>
>  
>
>>If more and more essential packages depend on ctypes, we should make a clear
>>statement, that Python isn't supported any longer on platform/compiler
>>combinations where libffi/ctypes doesn't build. This would give me arguments
>>to drop support of our software on those platforms.
>>    
>>
>
>You are mixing the stdlib in with the language in terms of what is
>required for Python to work, which I think is unfair. Just because
>some part of the stdlib isn't portable to some OS does not mean Python
>is not supported on that platform. If you can run a pure Python module
>that does not depend on any C extension, then that platform has the
>support needed to run Python. Everything else is extra (which is why
>we have modules in the stdlib only available on specific platforms).
>
>-Brett
>
>  
>
I don't think it is unfair. If the development team decides one day to 
reimplement essential extensions like math, _socket, select, _ssl, pwd, 
grp, time, _locale, zlib... based on ctypes because it may be much 
easier to maintain python modules instead of dealing with complicated C 
code,  Python will become pretty useless. It's like a cool radio without 
the chance to get any batteries for it, pretty useless.

Platform specific modules are documented as such and nobody would expect 
a _winreg module on AIX or HP-UX.

As said before, PyOpenGL is an example of an extension that moved from C 
code to Python/ctypes, luckily we don't use it, but what if the 
maintainers of MySQL-Python or cx_Oracle decide to move to ctypes.
Having the ctypes extension in the stdlib doesn't imply it runs on any 
platform where python runs. Extension writers should keep this in mind 
when they decide to use ctypes. They should document, that their 
extension depends on ctypes and therefore doesn't run on platforms where 
ctypes doesn't work.

Ulli