Python 2.4 final is out and has a new subprocess module

Post #185,841 by FuManChu 12/2/04 12:26:13 PM Reply	Python 2.4 final is out and has a new subprocess module ...to address the same forking issue you mention. Seems it's a common issue. ;) It also sports: - Lots of new C code for speed improvements. - Function decorators. - Generator expressions. sum(x*x for x in xrange(10)) doesn't create an intermediate list. - built in set type. - unified ints and longs. - built in Decimal type. - a newly-non-recursive SRE engine (for regular expressions). - reverse iteration support. [link\|http://www.python.org\|http://www.python.org]
Post #185,843 by Another Scott 12/2/04 12:52:59 PM 12/2/04 5:12:42 PM Reply	Does it work with eudora2mbox.py? Yes, it does. Grr.... Funny this thread starting just as I'm trying to get python 2.4 working with [link\|http://www.gnist.org/~lars/code/eudora2mbox/eudora2mbox.html\|eudora2mbox]. It's a python script for cleaning up the HTML in Eudora e-mail boxes before they're imported into Thunderbird. I installed the Windows version of 2.4 (using the .msi installer) from python.org I installed all the options in d:\\lang\\python\\python24\\. It seems to work fine when started from d:\\lang\\python\\python24. I added python to the Path (appended ";d:\\lang\\python\\python24") via Start -> ControPanel -> System -> Advanced -> EnvironmentVariables -> SystemVariables -> Path -> Edit. Is that sufficient? I would think that the installer would have modified the Path if it was needed... On running the script in either the python or the Eudora root directory I get: d:\\tcpip\\eudora42>eudora2mbox.py -r d:/tcpip/eudora42/ -o d:/tcpip/Thunderbird/mail/ From Eudora 'd:/tcpip/eudora42/' to M/T 'd:/tcpip/Thunderbird/mail/': ERROR: unable to read file! d:/tcpip/eudora42\\Out.mbx The d:\\tcpip\\Thunderbird\\mail directory was created by the script, but nothing's in it. Out.mbx exists (it's a 0 byte file). In.mbx gives the same results (it's 2 MB): d:\\tcpip\\eudora42>eudora2mbox.py In.mbx ERROR: unable to read file! In.mbx I've sent an e-mail to the author, but any help here would be greatly appreciated. I'm at a loss. :-( [edit:] For posterity: I tried python 2.4 from python.org, 2.3.4 from python.org and 2.4.0 from ActiveState with the same results. Lars was quite responsive, but couldn't find anything wrong. He said he's used it on many Windows boxes without incident. After much playing around, I found that if I replaced every instance of "concat" with "open" in the [link\|http://www.gnist.org/~lars/code/eudora2mbox/eudora2mbox.py\|eudora2mbox.py] file that it worked fine. I'm not sure of the implications of doing that, but it worked for me (on 2.4.0 from ActiveState). I sent him a note. Oh, and Lars says that 0.9 has better Eudora importing capabilities so his script is not as important as it was earlier. [/edit:] [edit2:] The [link\|http://z.iwethey.org/forums/render/content/show?contentid=116753\|concat] bug was biting me again! Grr. Privoxy replaced "open" with "concat" and broke the script. My replacing "concat" with "open" fixed it. There's nothing wrong with Lars's source. I've got to get a better proxy or something... [/edit2:] Cheers, Scott. Edited by Another Scott Dec. 2, 2004, 04:53:10 PM EST Edited by Another Scott Dec. 2, 2004, 05:12:42 PM EST Expand All History
Post #185,846 by admin 12/2/04 1:00:41 PM Reply	They need to get rid of the global interpreter lock Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #185,925 by FuManChu 12/3/04 12:24:30 PM Reply	Feel free to submit a patch ;)
Post #185,937 by admin 12/3/04 1:11:33 PM Reply	I don't need to. [link\|http://www.python.org/ftp/python/contrib-09-Dec-1999/System/threading.README\|http://www.python.or.../threading.README] But removing the GIL slows down Python's speed on single CPU machines. What I'd like to see is either a) a compilation switch that incorporates the patches if you are going to run on SMP or b) a run-time switch that does the same. The alternative is to just use cross-process communication and multiple Python processes, such as Twisted does. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #185,943 by FuManChu 12/3/04 1:41:58 PM Reply	Multiprocess is indeed the way to go What are you trying to build that needs multiple threads across processors?
Post #185,927 by ChrisR 12/3/04 12:29:40 PM Reply	Does this effect only the C API's? Seems like being able to mark things as threadsafe (or unsafe) would be the way to go.
Post #185,932 by FuManChu 12/3/04 12:46:46 PM Reply	It already does that for a good chunk of C code The GIL only locks the interpretation of Python bytecodes. So any C call can potentially release the GIL (and make that thread wait for the call to finish, at which point it reacquires the lock and proceeds). I/O is a pretty common use case for this. Note too, that each process has its own GIL.
Post #185,936 by admin 12/3/04 1:10:37 PM Reply	Not quite. The GIL locks the access of Python objects as well as the interpretation of the byte codes. So to do any real work with Python in C you still have to obtain the lock. It's basically cooperative multi-tasking. Additionally, if you create a thread in C, you have to set up a bunch of Python thread bookkeeping structures that will be used by the interpreter as well. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."

Welcome to IWETHEY!