handling return codes from CTYPES

[Steve Simmons]

PY33, Win7, Python Newbie, Not homework

I'm trying to use some 'C' DLLs from Python using ctypes and I have a
minor issue with the return valuesbut I am new to Python; ctypes and
using DLLs so I am at the bottom of so many learning curves, I'm not
sure where or how to find my mistake.
When I call the DLL, I am expecting a return of 1 (success) or a
negative number (one of a set of error conditions)the return value is
specified as 'short' in the DLL call specification - "short InitScanLib
(const char * szLicense)". What I get back is either a 1 or something
like 65535. This implies that I am receiving the expected value (-1)
but 'something' is being lost in the translation. The code is asper the
snippet below:

I've tried declaring initResult as c_short by: inserting...

.... before the call to sLib.InitScanLib but I still get the same
response (65535).

Interactively, I can see ...
It's not a critical issue because I only want the return value to
lookupa textual error message but I do want to understand what's going
on. Any input appreciated.

 

[Steve Simmons]

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

 

[Chris Angelico]

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.

Yeah, it takes some getting used to. I've spent the past couple of
decades writing imperative code with strict declarations and fairly
close to the metal, and I still have one C++ module at work - but more
and more, I'm pushing to write code in a modern high-level language
like Python, where memory management isn't my problem, and failings in
the code result in easily-readable (and catchable!) exceptions. I
often fire up gdb for the C++ code at work, but usually a Python or
Pike exception traceback is enough on its own.

Learning curve, rewarded with immensely easier work. So many things
are like that; life is all about figuring out which ones are worth the
curve's effort.

ChrisA