Re: Threads vs Processes
On Wed, 26 Jul 2006 10:54:48 -0700, Carl J. Van Arsdall wrote: > Alright, based a on discussion on this mailing list, I've started to > wonder, why use threads vs processes. So, If I have a system that has a > large area of shared memory, which would be better? I've been leaning > towards threads, I'm going to say why. > > Processes seem fairly expensive from my research so far. Each fork > copies the entire contents of memory into the new process. There's also > a more expensive context switch between processes. So if I have a > system that would fork 50+ child processes my memory usage would be huge > and I burn more cycles that I don't have to. I understand that there > are ways of IPC, but aren't these also more expensive? > > So threads seems faster and more efficient for this scenario. That > alone makes me want to stay with threads, but I get the feeling from > people on this list that processes are better and that threads are over > used. I don't understand why, so can anyone shed any light on this? > > > Thanks, > > -carl Not quite that simple. In most modern OS's today there is something called COW - copy on write. What happens is when you fork a process it will make an identical copy. Whenever the forked process does write will it make a copy of the memory. So it isn't quite as bad. Secondly, with context switching if the OS is smart it might not flush the entire TLB. Since most applications are pretty "local" as far as execution goes, it might very well be the case the page (or pages) are already in memory. As far as Python goes what you need to determine is how much real parallelism you want. Since there is a global lock in Python you will only execute a few (as in tens) instructions before switching to the new thread. In the case of true process you have two independent Python virtual machines. That may make things go much faster. Another issue is the libraries you use. A lot of them aren't thread safe. So you need to watch out. Chance -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to C converter
If you are looking for a "real" python to C, well in this case C++ look for the shedskin compiler. It will take a rather nice subset of Python and generate C++ code from it. It is still rather experimental but I have been using it. Chance G. On Mon, 05 Jun 2006 07:19:39 -0700, Fuzzyman wrote: > > gene tani wrote: >> Rene Pijlman wrote: >> > [EMAIL PROTECTED]: >> > >I have an application return in python. I want this to be >> > >converted to C. >> > >> > http://www.python.org/doc/faq/general/#can-python-be-compiled-to-machine-code-c-or-some-other-language >> > >> >> http://pyfaq.infogami.com/can-python-be-compiled-to-machine-code-c-or-some-other-language >> shd probably mention Shedskin, boost, ctypes, any others? > > The PyPy LLVM backend will compile Python code to C. > > Also Pyrex can do a bit more than just integrate C with Python, AFAIK > it *can* compile some Python to C - although with very little speed > advantage if you don't use native C types. > > Fuzzyman > http://www.voidspace.org.uk/python/index.shtml -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to C converter
Isn't Pyrex for writing extensions to Python? As for PyPy, I didn't scroll down far enough to see the compiler info. It does say it is Python written in Python at the top. Shedskin is nothing but a compiler. On Wed, 07 Jun 2006 19:13:27 +0200, Carl Friedrich Bolz wrote: > Chance Ginger wrote: >> If you are looking for a "real" python to C, well in this case >> C++ look for the shedskin compiler. It will take a rather >> nice subset of Python and generate C++ code from it. > > > In which sense is shedskin a more "real" python to C/C++ compiler than > some of the other mentioned projects? As most of the others (PyPy, > Pyrex), Shedskin works only for a small number of Python programs that > don't mix types too wildly. > > BTW: While the RPython (the subset of the Python language that PyPy can > compile) might not be extremely advanced, using it gives you a number of > very interesting features: like having the resulting program been > enhanced to not use the C stack (for deeply recursive code), using > different garbage collection strategies... > > Cheers, > > Carl Friedrich Bolz -- http://mail.python.org/mailman/listinfo/python-list
Re: Way for see if dict has a key
On Fri, 30 Jun 2006 10:19:46 +, Michele Petrazzo wrote: > Hi ng, > what the preferred way for see if the dict has a key? > We have a lot of solutions: > > key in dict > key in dict.keys() > dict.has_key(key) > ... > > but what the better or the more "pythonic"? > > Thanks, > Michele It is a religious call -- http://mail.python.org/mailman/listinfo/python-list
Writing an applilcation that can easily adapt to any language
I am rather new at Python so I want to get it right. What I am doing is writing a rather large application with plenty of places that strings will be used. Most of the strings involve statements of one kind or another. I would like to make it easy for the support people to port the application from one language to another, German, Spanish, etc. Rather than make them search all over for the strings to replace is there a library that I can use to make this all easier? I keep thinking of resources in Java, as an example. Is there anything like it in Python? Peace, Chance. -- http://mail.python.org/mailman/listinfo/python-list
Writing 'C' structures out in cPickle format?
I have a problem that I am trying to solve. I have two different systems - one written in C and another in Python. I would like the two to exchange some information. On the Python side I decided to use cPickle. On the C side I would write a library that can read the cPickle and generate the correct C structure (the data is, more or less, self-describing) and visa versa. I was wondering if anyone has done something like this before and if so can they point me to information on how to easily do it? The structures I am using on the C side are pretty simple (very flat and using only integers and strings). -- http://mail.python.org/mailman/listinfo/python-list
Detecting arguments of a function - possible?
I am trying to write a tool to examine a function (I'd like it to work with pyc files only). So here are a few questions I have; any pointers would be very welcome. Can I determine the number of arguments required of a function? Is there a way to detect is the function will throw an exception (I don't care under what conditions just that it is possible)? Thanks in advance... Chas. -- http://mail.python.org/mailman/listinfo/python-list
Decorators, Identity functions and execution...
If I define a decorator like: def t(x) : def I(x) : return x return I and use it like: @t(X) def foo(a) : # definition of foo... pass or maybe this: @t(X) @(Y) def bar(a) : # The definition of bar... Will in encounter much of a penalty in executing 'foo' or 'bar'? If so, is there a way to define t such that Python knows it is the identity function and short-circuit evaluation? Thanks in advance. -- http://mail.python.org/mailman/listinfo/python-list
Re: Decorators, Identity functions and execution...
On Sun, 09 Apr 2006 09:51:18 +0200, Fredrik Lundh wrote: > Chance Ginger" wrote: > >> If I define a decorator like: >> >> def t(x) : >> def I(x) : return x >> return I > > ... you get a syntax error. > It isn't a syntax error...I tried it before I posted. In fact def t(x) : def I(x) : return x return I is correct. >> and use it like: >> >> @t(X) >> def foo(a) : >> # definition of foo... >> pass > > that's also a syntax error. Once again this isn't an error assuming you pass in a valid 'X'. > >> or maybe this: >> >> @t(X) >> @(Y) >> def bar(a) : >> # The definition of bar... > > and that's not even fixable. > Again you are mistaken. If I say: @t(1) @t(2) def bar(a) : pass It is perfectly valid. >> Will in encounter much of a penalty in executing >> 'foo' or 'bar'? > > since foo is wrapped, calling foo will call your I function, which in > turn calls the original foo. > >> If so, is there a way to define t such that Python knows it is >> the identity function and short-circuit evaluation? > > if you don't want to wrap something, don't wrap it: > > def t(x) : > def I(x) : > return x > if date == friday: > return x # don't wrap it > return I # wrap it > > Decorators are a way to add "syntactic" sugar to Python, extending it in ways that make it useful for tools. What I am trying to do is lessen the impact on the time used in executing Python code when I use some forms of decorators. -- http://mail.python.org/mailman/listinfo/python-list
Re: Decorators, Identity functions and execution...
First, thanks for the tip of 'tabs'. I keep forgetting Outlook has some interesting rules about displaying text. Thanks for the comment about happening at load time. That resolved the problem (in my thinking)! I don't believe I have an issue at all... Peace, CG. On Sun, 09 Apr 2006 08:52:18 -0700, Carl Banks wrote: > > Chance Ginger wrote: >> On Sun, 09 Apr 2006 09:51:18 +0200, Fredrik Lundh wrote: >> >> > Chance Ginger" wrote: >> > >> >> If I define a decorator like: >> >> >> >> def t(x) : >> >> def I(x) : return x >> >> return I >> > >> > ... you get a syntax error. >> > >> >> It isn't a syntax error...I tried it before I posted. In fact >> def t(x) : >> def I(x) : return x >> return I >> >> is correct. > > You've made the unfortunate mistake of indenting it with tabs, which do > not show up on some newsreaders. I see the tabs in Google; people > using Microsoft Outlook do not. > > Always use spaces when posting, and use them in your code as well. > Spaces are the current recommended practice, and in the future tabs > might become illegal. I'd prefer tabs myself, but it's more important > to respect community standards than to stick to some silly preference > you have. > > >> Decorators are a way to add "syntactic" sugar to Python, >> extending it in ways that make it useful for tools. What >> I am trying to do is lessen the impact on the time used >> in executing Python code when I use some forms of decorators. > > One suggestion. Have you run the script, determined it's too slow, and > are trying to optimize? If not (and it doesn't sound like you are), I > suggest that it's too soon to worry about whether this decorator has > any overhead. You may end up doing a lot of work optimizing that will > ultimately have very little benefit. > > Having said that, this decorator will not affect calling overhead at > all. The decorator is applied when the module is loaded, not when the > decorated function is called. > > > Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
