On Feb 23, 2006, at 14:27, Michele Petrazzo wrote:
>  This may be a good idea, or not. You have to decide.
>  How many developer (better projects that use ctypes) have to change  
>  they
>  code for work with new version? Big question, you say.
>  I see only two (or three) question about this issue, so I don't think
>  that, for the other developer :), this is a problem.
>  If you want to be backwards compatible, do it! What "internal" python
>  developers think about this?

I've used ctypes to develop more than a handful of library wrappers,  
as well as contribute to ones like OpenGL-ctypes.  When the version  
number is less than 1.0, I start with the assumption that the library  
is going to need some hand holding because the author is not yet set  
on the interface and implementation of the system.  Fortunately,  
Thomas consistently writes good stuff -- which means it soon becomes  
an invaluable tool in the bag.  So to localize changes he makes, we  
use an internal build of ctypes for our products.  That way I am able  
to control when we need to update our libraries depending on ctypes.   
This works great for product-based or site-based software.  However,  
it's not so great for open source because the need to track the  
latest and greatest ctypes is there, and must be addressed.

My opinion is that Thomas should make changes needed to get ctypes  
into the shape he wants to maintain the 1.0 release branch.  I would  
prefer that the python integration piece has only the methods and  
properties it needs, and not a lot of duplicate names.  This means  
breaking a few things now to ease the longer term maintenance.   
Things like documentation, examples, and a general pythonic feel take  
a little bit more precedence than normal because we are going to be  
blessed with a long term implementation in python itself.  Also,  
there is a precedent of maintaining two branches for complex projects  
like ctypes -- one for python, and one for development & cutting  
edge.  Both the email and optparse packages operate in this mode.

So, all in all, I think Thomas needs to be free in pre 1.0 releases  
to make the best library he can, allowing the API to be nailed down.   
Once he pushes out a 1.0, I think it will need to carefully maintain  
backwards compatibility.  (With the ability to deprecate things, of  
course!)  This gets us both a clean 1.0 implementation, and an  
version in python itself!

Thanks,
-Shane


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
ctypes-users mailing list
ctypes-users@[...].net
https://lists.sourceforge.net/lists/listinfo/ctypes-users