ANN: PySizer 0.1
I'd like to announce the first release of PySizer, a memory usage profiler for Python code. PySizer was written as part of Google's Summer of Code. The source, documentation and so on are at http://pysizer.8325.org. The current release is at http://pysizer.8325.org/dist/sizer-0.1.tar.gz. The code is kept in a Subversion repository at http://codespeak.net/svn/user/nick8325/sizer. The idea is to take a snapshot of memory use at some time, and then use the functions of the profiler to find information about it. Features * You can make a snapshot of all reachable objects at a given time, organised as a tree (well, a graph, since there are cycles). * For any given object, you can find out how much space it takes up, what objects it references and so on. With a patched version of Python, you can also find out what stack of function calls created an object, and what objects were created by each stack of calls. * You can collect objects into groups. For example, you can group each object according to the module it appears to come from. Then you can treat each module as a single object. * You can filter objects, find the amount of space used by instances of each type, find objects which appeared from one snapshot to the next, find the biggest objects/types/groups, and so on. Requirements See http://pysizer.8325.org/INSTALL. The main one is Python 2.4 - I will port it to 2.3 soon. Bugs, suggestions, comments, problems, anything else You can contact me at [EMAIL PROTECTED] I would love to know if you find a use for it, too. -- http://mail.python.org/mailman/listinfo/python-list
Re: PySizer 0.1
Claudio Grondi wrote: > A small hint about the Web-site: > At least to me, the links to the documentation as e.g. > > http://pysizer.8325.org/doc/auto/home/nick/sizer-trunk/doc/auto/scanner.html > are broken (no big thing, because the distro has it anyway). > Oops. That should be fixed now. -- http://mail.python.org/mailman/listinfo/python-list
Re: func(*params)
David Duerrenmatt wrote: > Hi there > > For some reasons, I've to use Python 1.5.2 and am looking for a workaround: > > In newer Python versions, I can call a function this way: > > func = some_function > func(*params) > I think the "apply" function is what you want: apply(object[, args[, kwargs]]) -> value Call a callable object with positional arguments taken from the tuple args, and keyword arguments taken from the optional dictionary kwargs. Note that classes are callable, as are instances with a __call__() method. Deprecated since release 2.3. Instead, use the extended call syntax: function(*args, **keywords). -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie: returning dynamicly built lists (using win32com)
I'm afraid I don't have a Windows machine to test on, but.. Ransom wrote: > I get an error like: > [ 0x15450880>] > This isn't an error. This is a list with one element, where the element apparently represents a range of Excel cells. So by using that element you can do things like changing the formatting of the cell, as well as finding out what data is in there. It looks like you might need to use excel.ActiveSheet.Cells(32, 6).Value to get the contents of cell (32, 6). (It depends on what Excel calls it, of course, so if it's not that have a look at Excel's VBA documentation to see if it mentions anything.) Nick -- http://mail.python.org/mailman/listinfo/python-list
Re: Clarity: GIL, processes and CPUs etc
[EMAIL PROTECTED] wrote: > I have been reading many of the posting on the GIL and impact on > threading etc. > I have found is confusing and would welcome some clarity on this. > > I understand that embedding the interpreter in a C/C++ application > limits it to one CPU. > If the application is multi-threaded (system threads) in will not use > additional CPUs as the interpreter is tied to one CPU courtesy of the > GIL. > True or False? > As I understand it, the interpreter needs the GIL held in order to run. That means that you can only run Python code on one CPU at once, but plain C/C++ code can be multithreaded. > I understand that forking or running multiple process instances of the > above application would make use of multiple CPUs. This is because each > process would have its own interpreter and GIL that is independent of > any other process. > True or False? > I suppose it would, yes. But this is just like running multiple copies of Python, in that you won't be able to use PyObject *s from one instance in another directly, so the multiple processes would have to communicate by sockets or IPC or some other way. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to force creation of a .pyc?
mrstephengross wrote: > I would like to distribute a python program, but only in .pyc form (so > that people cannot simply look at my code). Is there a way to do this? > I've read up a little on the logic by which python creates .pyc's, and > it sounds like python requires the main executed program to be in .py > format. Any ideas? > If your main program is in main.py, you could perhaps launch it with python -c "import main", or make another file which just does import main. Then you could keep just the .pycs/.pyos. But it's possible for a determined user to recover a lot of information about the source code. For example, if I write def foo(a): for i in range(a): print i then >>> dis.dis(foo) 2 0 SETUP_LOOP 25 (to 28) 3 LOAD_GLOBAL 0 (range) 6 LOAD_FAST0 (a) 9 CALL_FUNCTION1 12 GET_ITER >> 13 FOR_ITER11 (to 27) 16 STORE_FAST 1 (i) 3 19 LOAD_FAST1 (i) 22 PRINT_ITEM 23 PRINT_NEWLINE 24 JUMP_ABSOLUTE 13 >> 27 POP_BLOCK >> 28 LOAD_CONST 0 (None) 31 RETURN_VALUE where 0..12 makes an iterator for range(a), 16..19 updates i and 22..23 prints it out. It would be possible to turn it into equivalent source code. Decompyle (from http://ftp.debian.org/debian/pool/main/d/decompyle/decompyle_2.3.2.orig.tar.gz) can even do that. -- http://mail.python.org/mailman/listinfo/python-list
Re: __getattr__ and functions that don't exist
Erik Johnson wrote: > Maybe I just don't know the right special function, but what I am wanting to > do is write something akin to a __getattr__ function so that when you try to > call an object method that doesn't exist, it get's intercepted *along with > it's argument*, in the same manner as __getattr__ intercepts attributes > references for attributes that don't exist. > > > This doesn't quite work: > > >>> class Foo: > ... def __getattr__(self, att_name, *args): > ... print "%s%s" % (att_name, str(tuple(*args))) > ... > >>> f = Foo() The problem is that the call to f.bar happens in two stages: the interpreter calls getattr(f, "foo") to get a function, and then it calls that function. When __getattr__ is called, you can't tell what the parameters of the function call will be, or even if it'll be called at all - someone could have run "print f.bar". Instead, you can make __getattr__ return a function. Then *that* function will be called as f.bar, and you can print out its arguments there: class Foo: def __getattr__(self, attr): def intercepted(*args): print "%s%s" % (attr, args) return intercepted -- http://mail.python.org/mailman/listinfo/python-list
Re: About IDLE?
Sybren Stuvel wrote: > Dr. Pastor enlightened us with: > > When I select Run Module in the Edit window, I got only > > two >>> after the RESTART line. > > I expected to see the output of several commands! > > You never gave it any commands that print output. > > I suggest reading the Python tutorial. > To be more specific, when you type in an expression at the Python prompt, it will evaluate it and then print it (if it doesn't evaluate to None). In a module it doesn't do that, as then you'd have all sorts of things printed out modules were imported. -- http://mail.python.org/mailman/listinfo/python-list
Re: About IDLE?
Dr. Pastor wrote: > Any reply? > ahem. three replies, when i counted: http://groups.google.com/group/comp.lang.python/browse_frm/thread/ab0c8455251e616c/ -- http://mail.python.org/mailman/listinfo/python-list
Re: C-API: A beginner's problem
Duncan Booth wrote: > Heikki Salo wrote: > > > > > And closer look tells that the code should not even compile. Is the > > code cut & pasted directly? Line "list[i] = item;" tries to assign a > > pointer to an int-array, which should not compile. There are other > > similar oddities. > > ... such as the declaration of list at a point in the code which is not > permitted in C, and using a non constant value for the length (which is > also not allowed). They are allowed in C99, according to GCC's manual. -- http://mail.python.org/mailman/listinfo/python-list
