Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #37256
| Date | 2013-01-22 08:02 +0000 |
|---|---|
| From | Steve Simmons <square.steve@gmail.com> |
| Subject | Re: handling return codes from CTYPES |
| References | <mailman.736.1358765181.2939.python-list@python.org> <XnsA14F71C8BA4D1duncanbooth@127.0.0.1> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.780.1358845215.2939.python-list@python.org> (permalink) |
Duncan, Mike, MRAB, Thank you. New technology set, same forgotten lesson - RTFM (all of it!). Thanks also for the clarification on discarding objects and Garbage Collection. Looks like I'll have to turn a large chunk of my previous understanding of (mainframe) languages 'inside out'. I'm just wondering how often I'll have to chant "it isn't a variable, it's a name bound to an object" before I can write a chunk of code without spending ages pondering why it isn't working. I already like Python for its clean design but I think it'll be a while before I love it completely. Steve On 21/01/2013 11:11, Duncan Booth wrote: > Tell the function what type to return before you call it: InitScanLib > = sLib.InitScanLib InitScanLib.restype = c_short See > http://docs.python.org/2/library/ctypes.html#return-types You can also > tell it what parameter types to expect which will make calling it > simpler.
Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
handling return codes from CTYPES Steve Simmons <square.steve@gmail.com> - 2013-01-21 10:46 +0000
Re: handling return codes from CTYPES Duncan Booth <duncan.booth@invalid.invalid> - 2013-01-21 11:11 +0000
Re: handling return codes from CTYPES Steve Simmons <square.steve@gmail.com> - 2013-01-22 08:02 +0000
Re: handling return codes from CTYPES Chris Angelico <rosuav@gmail.com> - 2013-01-23 00:10 +1100
csiph-web