View Single Post
Old 09-30-2014, 11:56 AM   #72
KevinH
Sigil Developer
KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.
 
Posts: 8,959
Karma: 6361444
Join Date: Nov 2009
Device: many
Hi Kovid,

Yes, I know we can fix all of these things and work around them. I have code to do all of this and more (although using subprocess.Popen and Listener and client classes was a new one for me). It is just reaching the point of silliness. I need to carry around a library of python 2 fixes that simply should not be needed. Especially after 5 to 10 years or more! These fixes should have been incorporated into the official python 2.X years and years ago but never made it and never will.

Also, I have looked all over the python developer's mailing list archive and can not find anything that states python 2.8 will happen. In fact, all I can see if Guido clearly stating it will never happen (see the May 2014 Python conference) but he did add that support for python 2.X will continue until 2020. So where can I find a link that talks about Python 2.8 actually happening and what if any changes it includes?

Unlike 5 years ago, most of the main libraries and even scientific libraries (like numpy) now support Python 3. And python 3 seems to be the only platform getting any of these old problems fixed.

So unless I see some large group step forward to incorporate all of these fixes into a forked python 2.X series, I personally am strongly leaning towards using Python 3.4 and later when (and if) we are forced to choose one. But of course, the final call belongs to user-none on that. It is his project.

Right now, using external interpreters luckily means we do not have to choose and can support both. But then we get hit by Windows users who are reluctant to install either version!

Quote:
Originally Posted by kovidgoyal View Post
@KevinH: Fixing sys.argv is trivial, if you want I can send you some code for it. Or just use this years old recipe: http://code.activestate.com/recipes/572200/

As for multiprocessing, just dont use it. There is no need to to use it. All of calibre, which makes extensive use of worker processes never uses it. You can simply use the Listender and Client classes from the multiprocessing module to implement IPC between processes you launch with subprocess.Popen
Take care,

KevinH
KevinH is online now