[Baypiggies] ctypes presentation material online

Marilyn Davis marilyn at deliberate.com
Fri May 12 20:48:24 CEST 2006

On Fri, 12 May 2006, Dennis Reinhardt wrote:

> At 10:21 AM 5/12/2006, Marilyn Davis wrote:
> >If you had it to do over again, would you use ctypes?  Or try one of
> >the other options, even though they take more memory?
> Tough question, because memory is but one part of the tradeoff.
> First, let me say that what I am doing is building a ready-to-run program, 
> an exe which when run, well, just runs.  This is in contrast to other 
> deployments where you first need to install Python and a number of other 
> components first.  BitTorrent install IIRC is of this type, for example.

I see.

What about C for this?  I mean since you're looking for a ready-to-run
and you have to deal with typing and be careful about memory anyway?

I guess that's a huge learning curve if you don't know it already.

Maybe sticking to Python and reaching back to C through ctypes is
still faster to develop than a total C solution.  With C, you'd have
to worry about memory for every piece of it you use.

> Adding other components can greatly complicate the user install.  There is 
> a major cost borne by the end user in how well integrated the components 
> are.  Adding more components creates problems beyond just download 
> size.  In order to be ready-to-run, you need some scheme for finding 
> components you have installed which does not conflict with any Python 
> components the user may have installed already.  I solve this by altering 
> sys.path at startup.  I would have to include additional components and 
> know that there are compatible with this (i.e. that they can operate 
> independent of registry settings).
> I never got far enough with WxPython to see if this was a problem.  There 
> is a major learning curve.
> I also had a learning curve implementing DialogDevil (my program) with 
> ctypes.  Even with the 40-50 hours I spent tracking down the crash and the 
> learning curve with ctypes itself (non-trivial), I would still write 
> DialogDevil using this approach.  Here is why:
>          I could be reasonably assured I would not have
>          packaging and deployment issues downstream
>          I could be assured that the entire non-COM
>          Windows API was available to me and that I
>          would not get stuck late in the project because
>          some interface was missing or not usable.
>          The simple functionality was manageable.  I
>          could isolate problems with ctypes.  With more
>         complex packages, my support burden for
>         isolating problems is increased.
>          The download size was a very nice bonus.
> However, in a larger sense, no, I have not done it again.  Currently, I am 
> using a web-browser as a user interface.  The idea here is that I have 
> written an http server and user interactions are via web forms.  In so 
> doing, I get client-server architecture nearly for free with an obvious 
> upgrade to multi-user implementations.    This is not a benefit for 
> DialogDevil type products but is compelling for others.

Thank you so much Dennis.  This is valuable insight for us.


> Regards, Dennis
> ----------------------------------
> | Dennis    | DennisR at dair.com   |
> | Reinhardt | Powerful Anti-Spam |
> ----------------------------------
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> http://mail.python.org/mailman/listinfo/baypiggies


More information about the Baypiggies mailing list