Problem with case insensitive volumes
Does anyone know of a way to get the unique pathname for files stored
on FAT32 or other case insensitive drives?
For example:
os.path.samefile('/media/usbkey/file1.jpg','/media/usbkey/FILE1.jpg')
returns True
but, is there a simple way to determine whether '/media/usbkey/
file1.jpg' or '/media/usbkey/FILE1.jpg' is the actual representation
on the device.
it matters because operations like this have meaning:
os.rename('/media/usbkey/file1.jpg','/media/usbkey/tmp')
os.rename('/media/usbkey/tmp','/media/usbkey/FILE1.jpg')
If I have a program that scans a directory for files and compares
against a stored list of pathnames, I want to be able to determine not
only that the file still exists but whether or not it has changed case
(i.e. '/media/usbkey/file1.jpg' has become '/media/usbkey/FILE1.jpg').
Any takers?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Embedding/Extending Python in/with C++: non-static members?
thanks for the responses Nick and AnonMail I'm doing a similar thing, and I would imagine others are also. 1. In a python file, set up wrapper functions that the python user actually uses (e.g FunctionA). Each function corresponds to a particular C/C++ extension function that you are exposing (e.g. CFunctionA). ... 4. Now when you enter you C/C++ function you can find your object by looking it up in some predefined table using the id. What we actually do is not use an integer but instead use a void pointer which is cast appropriately once inside C/C++. This avoids the lookup. step 4 is smart :) It's good to know that there is at least one data point of success using the approach. I won't give up just yet. -- http://mail.python.org/mailman/listinfo/python-list
Re: Embedding/Extending Python in/with C++: non-static members?
(I thought I'd follow up on this post so as not to send unsuspecting readers down a hopeless path) duh! I've obviously spent too much time with dynamic languages. The problem with what I'm trying to do is obvious: In C++ you simply can't pass pointers to call a particular instance of a C++ class method so there is no way to initialize the PyMethodDef with class methods instances. In other words, there is no callback mechanism built into the language and you are stuck with template based approaches, which obviously don't mesh very well with the Python/C API (without SWIG, Boost::Python etc). So to get a python interpreter instance to communicate with pre- existing dynamically allocated C++ objects, it looks like I need to implement some kind of lookup table approach. The static nature of the Python/C API is just too cumbersome for use with multiple interpreters and making me thing it might be better to embed just a sinlge interpreter inside my app and use multi-process communication with either pipes or sockets for the extra interpreters... -- http://mail.python.org/mailman/listinfo/python-list
Embedding/Extending Python in/with C++: non-static members?
Hi Folks:
I have a question about the use of static members in Python/C
extensions. Take the simple example from the Extending and Embedding
the Python Interpreter docs:
A simple module method:
static PyObject *
spam_system(PyObject *self, PyObject *args)
{
...
}
listed in a method table:
static PyMethodDef SpamMethods[] = {
...
{system, spam_system, METH_VARARGS,
Execute a shell command.},
...
{NULL, NULL, 0, NULL}/* Sentinel */
};
that is registered with:
PyMODINIT_FUNC
initspam(void)
{
(void) Py_InitModule(spam, SpamMethods);
}
I have an application that embed multiple interpreters. I want to be
able to register methods for each interpreter that access C++ state
data relevant to that particular interpreter. In other words I want to
be able to register non-static class members in a class like the
following:
class PythonSpamModuleInstance
{
PythonSpamModuleInstance()
{
SpamMethods[0]={system, spam_system, METH_VARARGS,Execute
a shell command.};
SpamMethods[1]={NULL, NULL, 0, NULL};
PyObject *spammodule=Py_InitModule(spam, SpamMethods); //
Needs an INCREF call?
}
~PythonSpamModuleInstance()
{
PyObject_Del(spam, SpamMethods);
}
PyObject *spam_system(PyObject *self, PyObject *args)
{
// accesses non-static data in this class
}
PyMethodDef SpamMethods[2];
PyObject *spammodule;
// Other data specific to this instance of the module
};
The idea is that each time my app launches an embedded Interpreter it
will create an accompanying instance of PythonSpamModuleInstance that
allows the Interpreter to call the registered non-static C++ member
function spam_system. Calls to that member function will also affect
state information.
So the questions: will this work? In particular, will the use of non-
static member functions cause problems? Is there a better way of
creating extension modules for multiple embedded interpreters? If I am
forced to use static methods, how do i figure out which interpreter is
calling them?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Bug/Weak Implementation? popen* routines can't handle simultaneous read/write?
On Jun 8, 12:30 pm, Nick Craig-Wood [EMAIL PROTECTED] wrote: Windows has a really strange idea of non-blocking IO - it uses something called overlapped io. You or in the FILE_FLAG_OVERLAPPED flag when you create the file/pipe. You then pass in overlap buffers for reading writing. the wx guys appear to do it differently (unless FILE_FLAG_OVERLAPPED is implicit in the calls they make) take a look at: http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/src/msw/utilsexc.cpp?rev=1.88content-type=text/vnd.viewcvs-markup a reasonably well-documented wxExecute function handles all the messy win32 api calls and wraps the process in a wxProcess object and the streams in wxInputStream / wxOutputStream (also see the wxExecuteDDE function) -- http://mail.python.org/mailman/listinfo/python-list
Bug/Weak Implementation? popen* routines can't handle simultaneous read/write?
Hi folks, I've seen the following issue come up in multiple posts to this mailing list: I have a python program that spawns a child process with popen or popen2 or popen3 or popen2.popen2 etc. the child process is interactive: it asks for input then spits out some output, asks for more input then spits out some output. for example, consider the trivial child program: print welcome print , s=raw_input() while s!='exit': print you entered:,s print , s=raw_input() Now I may be completely wrong about this (I did play with popen for a very long time before writing this message), but it appears that none of the popen variants allow for a sequence of reads and writes to/from this child. that is, if I read from the open pipe's output I will never be able to write the input for the child because the parent program will block on read until eof (I will have similar blocking problems if I start with write - using readline does not seem to help). the standard proposed remedy I have seen on this list is to use Unix- only select/fctl, or otherwise dig into the bowls of the win32 api, or download some half-complete sourceforge process control project. All well and good, but unsatisfying for writing platform independent code. it turns out that there is at least one open source multi-platform (read: win32/linux) api that does handle synchronous I/O with the child: wxWidgets and wxPython using the class wxProcess. Now the wxWidgets implementation is far from perfect, but it at least allows a program to test for new input on the child's stdout and read stdout/ write stdout in a non-blocking way. However, I find it frustrating that I have to import wx just to have useable interactive pipes in my python scripts when I would expect this to be part of the native python implementation. Anybody have any thoughts on this? Do I have my story straight? (the popen variants can't handle this case and there are no other alternatives in the standard python distro) Is there some place I can submit this as a feature request? (Python dev?) -- http://mail.python.org/mailman/listinfo/python-list
Re: Bug/Weak Implementation? popen* routines can't handle simultaneous read/write?
thanks for all of your responses. i'll look more closely at pexpect (The version I originally saw was much much older). I do want a cross- platform solution. I'm pretty busy so getting the wxProcess magic into useful shape will take me some time (at least on the order of weeks) so other interest parties feel free to step up. cheers Damien On Jun 7, 8:59 pm, Noah [EMAIL PROTECTED] wrote: On Jun 7, 9:01 am, dmoore [EMAIL PROTECTED] wrote: popen and friends will never do what you want it to do. Down that path lies bitter disappointment. You need pseduo-ttys and non-blocking IO. I don't know how to do this on Windows, but I know it's possible. Cygwin does it. Anybody have any thoughts on this? Do I have my story straight? (the popen variants can't handle this case and there are no other alternatives in the standard python distro) Is there some place I can submit this as a feature request? (Python dev?) Try Pexpecthttp://pexpect.sourceforge.net/ It's been around for a long time and is quite complete and stable. The catch is that it's UNIX-only. If you want to tease out the magic code from wxProcess that does non-blocking reads on win32 then I'd be happy to integrate that into the current development branch of Pexpect. If someone can provide a pure Python drop-in replacement for the read_nonblocking() function I use for UNIX systems then it would be easy. I have a whole test framework that I can run it through to see if it performs the same as the UNIX flavor. I'm sure this is feasible without any C extensions -- it might require some ctypes hacking. I know Windows has pretty decent async IO, but I don't know what they have as an equivalent for a pty. Maybe it isn't necessary. A pty is only necessary on UNIX because the standard c library, stdio, behaves differently when it's talking to a plain pipe versus a terminal -- it switches buffering between block and line oriented buffer. You don't want block buffering on interactive applications. This is why popen eventually breaks down. No, there is no way to select this behavior from the calling side... unless you can trick it into dynamically linking to your specially hacked libc. But that's getting ahead because that's what happens on UNIX -- it might be a non-issue on Windows. The read_nonblocking() function I use has an interface like this: pre def read_nonblocking (self, size = 1, timeout = -1): This reads at most size characters from the child application. It includes a timeout. If the read does not complete within the timeout period then a TIMEOUT exception is raised. If the end of file is read then an EOF exception will be raised. If a log file was set using setlog() then all data will also be written to the log file. If timeout is None then the read may block indefinitely. If timeout is -1 then the self.timeout value is used. If timeout is 0 then the child is polled and if there was no data immediately ready then this will raise a TIMEOUT exception. The timeout refers only to the amount of time to read at least one character. This is not effected by the 'size' parameter, so if you call read_nonblocking(size=100, timeout=30) and only one character is available right away then one character will be returned immediately. It will not wait for 30 seconds for another 99 characters to come in. This is a wrapper around os.read(). It uses select.select() to implement the timeout. /pre Yours, Noah -- http://mail.python.org/mailman/listinfo/python-list
