[Python-Dev] Static builds on Windows (continued)
Earlier references: http://mail.python.org/pipermail/python-dev/2004-July/046499.html I want to be able to create a version of python24.lib that is a static library, suitable for creating a python.exe or other .exe using python's api. So I did as the earlier poster suggested, using 2.4.1 sources. I modified the PCBuild/pythoncore and python .vcproj files as follows: General/ ConfigurationType/ Static library (was dynamic in pythoncore) c/C++ Code Generation RT Library /MT (was /MTD for mt DLL) c/c++/Precompiled/ Not Using Precompiled headers (based on some MSDN hints) librarian OutputFile .//python24.lib Preprocessor: added Py_NO_ENABLED_SHARED. Removed USE_DL_IMPORT I built pythoncore and python. The resulting python.exe worked fine, but did indeed fail when I tried to dynamically load anything (Dialog said: the application terminated abnormally) Now I am not very clueful about the dllimport/dllexport business. But it seems that I should be able to link MY program against a .lib somehow (a real lib), and let the .EXE export the symbols somehow. My first guess is to try to use /MTD, use Py_NO_ENABLE_SHARED when building python24.lib, but then use PY_ENABLE_SHARED when compiling the python.c. I'll try that later, but anyone have more insight into the right way to do this? marvin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Static builds on Windows (continued)
> Date: Wed, 05 Oct 2005 00:21:20 +0200 > From: "Martin v. L?wis" <[EMAIL PROTECTED]> > Subject: Re: [Python-Dev] Static builds on Windows (continued) > Cc: [email protected] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Marvin wrote: > >>I built pythoncore and python. The resulting python.exe worked fine, but did >>indeed fail when I tried to dynamically load anything (Dialog said: the >>application terminated abnormally) > > > Not sure what you are trying to do here. In your case, dynamic loading > simply cannot work. The extension modules all link with python24.dll, > which you don't have. It may find some python24.dll, which then gives > conflicts with the Python interpreter that is already running. > > So what you really should do is disable dynamic loading entirely. To do > so, remove dynload_win from your project, and #undef > HAVE_DYNAMIC_LOADING in PC/pyconfig.h. > > Not sure if anybody has recently tested whether this configuration > actually works - if you find that it doesn't, please post your patches > to sf.net/projects/python. > > If you really want to provide dynamic loading of some kind, you should > arrange the extension modules to import the symbols from your .exe. > Linking the exe should generate an import library, and you should link > the extensions against that. > > HTH, > Martin > I'll try that when I get back to this and feed back my results. I figured out that I can avoid the need for dynamic loading. I wanted to use some existing extension modules, but the whole point was to use the existing ones which as you point out are linked against a dll. So even if I created an .EXE that exported the symbols, I'd still have to rebuild the extensions. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Borrowed and Stolen References in API
On Tue, May 10, 2011 at 12:13:47PM +1200, Greg Ewing wrote: > Nick Coghlan wrote: > >> One interesting aspect is that from the caller's point of view, a >> *new* reference to the relevant behaves like a borrowed reference for >> input parameters, but like a stolen reference for output parameters >> and return values. > > I think it's less confusing to use the term "new" only for > output/return values, and "stolen" only for input values. > > Inputs are either "borrowed" or "stolen" (by the callee). > > Outputs are either "new" (to the caller) or "borrowed" > (by the caller). > > (Or maybe the terms for outputs should be "given" and "lent"?-) To solve this problem in a similar system (the Clownfish object system used by Apache Lucy) we used the keywords "incremented" and "decremented". Applied to some Python C API function documentation: incremented PyObject* PyTuple_New(Py_ssize_t len) int PyTuple_SetItem(PyObject *p, Py_ssize_t pos, decremented PyObject *o) With "incremented" and "decremented", the perspective is always that of the caller. incremented: The caller has to account for an additional refcount. decremented: The caller has to account for a lost refcount. Marvin Humphrey ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Borrowed and Stolen References in API
On Tue, May 10, 2011 at 01:28:04PM +1200, Greg Ewing wrote: > Marvin Humphrey wrote: > >> incremented: The caller has to account for an additional refcount. >> decremented: The caller has to account for a lost refcount. > > I'm not sure that really clarifies anything. These terms > sound like they're talking about the reference count of the > object, but if they correspond to borrowed/stolen, they > don't necessarily correlate with what actually happens to > the reference count. Hmm, they don't correspond to borrowed/stolen. stolen from the caller -> decremented stolen from the callee -> incremented borrowed -> [no modifier] We don't have a modifier keyword which is analogous to "borrowed". The user is expected to understand object lifespan issues for borrowed references without explicit guidance. With regards to "what actually happens to the reference count", I would argue that "incremented" and "decremented" are accurate descriptions. * When a function returns an "incremented" object, that function has added a refcount to it. * When a function accepts a "decremented" object as an argument, it will consume a refcount from it -- either right away, or at some point in the future. In my view, it is not desirable to label arguments or return values as "borrowed"; it is only necessary to advise the user when they must take action to account for a refcount, gained or lost. Cheers, Marvin Humphrey ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
