Weird invisible arguments issues with Windows
I've installed Python 2.6.1 (AMD64) under Windows Vista Ultimate 64-bit. First off, it didn't register the extension for .PY (although it did register .PYC). After manually associating the .PY extension with the python.exe executable, I am now getting some weirdness on the command line. When I run the following script, saved as "build.py", by simply entering "build.py -r -d" on the command line, it produces the output "1": import sys if __name__ == "__main__": print len(sys.argv) It doesn't see the additional arguments for some reason. However, if I execute the script by prefixing it (i.e., "python build.py -r -d"), I get an output of "3", meaning it sees the additional arguments. Has anybody else run into this issue? And perhaps (hopefully) solved it? -- http://mail.python.org/mailman/listinfo/python-list
Re: Weird invisible arguments issues with Windows
Tim Golden wrote: > What does your association look like? Try ftype; should be something > like this: > > H:\>ftype python.file > python.file="C:\Python26\python.exe" "%1" %* Then, Chris Hulan wrote: > on my XP system, in the registry under HKEY_CLASSES_ROOT\Applications > \python.exe\shell\open\command > has: > Name (Default) > Type REG_SZ > Data C:\Python23\python.exe "%1" %* > > If that '%*' is missing, thats the problem Finally, MRAB scribed: > You might want to check that: > > assoc .py > > displays: > > .py=Python.File > > and: > > ftype Python.File > > displays: > > Python.File="C:\Python26\python.exe" "%1" %* Thank you for all the replies, guys. :) You all seem to be pointing at the same thing, and on my system, I show: C:\Users\Administrator>ftype python.file python.file="D:\Python26\python.exe" "%1" %* and C:\Users\Administrator>assoc .py .py=Python.File Which all seems to be correct. I'm guessing this doesn't bode well... -- http://mail.python.org/mailman/listinfo/python-list
Calling a class instance like a function
I'm wondering if there's a way to invoke a "function" operator on a Python class instance. For example, given a class instance: myClass = MyClass() I want to call that instance like a function, with an argument value: myClass(5.0) I can override the "()" operator in C++, so I'm wondering if there's a way to do it in Python as well. Thanks! -- http://mail.python.org/mailman/listinfo/python-list
Re: Calling a class instance like a function
Thank you very much, Filip!! :) Filip Gruszczyński wrote: > __call__ > > 2009/2/19 Uberman : >> I'm wondering if there's a way to invoke a "function" operator on a Python >> class instance. For example, given a class instance: >> >>myClass = MyClass() >> >> I want to call that instance like a function, with an argument value: >> >>myClass(5.0) >> >> I can override the "()" operator in C++, so I'm wondering if there's a way to >> do it in Python as well. >> >> Thanks! >> -- >> http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Why can't I store a DLL in a module library Zip file?
I'm using Python 2.5.1, and I'm trying to use the module library as a Zip file (for example, with python25_d.dll, the module library file would be called python25_d.zip). This works for the basic modules that come with Python (os, sys, site, etc.), and it even seems to work when I place my own Python-based modules within the Zip file (e.g., my_module.py). My Python modules are found within the library Zip file. However, my Python module is dependent upon a SWIG-generated shared library, which also has it's own Python module. When placed into the Zip file, the SWIG Python module is found, but the shared library file (the compiled C shared library) is not. I've stepped through the Python code to try and see what's happening, but when it comes to looking in the Zip file (python25_d.zip) for this shared library (*.pyd), it won't find it. When I place all the files in the same folder as the executable (outside the python25_d.zip) file, they are found by the run-time system, and everything is happy. I've also tried a properly constructed 'site-package' within the Zip file, with the SWIG-generated files contained within, but that doesn't work either. It's almost like shared libraries are disallowed from the module library Zip format. Is there a trick, or some special location where it needs to be placed? Any help with this would be appreciated. Thanks. -- http://mail.python.org/mailman/listinfo/python-list
Shared library Python on Mac OS X 64-bit
I'm trying to build a 64-bit version of Python 2.5.1 on Mac OS X 10.5.6 64-bit (Intel processor). The configure line I'm using is: ./configure --enable-shared --disable-framework --disable-toolbox-glue OPT="-fast -arch x86_64 -Wall -Wstrict-prototypes -fno-common -fPIC" LDFLAGS="-arch x86_64" The system builds, but it absolutely refuses to build the shared libraries. I keep getting the 'libpython2.5.a' file, and not the needed *.dylib files. Anybody know how to get this thing to produce shared and not static libraries? A link to examples or documentation that shows the correct configure parameters? I would have thought "--enable-shared" would do it, but I guess I'm wrong. -- http://mail.python.org/mailman/listinfo/python-list
Re: Shared library Python on Mac OS X 64-bit
Graham Dumpleton wrote: > Why don't you want to use MacOS X Framework libraries? It is the > better installation method. Because I'm not installing Python, I'm building it. If I were just interested in installing Python, I wouldn't care whether it was static or shared libraries. This is all very specific to my product. We are not just OS X, but Windows and Linux as well. Because of this, we use an SDK/ folder that has all the third-party dependencies contained within it (in a non-platform way). Frameworks are OS X-specific. I build Python within its distribution folder, and then package that same folder up into an archive that gets deposited into the SDK/ folder. The product then builds against that. -- http://mail.python.org/mailman/listinfo/python-list
Re: Shared library Python on Mac OS X 64-bit
Graham Dumpleton wrote: > > I don't understand the problem, you can say where it installs the > framework, it doesn't have to be under /Library, so can be in your > special SDK folder. For example: > > ./configure --prefix=/usr/local/python-2.5.4 \ > --enable-framework=/usr/local/python-2.5.4/frameworks \ > --enable-universalsdk=/ MACOSX_DEPLOYMENT_TARGET=10.5 \ > --with-universal-archs=all > > This would put stuff under /usr/local/python-2.5.4. While that looked promising, Graham, it didn't actually address my needs. "--with-universal-archs=all" produces binaries for "ppc" and "i386". I need 64-bit binaries (i.e., "x86_64"). Also, after building with your settings, there are no shared libraries produced. All I get is the static-link library, "libpython2.5.a", which is what I'm getting with every other configuration as well. So, indeed, I now know that I needn't place frameworks into default locations, but that doesn't really get me any closer to producing a 64-bit Python shared library. Thanks for trying, though. -- Render me gone, ||| Bob ^(===)^ -oOO--(_)--OOo- "If I owned Hell and Texas, I would rent out Texas and live in Hell." - General Phil Sheridan -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help with extension modules built in debug mode
On Wed, 27 Aug 2008 00:31:37 -0300, "Gabriel Genellina" <[EMAIL PROTECTED]> wrote: >In debug mode, python looks for hello_d.pyd - NOT hello.pyd. >Note that neither hello.dll nor hello_d.dll are recognized anymore since >version 2.5 Excellent! Thank you, Gabriel. Just what I was missing. -- http://mail.python.org/mailman/listinfo/python-list
Re: how do I stop SocketServer()?
On Wed, 27 Aug 2008 18:44:46 +0200, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote: >Alexandru Mosoi wrote: > >> supposing that I have a server (an instance of SocketServer()) that >> waits for a connection (ie is blocked in accept()) and in another >> thread i want to stop the server, how do I do that? > >By setting a timeout on the socket using socket.settimeout, and then >periodically check for an abortion condition in the server thread before >re-accepting connections. You can also poll for activity by using the select() call. For example: ... local_host = '' # Symbolic name meaning the local host server_port = socket.socket(socket.AF_INET, socket.SOCK_STREAM) server_port.bind((local_host, local_port)) server_port.listen(1) readsocks = [] readsocks.append(sync_port) # 'halt' would be your stop condition, set elsewhere while halt == False: readables, writeables, exceptions = select(readsocks, [], [], 1) # does the socket has a connection pending? if server_port in readables: # process client connection client_conn, client_addr = server_port.accept() ... -- http://mail.python.org/mailman/listinfo/python-list
Re: Ensure only single application instance.
On Fri, Aug 29, 2008 at 6:51 AM, Heston James <[EMAIL PROTECTED]> wrote: > Good afternoon all. > > I have an application/script which is launched by crontab on a regular > basis. I need an effective and accurate way to ensure that only one instance > of the script is running at any one time. You could create a named pipe in /tmp with a unique (static) name and permissions that disallow any kind of read/write access. Then simply have your script check for its existence when it starts. If it exists, then another instance of your script is running, and just terminate. Make sure your original instance removes the pipe when it exits. -- http://mail.python.org/mailman/listinfo/python-list
Happy fun time with SWIG
I have a bit of a odd arrangement here with SWIG, Python, Embedded Python and
C++ classes exported into Python. Here's the plot:
I have a class defined in a C++ DLL library. I am wrapping this class (we'll
call it "Peter") with SWIG so some of its base functionality is available in
Python. For the sake of this example, Peter has a method called get_type(),
that takes no arguments and returns an integer. This all works, and within my
Python environment I can create instances of Peter, copy them, query their
values -- everything I need to do with them. I've tested all this from the
Python interpreter with expected results. Peter exists functionally within
Python's environment.
However, I am also embedding Python into an application, an application that
needs to execute the Python module that makes heavy use of Peter (A-ha! The
plot thickens!). Peter's instance within the Python environment contains
singular data, set within the Python environment, that I need to access from
within the embedded Python code. I also use C++ instances of Peter within my
C++ code.
Here's an example of what I'm looking at:
# this is the SWIG generated Python import module
from Peter import *
class BaseClass:
def __init__(self):
self.peters = []
class SubClass(BaseClass):
def __init__(self):
BaseClass.__init__(self)
my_peter = Peter(0)
self.peters.append(my_peter)
Then, in my embedded code, after creating an instance of the Python SubClass:
...
PyObject* key = PyString_FromString("peters");
PyObject* py_peters = PyObject_GetAttr(py_SubClass_inst,key);
Py_XDECREF(key);
if(!py_peters || !PyList_Check(py_peters))
// handle this error
for(int j = 0;j < PyList_Size(py_peters);j++)
{
PyObject* py_peter = PyList_GetItem(py_peters,j);
PyObject* py_peter_method = PyObject_GetAttrString(py_peter,
"get_type");
if(!py_peter_method || !PyCallable_Check(py_peter_method))
continue;
PyThreadState* old_thread_state = PyThreadState_Swap(my_interpreter);
PyObject* pargs = Py_BuildValue("( )");
PyObject* py_peter_type = PyEval_CallObject(py_peter_method, pargs);
...
So, right here in PyEval_CallObject(), we are invoking the SWIG-generated code
to execute Peter's get_type() C++ method. However, this call is returning -1
(not a value coded into Peter's get_type() method). I debugged into the SWIG
code, and I see that I'm getting a PyExc_TypeError error, with a the message
that looks something like:
in method 'Peter_get_type', argument 1 of type 'Peter const *'
Checking the watch window, the PyObject->obj_type->tp_name of "py_peter" is
"Peter" (not "instance", as I've seen it set to before with other Python
attributes). This leads me to believe that what I'm dealing with is not
actually an instance of Peter, but rather a class template of Peter. This
confuses me, because I thought I initialized the peters[] arrays with instances.
Anybody have any helpful insights on this? Why is SWIG barfing? Am I perhaps
accessing the Peter instance incorrectly?
Many thanks in advance.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Happy fun time with SWIG
Nobody has any help for me on this one? Let me see if I can make it clearer by using something simpler: +---+ ---| Peter |--- | +---+ | | | V V +-+ +-+ | Python| | Application | | Environment | | Environment | +-+ +-+ ^ ^ | | ---<--<--< ? >-->-->--- Both environments use the C++ class Peter in their environments (Application directly, and Python via SWIG). How do I exchange instances of Peter between them? How do I get Python-environment instances of Peter with its Python-specific settings into the Application's environment (and vice versa)? OR... Does anybody know of a a SWIG-specific mailing list or forum where discussion of this type of problem would be more appropriate? -- http://mail.python.org/mailman/listinfo/python-list
