[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.
Marilyn
>
> 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