extending and embedding python without distutils
I have a rather large C++ project which has his own build system (scons) and I would prefer to stay inside scons in order to build some python extensions/embeddings (that is, I prefer to avoid using distutils directly to build my extensions). Can someone confirm that I'm doing the right thing to pick up the necessary dependencies to pick up the compilation flags (the first output line below, once I prefix it with '-I'), location of libpythonX.X.a (the second output line below, once I prefix it with '-L'), and dependent linking libraries (the last three output lines below). This is the type of thing that pkg-config normally solves on linux. (I'd have to add -lpythonX.X to my build commands, which I can do separately by grabbing the major and minor version and building up a string). >>> import distutils.sysconfig >>> for v in 'INCLUDEPY', 'LIBPL', 'LOCALMODLIBS', 'BASEMODLIBS', 'LIBS': ... print distutils.sysconfig.get_config_var(v) ... /home/rutt/.upak/installed/python-2.4/include/python2.4 /home/rutt/.upak/installed/python-2.4/lib/python2.4/config -L/home/rutt/.upak/installed/tcltk/lib -L/usr/X11R6/lib -ltk8.4 -ltcl8.4 -lX11 -lpthread -ldl -lutil The purpose of this posting is to see if anyone jumps in and says "hey, you missed a variable called ...". Thanks, -- Benjamin Rutt -- http://mail.python.org/mailman/listinfo/python-list
disable Pmw.Counter?
Does anyone know how to disable a Pmw.Counter? (make it so it cannot be changed, but you can still call the get() function to see its current value?) Thanks, -- Benjamin Rutt -- http://mail.python.org/mailman/listinfo/python-list
is open(...).read() a resource leak?
If I did the following in an infinite loop, would the host system/user
account soon run out of file descriptors? (I'm thinking no, since I'd
imagine that a file object has a __del__-like method that will call
close() automatically since it goes out of scope):
open('/home/rutt/.bashrc,'r').read()
Can anyone confirm that I'm right in seeing (1) the file object's
actual destructor is below and seems to call a close method if not
already done (at the <-- indicated lines) and (2) the method table
that makes this method the destructor? Both are in
Objects/fileobject.c in python sources.
(1)
static void
file_dealloc(PyFileObject *f)
{
if (f->f_fp != NULL && f->f_close != NULL) { <
Py_BEGIN_ALLOW_THREADS
(*f->f_close)(f->f_fp); <
Py_END_ALLOW_THREADS
}
Py_XDECREF(f->f_name);
Py_XDECREF(f->f_mode);
Py_XDECREF(f->f_encoding);
drop_readahead(f);
f->ob_type->tp_free((PyObject *)f);
}
(2)
PyTypeObject PyFile_Type = {
PyObject_HEAD_INIT(&PyType_Type)
0,
"file",
sizeof(PyFileObject),
0,
(destructor)file_dealloc, /* tp_dealloc */ <
0, /* tp_print */
0, /* tp_getattr */
0, /* tp_setattr */
0, /* tp_compare */
(reprfunc)file_repr,/* tp_repr */
0, /* tp_as_number */
[...]
Thanks,
--
Benjamin Rutt
--
http://mail.python.org/mailman/listinfo/python-list
Re: is open(...).read() a resource leak?
"Fredrik Lundh" <[EMAIL PROTECTED]> writes:
> Benjamin Rutt wrote:
>
>> If I did the following in an infinite loop, would the host system/user
>> account soon run out of file descriptors? (I'm thinking no, since I'd
>> imagine that a file object has a __del__-like method that will call
>> close() automatically since it goes out of scope):
>>
>>open('/home/rutt/.bashrc,'r').read()
>
> under CPython, this is not a problem (the reference counting system will
> make sure that file handles are reclaimed as fast as new ones are opened).
It would be reclaimed immediately, correct? (As opposed to waiting
for the next file-open call or some later time). In my understanding
of CPython gc and reference counting, only the cyclical objects will
be lazily/periodically reclaimed in a scheduled fashion, while all
non-cyclical objects are reclaimed immediately when their last
incoming reference decrements the count to 0.
> under an arbitrary Python implementation, it may be a problem,
> especially if the implementation doesn't trigger a collection if it
> runs out of handles (that can be seen as a bug, though...).
OK, makes sense, thank you.
--
Benjamin Rutt
--
http://mail.python.org/mailman/listinfo/python-list
getting list of all available modules
I note that the help() function of interactive python can determine all available modules: [EMAIL PROTECTED] ~]$ python Python 2.4 (#1, Mar 31 2005, 15:26:02) [GCC 3.2.3 (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> help() [...] help> modules Please wait a moment while I gather a list of all available modules... BaseHTTPServer bisect linuxaudiodev shelve Bastion bsddb (package) locale shlex BicycleRepairMan_Idle cPickle logging (package) shutil CDROM cStringIO macpath signal CGIHTTPServer calendarmacurl2path site Canvas cgi mailbox smtpd ConfigParsercgitb mailcap smtplib [...] I want to do the same (get all such modules in a python list); how can I do so? Or where is the code for the REPL for help() itself so I can find out myself? This is to build a code introspection tool BTW. Thanks, -- Benjamin Rutt -- http://mail.python.org/mailman/listinfo/python-list
question about introspection using inspect module
I'm trying to learn about introspection in Python. my ultimate goal
is to be able to build a module "text database" of all modules that
are in the sys.path, by discovering all candidate modules (I've
already done that), importing all of them, and then introspecting on
each module to discover its functions, globals and classes. But for
now I am having a problem with the latter.
I would like to import a module and figure out the names of its
defined functions, globals, and classes. Here's my attempt, file
foo.py, which has a single function, class, and global defined:
#!/usr/bin/env python
def somefunction(i):
i = i + 1
class someclass:
def __init__(self):
self.x = 0
self.y = 1
someglobal = 1.2
if __name__ == "__main__": # when run as a script
import foo
import inspect
from inspect import *
isfuncs = filter(lambda x: re.match("^is", x) and x, dir(inspect))
print isfuncs
print filter(lambda x: re.match("some", x[0]) and x[0], getmembers(foo))
for f in isfuncs:
exec('print "trying %20s: ",; print getmembers(foo, %s)' % (f, f))
the output of running it as a script is the following:
['isbuiltin', 'isclass', 'iscode', 'isdatadescriptor', 'isframe',
'isfunction', 'ismethod', 'ismethoddescriptor', 'ismodule', 'isroutine',
'istraceback']
[('someclass', ), ('somefunction',
), ('someglobal', 1.2)]
tryingisbuiltin: []
trying isclass: [('someclass', )]
trying iscode: []
trying isdatadescriptor: []
trying isframe: []
trying isfunction: [('somefunction', )]
trying ismethod: []
trying ismethoddescriptor: []
trying ismodule: []
tryingisroutine: [('somefunction', )]
trying istraceback: []
I was trying to use inspect.getmembers(foo, ) with an
appropriate predicate ("is" function). it looks like I am able to
discover that 'someclass' is a class, and that 'somefunction' is a
function (and also a routine, apparently). However, I cannot seem to
discover that 'someglobal' is a global. How to do so? Thanks,
--
Benjamin Rutt
--
http://mail.python.org/mailman/listinfo/python-list
Re: question about introspection using inspect module
Fernando Perez <[EMAIL PROTECTED]> writes: > I certainly don't want to discourage you from learning about python > introspection, it's one of the most fun aspects of the language. But just as > an FYI, the pydoc system already does much of what you have in mind, at least > if I'm reading your description correctly: > > planck[/tmp]> pydoc -p 12345 > pydoc server ready at http://localhost:12345/ thanks, I'm aware of that actually, and seeing all the information available there was inspiring to me. what I am actually trying to do is to build a database of Python modules. so then later, I can write a tool in my favorite editor (Emacs) to invoke some forms of completion against this database (e.g. os.remov or socket. to see a list of all socket module definitions). I was browsing pydoc.py but at first glance was having trouble separating what in the code what is for the GUI, what is for the Web server, and what does the introspection. I have actually borrowed the ModuleScanner class already, to build the list of modules. It is just inspecting those modules further where I'm having trouble. thanks, -- Benjamin Rutt -- http://mail.python.org/mailman/listinfo/python-list
.pth files question
Am I correct in understanding that: 1) foo.pth will be used if it is in the directory /usr/lib/python-2.4/site-packages 2) foo.pth will not be read from if it is only placed somewhere in the PYTHONPATH environment, such as foo.pth exists as the file /tmp/bar/foo.pth, where PYTHONPATH contains "/tmp/bar"? Thanks, -- Benjamin Rutt -- http://mail.python.org/mailman/listinfo/python-list
tkinter: always scroll to show last line of text
I have a tkinter 'Text' and 'Scrollbar' connected and working normally. When a new line of text is inserted (because I'm monitoring an output stream), I'd like the text and scrollbar to be scrolled to the bottom, so the latest line of text is always shown. How to do this? Thanks, -- Benjamin Rutt -- http://mail.python.org/mailman/listinfo/python-list
Re: tkinter: always scroll to show last line of text
Martin Franklin <[EMAIL PROTECTED]> writes:
> text.yview_pickplace("end")
Thank you, works perfectly!
--
Benjamin Rutt
--
http://mail.python.org/mailman/listinfo/python-list
tkinter: call root.after from a thread?
Let's say we have root = Tk() ... root.mainloop() Is a safe to call the method root.after(...) from a separate thread? (The registered callback updates the GUI). I know you're supposed to avoid calling methods such as pack(), etc. from a thread, but I was wondering if calling root.after() would be safe? I'm doing this in a GUI without any problems, so far. Thanks, -- Benjamin Rutt -- http://mail.python.org/mailman/listinfo/python-list
Re: pdb with emacs
"Yuri Shtil" <[EMAIL PROTECTED]> writes: > I am trying to learn python and use the gud/pdb from emacs. The > functionality that I am used to under gud/gdb and gud/perldb is missing, or > I don't know how to make it work. > Specifically: when I start pdb on a script file, the source does not show in > an another window as it does with perldb and gdb. The source appears for me if I do C-c C-s immediately after startup. > If I bring it up in an another window, the ^X SPC set a break, but > the subsequent gud-next commands do not move the execution cursor in > the source file window. I can in general set breakpoints using C-x SPC in the source buffer after the source appears, which will be hit after I resume execution. So I guess I don't observe your problems. I am using a custom "pdb" executable script though, maybe this helps: #!/bin/sh exec python $HOME/opt/python-2.3/lib/python2.3/pdb.py "$@" -- Benjamin Rutt -- http://mail.python.org/mailman/listinfo/python-list
modify a long-running python script while it is running?
I often execute a long-running python script which is a "driver" for my application; it may run for several hours on a large input. Under CPython, is it safe for me to modify the Python script and run it under some smaller inputs for test purposes, while the long-running script is still running? It seems safe to do so, but I want to be sure. I know, for example, that #!/bin/sh on my system is not safe in this regard. I suppose this question could be reformatted as "does CPython read the entire script file into memory and then close the file before executing the script, making it safe for me to modify the script after I know it has started?"[1] Thank you, Footnotes: [1] how would I know that it is started? For example, at least one print statement I am expecting has been executed. -- Benjamin Rutt -- http://mail.python.org/mailman/listinfo/python-list
sys.stdin.readline() results in extra space send to stdout
There has been a problem that has been bugging me for a while for
reading input from standard in. Consider the following simple program:
#!/usr/bin/env python
import sys
print 'enter something: ',
answer = sys.stdin.readline().strip()
print 'you answered {%s}' % (answer)
When I run this interactively, the following happens:
$ ~/tmp/foo.py
enter something: hi
you answered {hi}
Notice the extra space before 'you'; I did not put it there. It seems
that this problem can be avoided if I instead use the program:
#!/usr/bin/env python
import code
answer = code.InteractiveConsole().raw_input('enter something: ')
print 'you answered {%s}' % (answer)
Now, the output is:
$ ~/tmp/foo.py
enter something: hi
you answered {hi}
Is this a well-known problem? Is it a bug? I do not see why that
extra space is getting there in the first version. Using the code
module seems a little dirty, when sys.stdin is available. This is
python 2.4 on a Linux platform. Thank you,
--
Benjamin Rutt
--
http://mail.python.org/mailman/listinfo/python-list
tkinter: not freeing memory like I'd expect
I have a bunch (e.g. 40) of tkinter Text objects in a gui on a linux
machine, tracking monitoring info per host. They accumulate up to
500MB of text data (according to /bin/top) over time reading from
sockets. I want to release this memory first by clearing all the text
contents, but keeping the Text objects in the GUI, via a callback
like:
def erase_all_text():
for h in known_hosts_texts.keys():
t = known_hosts_texts[h]
t.config(state=NORMAL)
t.delete('1.0',END)
t.config(state=DISABLED)
But after calling the function, although the texts are cleared, no
memory is released according to /bin/top (the process is still 500MB
large). Next, I try to remove all objects from the GUI, in the hope
that will free the memory:
def clear_all():
global known_hosts
global known_hosts_frames
global known_hosts_texts
known_hosts = {}
known_hosts_frames = {}
known_hosts_texts = {}
for w in frametop.children.values():
w.destroy()
Got those last 2 lines from a Fredrik Lundh post I think. But again,
the process is still 500MB large.
I should point out that the erase_all_text() and clear_all() do what
they're told for the GUI, appearance-wise, it's just that I'd expect
the memory footprint to be reduced when they are called. The lack of
a reduction eats up my memory space and causes the out-of-memory linux
killer to fire up eventually. Am I doing anything wrong in either of
my approaches? Or should I not expect memory to be released?
--
Benjamin Rutt
--
http://mail.python.org/mailman/listinfo/python-list
