Writing a C extension - borrowed references
Hi all I'm writing my first C extension for Python here, and all is going well. However, I was reading [1], and the author there is advocating Py_INCREF 'ing *every* borrowed reference. Now, I get that if I do something to mutate and perhaps invalidate the PyObject that was borrowed I can get unpredictable results - eg, by getting a borrowed reference to a value from a dictionary, clearing the dictionary and then expecting to use the borrowed reference. However, if my code does not do things like that, is there a chance of a borrowed reference being invalidated that is not related to my use of the thing I borrowed it from? Is this cargo cult advice (sometimes the gods need this structure, and so to please the gods it must be everywhere), sensible belt and braces or needless overkill? Cheers Tom [1] http://pythonextensionpatterns.readthedocs.io/en/latest/refcount.html#borrowed-references -- https://mail.python.org/mailman/listinfo/python-list
Re: Writing a C extension - borrowed references
On Tue, Mar 20, 2018 at 4:38 PM, Chris Angelico wrote: > BTW, have you looked into Cython? It's smart enough to take care of a > lot of this sort of thing for you. I did a bit; this work is to replace our old python 2 SAML client, which used python-lasso and python-libxml2, both packages that are built as part of building the C library and thus an utter PITA to package for different versions of python (something our Infra team were extremely reluctant to do). When the latest (PITA to build) version of python-lasso started interfering with python-xmlsec (validating an invalid signature was causing segfaults), I got fed up of fighting it. I actually also maintain a C version of the same code, using the same libraries, so porting those few segments of code to Python/C seemed more expedient than rewriting in Cython. I'm not writing an API to these libraries, just a few functions. Cheers Tom -- https://mail.python.org/mailman/listinfo/python-list
[OT] Re: Style Q: Instance variables defined outside of __init__
On Tue, Mar 20, 2018 at 5:25 PM, Grant Edwards wrote: > On 2018-03-20, Neil Cerutti wrote: > >> My automotive course will probaly divide cars into Automatic >> Transmission, and Front Wheel Drive. > > I get your point: the two characteristics are, in theory, orthogonal. > But, in the US, the two appear to be correlated. ISTM that cars with > manual transmissions are much more likely to be RWD than are > automatics. I find that slightly strange, I guess in the US, manual transmission correlates to the non default option(?), along with RWD. In Europe, RWD and automatic transmission are more expensive options than FWD and manual transmissions, and most cars are FWD and manual. At least most cars I can afford.. Cheers Tom -- https://mail.python.org/mailman/listinfo/python-list
Re: Writing a C extension - borrowed references
On Tue, Mar 20, 2018 at 5:36 PM, Rob Gaddi wrote: > If all you're doing is a thin-wrapper around a C library, have you thought > about just using ctypes? Yep; the C library whose API I'm using uses macros to cast things to the right structure, and (similar to Cython), as I already _have_ the code, I wasn't particularly interested in working out how to convert things like: LASSO_SAMLP2_NAME_ID_POLICY(LASSO_SAMLP2_AUTHN_REQUEST( LASSO_PROFILE(login)->request)->NameIDPolicy )->Format = strdup(LASSO_SAML2_NAME_IDENTIFIER_FORMAT_PERSISTENT); into ctypes compatible syntax, when I can simply adapt the working C code to Python. :) Plus, there is the library static initialisation to manage, the issues of distributing the C libraries if I do a C wrapper to call from ctypes. This way, it can be distributed from our devpi very easily. Cheers Tom -- https://mail.python.org/mailman/listinfo/python-list
