Python-Dev December 2012

python-dev@python.org

102 participants
77 discussions

Re: [Python-Dev] How old Python version should be supported in tests?

by Benjamin Peterson

2012/12/27 Serhiy Storchaka <storchaka(a)gmail.com>: > четвер 27 грудень 2012 18:24:37 ви написали: >> It would be great if it could all be killed, but I suppose it might be >> in some externally maintained module. Which tests? > > They are bsddb, sqlite3, ctypes and multiprocessing. I don't see the point in permuting thing too much in the 2.7 branch. -- Regards, Benjamin

8 years, 9 months

How old Python version should be supported in tests?

by Serhiy Storchaka

I found a code like "if sys.version_info < (2, 4):" in some tests. Should old versions (< 2.6) be supported in tests? Can such support code be removed (note that other tests likely doesn't compatible with old versions)?

8 years, 9 months

Re: [Python-Dev] Running GUI and "GObject.mainloop.run()" together?

by Ajay Garg

Oops.. I am extremely sorry for posting to Python-Dev (I did not intend to; just a bad habit of "Reply-to-All"). Sorry again. On Thu, Dec 27, 2012 at 1:28 AM, Glyph <glyph(a)twistedmatrix.com> wrote: > On Dec 25, 2012, at 9:05 AM, Ajay Garg <ajaygargnsit(a)gmail.com> wrote: > > > Also, I think I am now starting to get a hang of things; however, one > doubt solved raises another doubt :D > > > > The reason I began looking out for the two-threads-approach, is because > when trying to use the GUI (Gtk) application as a dbus-service, I was > getting the error "This connection was not provided by any of .service > files". > > Please stop cross-posting this to the python-dev list. It isn't > appropriate, as several people have said already. > > -glyph > > -- Regards, Ajay

8 years, 9 months

push changesets hooks failing

by Jesus Cea

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I got this when pushing: """ jcea@ubuntu:~/hg/python/cpython$ hg push pushing to ssh://hg@hg.python.org/cpython/ searching for changes searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 4 changesets with 9 changes to 3 files remote: buildbot: change(s) sent successfully remote: sent email to roundup at report(a)bugs.python.org remote: notified python-checkins(a)python.org of incoming changeset 0ffaf1079a7a remote: error: incoming.irker hook raised an exception: [Errno 111] Connection refused remote: notified python-checkins(a)python.org of incoming changeset 3801ee5d5d73 remote: error: incoming.irker hook raised an exception: [Errno 111] Connection refused remote: notified python-checkins(a)python.org of incoming changeset b6a9f8fd9443 remote: error: incoming.irker hook raised an exception: [Errno 111] Connection refused remote: notified python-checkins(a)python.org of incoming changeset 3f7d5c235d82 remote: error: incoming.irker hook raised an exception: [Errno 111] Connection refused """ - -- Jesús Cea Avión _/_/ _/_/_/ _/_/_/ jcea(a)jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQCVAwUBUNsdf5lgi5GaxT1NAQKuzQP+IPef5nx00zKdUwL4LoLDds05Dl+WtrFu Vs+Nvm4haa1+NNJ1owodtA5Xp01pDhMrhv4dvFcfEdbF2zLi3h8Xo+9oO6sEGhqE cMJZJxRCa4RdC9zpFzw0jWS7Udn/j91veWqaR/HLPYeKWcaXqWOegI+f2aoCBbQ7 5cd8Ynqihxw= =xUEy -----END PGP SIGNATURE-----

8 years, 9 months

Raising OSError concrete classes from errno code

by Andrew Svetlov

Currently we have exception tree of classes inherited from OSError When we use C API we can call PyErr_SetFromErrno and PyErr_SetFromErrnoWithFilename[Object] functions. This ones raise concrete exception class (FileNotFoundError for example) looking on implicit errno value. I cannot see the way to do it from python. Maybe adding builtin like exception_from_errno(errno, filename=None) make some value? Function returns exception instance, concrete class depends of errno value For example if I've got EPOLLERR from poller call I can get error code via s.getsockopt(SOL_SOCKET, SO_ERROR) but I cannot raise concrete exception from given errno code. -- Thanks, Andrew Svetlov

8 years, 9 months

PEP 3145 (With Contents)

by Eric Pruitt

Alright, I will re-submit with the contents pasted. I never use double backquotes as I think them rather ugly; that is the work of an editor or some automated program in the chain. Plus, it also messed up my line formatting and now I have lines with one word on them... Anyway, the contents of PEP 3145: PEP: 3145 Title: Asynchronous I/O For subprocess.Popen Author: (James) Eric Pruitt, Charles R. McCreary, Josiah Carlson Type: Standards Track Content-Type: text/plain Created: 04-Aug-2009 Python-Version: 3.2 Abstract: In its present form, the subprocess.Popen implementation is prone to dead-locking and blocking of the parent Python script while waiting on data from the child process. Motivation: A search for "python asynchronous subprocess" will turn up numerous accounts of people wanting to execute a child process and communicate with it from time to time reading only the data that is available instead of blocking to wait for the program to produce data [1] [2] [3]. The current behavior of the subprocess module is that when a user sends or receives data via the stdin, stderr and stdout file objects, dead locks are common and documented [4] [5]. While communicate can be used to alleviate some of the buffering issues, it will still cause the parent process to block while attempting to read data when none is available to be read from the child process. Rationale: There is a documented need for asynchronous, non-blocking functionality in subprocess.Popen [6] [7] [2] [3]. Inclusion of the code would improve the utility of the Python standard library that can be used on Unix based and Windows builds of Python. Practically every I/O object in Python has a file-like wrapper of some sort. Sockets already act as such and for strings there is StringIO. Popen can be made to act like a file by simply using the methods attached the the subprocess.Popen.stderr, stdout and stdin file-like objects. But when using the read and write methods of those options, you do not have the benefit of asynchronous I/O. In the proposed solution the wrapper wraps the asynchronous methods to mimic a file object. Reference Implementation: I have been maintaining a Google Code repository that contains all of my changes including tests and documentation [9] as well as blog detailing the problems I have come across in the development process [10]. I have been working on implementing non-blocking asynchronous I/O in the subprocess.Popen module as well as a wrapper class for subprocess.Popen that makes it so that an executed process can take the place of a file by duplicating all of the methods and attributes that file objects have. There are two base functions that have been added to the subprocess.Popen class: Popen.send and Popen._recv, each with two separate implementations, one for Windows and one for Unix based systems. The Windows implementation uses ctypes to access the functions needed to control pipes in the kernel 32 DLL in an asynchronous manner. On Unix based systems, the Python interface for file control serves the same purpose. The different implementations of Popen.send and Popen._recv have identical arguments to make code that uses these functions work across multiple platforms. When calling the Popen._recv function, it requires the pipe name be passed as an argument so there exists the Popen.recv function that passes selects stdout as the pipe for Popen._recv by default. Popen.recv_err selects stderr as the pipe by default. "Popen.recv" and "Popen.recv_err" are much easier to read and understand than "Popen._recv('stdout' ..." and "Popen._recv('stderr' ..." respectively. Since the Popen._recv function does not wait on data to be produced before returning a value, it may return empty bytes. Popen.asyncread handles this issue by returning all data read over a given time interval. The ProcessIOWrapper class uses the asyncread and asyncwrite functions to allow a process to act like a file so that there are no blocking issues that can arise from using the stdout and stdin file objects produced from a subprocess.Popen call. References: [1] [ python-Feature Requests-1191964 ] asynchronous Subprocess http://mail.python.org/pipermail/python-bugs-list/2006-December/ 036524.html [2] Daily Life in an Ivory Basement : /feb-07/problems-with-subprocess http://ivory.idyll.org/blog/feb-07/problems-with-subprocess [3] How can I run an external command asynchronously from Python? - Stack Overflow http://stackoverflow.com/questions/636561/how-can-i-run-an-external- command-asynchronously-from-python [4] 18.1. subprocess - Subprocess management - Python v2.6.2 documentation http://docs.python.org/library/subprocess.html#subprocess.Popen.wait [5] 18.1. subprocess - Subprocess management - Python v2.6.2 documentation http://docs.python.org/library/subprocess.html#subprocess.Popen.kill [6] Issue 1191964: asynchronous Subprocess - Python tracker http://bugs.python.org/issue1191964 [7] Module to allow Asynchronous subprocess use on Windows and Posix platforms - ActiveState Code http://code.activestate.com/recipes/440554/ [8] subprocess.rst - subprocdev - Project Hosting on Google Code http://code.google.com/p/subprocdev/source/browse/doc/subprocess.rst?spec=s… [9] subprocdev - Project Hosting on Google Code http://code.google.com/p/subprocdev [10] Python Subprocess Dev http://subdev.blogspot.com/ Copyright: This P.E.P. is licensed under the Open Publication License; http://www.opencontent.org/openpub/. On Tue, Sep 8, 2009 at 22:56, Benjamin Peterson <benjamin(a)python.org> wrote: > 2009/9/7 Eric Pruitt <eric.pruitt(a)gmail.com>: >> Hello all, >> >> I have been working on adding asynchronous I/O to the Python >> subprocess module as part of my Google Summer of Code project. Now >> that I have finished documenting and pruning the code, I present PEP >> 3145 for its inclusion into the Python core code. Any and all feedback >> on the PEP (http://www.python.org/dev/peps/pep-3145/) is appreciated. > > Hi Eric, > One of the reasons you're not getting many response is that you've not > pasted the contents of the PEP in this message. That makes it really > easy for people to comment on various sections. > > BTW, it seems like you were trying to use reST formatting with the > text PEP layout. Double backquotes only mean something in reST. > > > -- > Regards, > Benjamin >

8 years, 9 months

Re: [Python-Dev] Running GUI and "GObject.mainloop.run()" together?

by Ajay Garg

Thanks Simon. Thanks for the extensive info; however it needs some hours (if not days :P) to be digested. On Tue, Dec 25, 2012 at 9:24 PM, Simon McVittie < simon.mcvittie(a)collabora.co.uk> wrote: > On 24/12/12 08:26, Ajay Garg wrote: > > For a recap of the brief history, I have a parent process, that is > > spawning a child process via "subprocess". > > Currently, the child-process is a GUI process; however, I intend to > > "behave" it as a dbus-service as well. > > In general that is something that can work, but it's necessary to > understand a bit about how main loops work, and how the modules of your > process deal with a main loop. > > Just saying "GUI" is not very informative: there are dozens of GUI > frameworks that you might be using, each with their own requirements and > oddities. If you say Gtk, or Qt, or Tk, or Windows MFC, or whatever > specific GUI framework you're using, then it becomes possible to say > something concrete about your situation. > > Based on later mails in the thread you seem to be using Gtk. > > I should note here that you seem to be using PyGtk (the "traditional" > Gtk 2 Python binding), which is deprecated. The modern version is to use > PyGI, the Python GObject-Introspection binding, and Gtk 3. > > When using PyGI, you have a choice of two D-Bus implementations: either > GDBus (part of gi.repository.GIO), or dbus-python ("import dbus"). I > would recommend GDBus, since dbus-python is constrained by backwards > compatibility with some flawed design decisions. > > However, assuming you're stuck with dbus-python: > > > I then used composition, wherein another class, "RemoteListener" > > deriving from "dbus.service.Object" was made an attribute of the "main" > > class. That worked. > > However, when I do > > > > dbus.mainloop.glib.DBusGMainLoop(set_as_default=True) > > GObject.mainloop.run() > > > > in the "RemoteListener"'s __init__ method, the GUI of the "main" class > > fails to load (apparently, because the "mainloop.run()" causes the > > singular, main-thread to go into busy-wait). > > Almost; it's not a busy-wait. GObject.mainloop.run() is the equivalent > of this pseudocode: > > def run(self): > while not global_default_main_context.someone_has_called_quit: > if global_default_main_context.has_more_events(): > global_default_main_context.process_next_event() > else: > global_default_main_context.wait_for_an_event() > > so it will loop until someone calls GObject.mainloop.quit() or > equivalent, or forever if that never happens - but as long as nothing > "interesting" happens, it will block on a poll() or select() syscall in > what my pseudocode calls wait_for_an_event(), which is the right thing > to do in event-driven programming like GLib/Gtk. > > (If you replace the last line of my pseudocode with "continue", that > would be a busy-wait.) > > > I tried option b), but now instantiating "RemoteListener" in a separate > > thread > > It is unclear whether the dbus-glib main loop glue (as set up by > DBusGMainLoop) is thread-safe or not. The safest assumption is always > "if you don't know whether foo is thread-safe, it probably isn't". In > any case, if it *is* thread-safe, the subset of it that's exposed > through dbus-python isn't enough to use it in multiple threads. > > GDBus, as made available via PyGI (specifically, gi.repository.GIO), is > known to be thread-safe. > > > Is there a way to run GUI and a dbus-service together? > > The general answer: only if either the GUI and the D-Bus code > run in different threads, or if they run in the same thread and can be > made to share a main context. > > The specific answer for Gtk: yes, they can easily share a main context. > > This: > > > dbus.mainloop.glib.DBusGMainLoop(set_as_default=True) > > sets up dbus-python's mainloop integration to integrate with the global > default main-context in GLib (implementation detail: it currently uses > dbus-glib to do that). What that means is that whenever a D-Bus > connection started by dbus-python wants to listen for events on a > socket, or wait for a timeout, it will ask GLib to add those to the > global default main context as event sources. > > This: > > > GObject.mainloop.run() > > iterates GLib's global default main context, analogous to the pseudocode > I mentioned before. Any "interesting" events that happen will cause your > code to be executed. > > A typical GUI application also needs to run the main loop to > wait for events. In PyGtk, you'd typically do that with: > > > Gtk.main() > > Gtk also uses GLib's global default main context, so this is pretty > similar to GObject.mainloop.run() - if you just remove the call to > GObject.mainloop.run() and use Gtk.main() instead, everything should be > fine. > > > As per http://www.pygtk.org/pygtk2reference/class- > > gobjectmainloop.html, it seems that we must be able to add event > > sources to gobject.mainloop > > Yes. For instance, gobject.timeout_add(), gobject.idle_add() and > gobject.io_add_watch() all add event sources to the default main context. > > dbus.mainloop.glib.DBusGMainLoop(set_as_default=True) tells dbus-python > that when it needs to add an event source to "the" main loop, it should > use equivalent C functions in GLib to do so. > > (In principle, DBusGMainLoop ought to take a GObject.MainContext as an > optional argument - but that's never been implemented, and it currently > always uses the default main context, which is the same one Gtk uses, > and which should only be iterated from the main thread.) > > > Once the event sources are added, each instance of gobject.mainloop > > (in its particular thread), will cater to only those sources. > > No, that's not true; gobject.mainloop is a namespace for a set of global > functions, not an object. If you must use multiple threads (not > recommended), please see the GLib C API documentation for details of how > main loops and main contexts relate, then the PyGtk documentation to see > how that translates into Python. > > > How is dbus."mainloop.glib.DBusGMainLoop(set_as_default=True)" > > related to gobject.mainloop? > > It instantiates a new DBusGMainLoop and sets it as dbus-python's global > default main-loop-integration object. (With hindsight, DBusGMainLoop was > a poor choice of name - it should have been DBusGMainIntegration or > something.) The result is that whenever a new dbus.connection.Connection > is instantiated, it will call methods on that DBusGMainLoop to connect > its event sources up to the default GLib main context, which is the same > one used by Gtk. > > dbus.bus.BusConnection, dbus.Bus, dbus.SessionBus etc. are > dbus.connection.Connection subclasses, so anything I say about > dbus.connection.Connection applies equally to them. > > > How is dbus."mainloop.glib.DBusGMainLoop(set_as_default=False)" > > related to gobject.mainloop? > > It instantiates a new DBusGMainLoop and doesn't use it for anything. If > you save the returned DBusGMainLoop in a variable (e.g. > my_dbus_g_main_loop = DBusGMainLoop(...)), then you can pass a keyword > argument mainloop=my_dbus_g_main_loop to a dbus.connection.Connection > constructor, and that dbus.connection.Connection will use that > DBusGMainLoop instead of dbus-python's global default. In practice, only > a very unusual application would need to do that. > > There is currently no point in having more than one DBusGMainLoop; it > would become useful if dbus-glib was thread-safe, and if dbus-python > supported non-default GLib main-contexts. > > > Is it necessary at all to specify > > "mainloop.glib.DBusGMainLoop(set_as_default=True)" or > > "mainloop.glib.DBusGMainLoop(set_as_default=False)" when using > > gobject.mainloop? > > Yes. Otherwise, dbus-python has no way to know that your application is > going to be iterating the GLib main loop, as opposed to Qt or Tk or > Enlightenment or something. > > > currently for the client, I am having the (client) (parent) process > > run the command "dbus-send" via the python-subprocess API. > > Does there exist a python API to do it in a cleaner manner? > > Yes, either dbus-python or GDBus. Each of those can do everything > dbus-send can, and more. > For a start, could you please point me to the paradigm to send a dbus-signal from the client to the server (where the server has the "add_to_signal_receiver" been set up). >From the limited googling that I did, I remember someone saying that for sending a signal, the typical setting-up-of-a-proxy-object is not required; however, I could not hit upon the exact dbus-python mechanism to send a signal :-\ > > S > _______________________________________________ > dbus mailing list > dbus(a)lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dbus > -- Regards, Ajay

8 years, 9 months

Re: [Python-Dev] [Python-checkins] cpython: Use OESeeror instead of os.error (#16720)

by Jeremy Kloth

On Mon, Dec 24, 2012 at 11:00 AM, andrew.svetlov <python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/6cfe2982de42 > changeset: 81017:6cfe2982de42 > parent: 81011:a7c9869a5114 > user: Andrew Svetlov <andrew.svetlov(a)gmail.com> > date: Mon Dec 24 19:58:48 2012 +0200 > summary: > Use OESeeror instead of os.error (#16720) > > diff --git a/Lib/os.py b/Lib/os.py > --- a/Lib/os.py > +++ b/Lib/os.py > @@ -275,7 +275,7 @@ > while head and tail: > try: > rmdir(head) > - except error: > + except OSrror: > break > head, tail = path.split(head) > Shouldn't that be OSError?

8 years, 9 months

Re: [Python-Dev] [Python-checkins] cpython: Fix #14470. Remove w9xpopen per PEP 11.

by Andrew Svetlov

You missed artifacts in ./PC/VC6 ./PC/VS7.1 ./PC/VS8.0 ./PC/VS9.0 On Mon, Dec 24, 2012 at 12:55 AM, brian.curtin <python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/c903e4f1121d > changeset: 81005:c903e4f1121d > parent: 81003:e3d0417d8266 > user: Brian Curtin <brian(a)python.org> > date: Sun Dec 23 16:53:21 2012 -0600 > summary: > Fix #14470. Remove w9xpopen per PEP 11. > > As stated in PEP 11, 3.4 removes code on Windows platforms where > COMSPEC points to command.com. The w9xpopen project in Visual Studio > was added to support that case, and there was a special case in subprocess > to cover that situation. This change removes the w9xpopen project from > the Visual Studio solution and removes any references to the w9xpopen > executable. > > files: > Lib/subprocess.py | 32 -- > PC/w9xpopen.c | 112 ------- > PCbuild/pcbuild.sln | 2 - > PCbuild/python.vcxproj | 6 +- > PCbuild/w9xpopen.vcxproj | 287 ------------------- > PCbuild/w9xpopen.vcxproj.filters | 13 - > Tools/msi/msi.py | 2 - > 7 files changed, 1 insertions(+), 453 deletions(-) > > > diff --git a/Lib/subprocess.py b/Lib/subprocess.py > --- a/Lib/subprocess.py > +++ b/Lib/subprocess.py > @@ -1029,23 +1029,6 @@ > return Handle(h) > > > - def _find_w9xpopen(self): > - """Find and return absolut path to w9xpopen.exe""" > - w9xpopen = os.path.join( > - os.path.dirname(_winapi.GetModuleFileName(0)), > - "w9xpopen.exe") > - if not os.path.exists(w9xpopen): > - # Eeek - file-not-found - possibly an embedding > - # situation - see if we can locate it in sys.exec_prefix > - w9xpopen = os.path.join(os.path.dirname(sys.base_exec_prefix), > - "w9xpopen.exe") > - if not os.path.exists(w9xpopen): > - raise SubprocessError( > - "Cannot locate w9xpopen.exe, which is needed for " > - "Popen to work with your shell or platform.") > - return w9xpopen > - > - > def _execute_child(self, args, executable, preexec_fn, close_fds, > pass_fds, cwd, env, > startupinfo, creationflags, shell, > @@ -1074,21 +1057,6 @@ > startupinfo.wShowWindow = _winapi.SW_HIDE > comspec = os.environ.get("COMSPEC", "cmd.exe") > args = '{} /c "{}"'.format (comspec, args) > - if (_winapi.GetVersion() >= 0x80000000 or > - os.path.basename(comspec).lower() == "command.com"): > - # Win9x, or using command.com on NT. We need to > - # use the w9xpopen intermediate program. For more > - # information, see KB Q150956 > - # (http://web.archive.org/web/20011105084002/http://support.microsoft.com/supp…) > - w9xpopen = self._find_w9xpopen() > - args = '"%s" %s' % (w9xpopen, args) > - # Not passing CREATE_NEW_CONSOLE has been known to > - # cause random failures on win9x. Specifically a > - # dialog: "Your program accessed mem currently in > - # use at xxx" and a hopeful warning about the > - # stability of your system. Cost is Ctrl+C won't > - # kill children. > - creationflags |= _winapi.CREATE_NEW_CONSOLE > > # Start the process > try: > diff --git a/PC/w9xpopen.c b/PC/w9xpopen.c > deleted file mode 100644 > --- a/PC/w9xpopen.c > +++ /dev/null > @@ -1,112 +0,0 @@ > -/* > - * w9xpopen.c > - * > - * Serves as an intermediate stub Win32 console application to > - * avoid a hanging pipe when redirecting 16-bit console based > - * programs (including MS-DOS console based programs and batch > - * files) on Window 95 and Windows 98. > - * > - * This program is to be launched with redirected standard > - * handles. It will launch the command line specified 16-bit > - * console based application in the same console, forwarding > - * its own redirected standard handles to the 16-bit child. > - > - * AKA solution to the problem described in KB: Q150956. > - */ > - > -#define WIN32_LEAN_AND_MEAN > -#include <windows.h> > -#include <stdio.h> > -#include <stdlib.h> /* for malloc and its friends */ > - > -const char *usage = > -"This program is used by Python's os.popen function\n" > -"to work around a limitation in Windows 95/98. It is\n" > -"not designed to be used as a stand-alone program."; > - > -int main(int argc, char *argv[]) > -{ > - BOOL bRet; > - STARTUPINFO si; > - PROCESS_INFORMATION pi; > - DWORD exit_code=0; > - size_t cmdlen = 0; > - int i; > - char *cmdline, *cmdlinefill; > - > - if (argc < 2) { > - if (GetFileType(GetStdHandle(STD_INPUT_HANDLE))==FILE_TYPE_CHAR) > - /* Attached to a console, and therefore not executed by Python > - Display a message box for the inquisitive user > - */ > - MessageBox(NULL, usage, argv[0], MB_OK); > - else { > - /* Eeek - executed by Python, but args are screwed! > - Write an error message to stdout so there is at > - least some clue for the end user when it appears > - in their output. > - A message box would be hidden and blocks the app. > - */ > - fprintf(stdout, "Internal popen error - no args specified\n%s\n", usage); > - } > - return 1; > - } > - /* Build up the command-line from the args. > - Args with a space are quoted, existing quotes are escaped. > - To keep things simple calculating the buffer size, we assume > - every character is a quote - ie, we allocate double what we need > - in the worst case. As this is only double the command line passed > - to us, there is a good chance this is reasonably small, so the total > - allocation will almost always be < 512 bytes. > - */ > - for (i=1;i<argc;i++) > - cmdlen += strlen(argv[i])*2 + 3; /* one space, maybe 2 quotes */ > - cmdline = cmdlinefill = (char *)malloc(cmdlen+1); > - if (cmdline == NULL) > - return -1; > - for (i=1;i<argc;i++) { > - const char *arglook; > - int bQuote = strchr(argv[i], ' ') != NULL; > - if (bQuote) > - *cmdlinefill++ = '"'; > - /* escape quotes */ > - for (arglook=argv[i];*arglook;arglook++) { > - if (*arglook=='"') > - *cmdlinefill++ = '\\'; > - *cmdlinefill++ = *arglook; > - } > - if (bQuote) > - *cmdlinefill++ = '"'; > - *cmdlinefill++ = ' '; > - } > - *cmdlinefill = '\0'; > - > - /* Make child process use this app's standard files. */ > - ZeroMemory(&si, sizeof si); > - si.cb = sizeof si; > - si.dwFlags = STARTF_USESTDHANDLES; > - si.hStdInput = GetStdHandle(STD_INPUT_HANDLE); > - si.hStdOutput = GetStdHandle(STD_OUTPUT_HANDLE); > - si.hStdError = GetStdHandle(STD_ERROR_HANDLE); > - > - bRet = CreateProcess( > - NULL, cmdline, > - NULL, NULL, > - TRUE, 0, > - NULL, NULL, > - &si, &pi > - ); > - > - free(cmdline); > - > - if (bRet) { > - if (WaitForSingleObject(pi.hProcess, INFINITE) != WAIT_FAILED) { > - GetExitCodeProcess(pi.hProcess, &exit_code); > - } > - CloseHandle(pi.hProcess); > - CloseHandle(pi.hThread); > - return exit_code; > - } > - > - return 1; > -} > diff --git a/PCbuild/pcbuild.sln b/PCbuild/pcbuild.sln > --- a/PCbuild/pcbuild.sln > +++ b/PCbuild/pcbuild.sln > @@ -14,8 +14,6 @@ > EndProject > Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "pythonw", "pythonw.vcxproj", "{F4229CC3-873C-49AE-9729-DD308ED4CD4A}" > EndProject > -Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "w9xpopen", "w9xpopen.vcxproj", "{E9E0A1F6-0009-4E8C-B8F8-1B8F5D49A058}" > -EndProject > Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "make_buildinfo", "make_buildinfo.vcxproj", "{C73F0EC1-358B-4177-940F-0846AC8B04CD}" > EndProject > Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "winsound", "winsound.vcxproj", "{28B5D777-DDF2-4B6B-B34F-31D938813856}" > diff --git a/PCbuild/python.vcxproj b/PCbuild/python.vcxproj > --- a/PCbuild/python.vcxproj > +++ b/PCbuild/python.vcxproj > @@ -357,12 +357,8 @@ > <Project>{cf7ac3d1-e2df-41d2-bea6-1e2556cdea26}</Project> > <ReferenceOutputAssembly>false</ReferenceOutputAssembly> > </ProjectReference> > - <ProjectReference Include="w9xpopen.vcxproj"> > - <Project>{e9e0a1f6-0009-4e8c-b8f8-1b8f5d49a058}</Project> > - <ReferenceOutputAssembly>false</ReferenceOutputAssembly> > - </ProjectReference> > </ItemGroup> > <Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" /> > <ImportGroup Label="ExtensionTargets"> > </ImportGroup> > -</Project> > \ No newline at end of file > +</Project> > diff --git a/PCbuild/w9xpopen.vcxproj b/PCbuild/w9xpopen.vcxproj > deleted file mode 100644 > --- a/PCbuild/w9xpopen.vcxproj > +++ /dev/null > @@ -1,287 +0,0 @@ > -<?xml version="1.0" encoding="utf-8"?> > -<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> > - <ItemGroup Label="ProjectConfigurations"> > - <ProjectConfiguration Include="Debug|Win32"> > - <Configuration>Debug</Configuration> > - <Platform>Win32</Platform> > - </ProjectConfiguration> > - <ProjectConfiguration Include="Debug|x64"> > - <Configuration>Debug</Configuration> > - <Platform>x64</Platform> > - </ProjectConfiguration> > - <ProjectConfiguration Include="PGInstrument|Win32"> > - <Configuration>PGInstrument</Configuration> > - <Platform>Win32</Platform> > - </ProjectConfiguration> > - <ProjectConfiguration Include="PGInstrument|x64"> > - <Configuration>PGInstrument</Configuration> > - <Platform>x64</Platform> > - </ProjectConfiguration> > - <ProjectConfiguration Include="PGUpdate|Win32"> > - <Configuration>PGUpdate</Configuration> > - <Platform>Win32</Platform> > - </ProjectConfiguration> > - <ProjectConfiguration Include="PGUpdate|x64"> > - <Configuration>PGUpdate</Configuration> > - <Platform>x64</Platform> > - </ProjectConfiguration> > - <ProjectConfiguration Include="Release|Win32"> > - <Configuration>Release</Configuration> > - <Platform>Win32</Platform> > - </ProjectConfiguration> > - <ProjectConfiguration Include="Release|x64"> > - <Configuration>Release</Configuration> > - <Platform>x64</Platform> > - </ProjectConfiguration> > - </ItemGroup> > - <PropertyGroup Label="Globals"> > - <ProjectGuid>{E9E0A1F6-0009-4E8C-B8F8-1B8F5D49A058}</ProjectGuid> > - <RootNamespace>w9xpopen</RootNamespace> > - </PropertyGroup> > - <Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" /> > - <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='PGUpdate|Win32'" Label="Configuration"> > - <ConfigurationType>Application</ConfigurationType> > - <UseOfMfc>false</UseOfMfc> > - <CharacterSet>MultiByte</CharacterSet> > - </PropertyGroup> > - <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='PGInstrument|Win32'" Label="Configuration"> > - <ConfigurationType>Application</ConfigurationType> > - <UseOfMfc>false</UseOfMfc> > - <CharacterSet>MultiByte</CharacterSet> > - </PropertyGroup> > - <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'" Label="Configuration"> > - <ConfigurationType>Application</ConfigurationType> > - <UseOfMfc>false</UseOfMfc> > - <CharacterSet>MultiByte</CharacterSet> > - </PropertyGroup> > - <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'" Label="Configuration"> > - <ConfigurationType>Application</ConfigurationType> > - <UseOfMfc>false</UseOfMfc> > - <CharacterSet>NotSet</CharacterSet> > - </PropertyGroup> > - <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='PGUpdate|x64'" Label="Configuration"> > - <ConfigurationType>Application</ConfigurationType> > - <UseOfMfc>false</UseOfMfc> > - <CharacterSet>MultiByte</CharacterSet> > - </PropertyGroup> > - <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='PGInstrument|x64'" Label="Configuration"> > - <ConfigurationType>Application</ConfigurationType> > - <UseOfMfc>false</UseOfMfc> > - <CharacterSet>MultiByte</CharacterSet> > - </PropertyGroup> > - <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'" Label="Configuration"> > - <ConfigurationType>Application</ConfigurationType> > - <UseOfMfc>false</UseOfMfc> > - <CharacterSet>MultiByte</CharacterSet> > - </PropertyGroup> > - <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'" Label="Configuration"> > - <ConfigurationType>Application</ConfigurationType> > - <UseOfMfc>false</UseOfMfc> > - <CharacterSet>MultiByte</CharacterSet> > - </PropertyGroup> > - <Import Project="$(VCTargetsPath)\Microsoft.Cpp.props" /> > - <ImportGroup Label="ExtensionSettings"> > - </ImportGroup> > - <ImportGroup Condition="'$(Configuration)|$(Platform)'=='PGUpdate|Win32'" Label="PropertySheets"> > - <Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" /> > - <Import Project="pyproject.props" /> > - <Import Project="release.props" /> > - <Import Project="pgupdate.props" /> > - </ImportGroup> > - <ImportGroup Condition="'$(Configuration)|$(Platform)'=='PGInstrument|Win32'" Label="PropertySheets"> > - <Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" /> > - <Import Project="pyproject.props" /> > - <Import Project="release.props" /> > - <Import Project="pginstrument.props" /> > - </ImportGroup> > - <ImportGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'" Label="PropertySheets"> > - <Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" /> > - <Import Project="pyproject.props" /> > - <Import Project="release.props" /> > - </ImportGroup> > - <ImportGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'" Label="PropertySheets"> > - <Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" /> > - <Import Project="pyproject.props" /> > - <Import Project="debug.props" /> > - </ImportGroup> > - <ImportGroup Condition="'$(Configuration)|$(Platform)'=='PGUpdate|x64'" Label="PropertySheets"> > - <Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" /> > - <Import Project="pyproject.props" /> > - <Import Project="x64.props" /> > - <Import Project="release.props" /> > - <Import Project="pgupdate.props" /> > - </ImportGroup> > - <ImportGroup Condition="'$(Configuration)|$(Platform)'=='PGInstrument|x64'" Label="PropertySheets"> > - <Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" /> > - <Import Project="pyproject.props" /> > - <Import Project="x64.props" /> > - <Import Project="release.props" /> > - <Import Project="pginstrument.props" /> > - </ImportGroup> > - <ImportGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'" Label="PropertySheets"> > - <Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" /> > - <Import Project="pyproject.props" /> > - <Import Project="x64.props" /> > - <Import Project="release.props" /> > - </ImportGroup> > - <ImportGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'" Label="PropertySheets"> > - <Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" /> > - <Import Project="pyproject.props" /> > - <Import Project="x64.props" /> > - <Import Project="debug.props" /> > - </ImportGroup> > - <PropertyGroup Label="UserMacros" /> > - <PropertyGroup> > - <_ProjectFileVersion>10.0.40219.1</_ProjectFileVersion> > - <CodeAnalysisRuleSet Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">AllRules.ruleset</CodeAnalysisRuleSet> > - <CodeAnalysisRules Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'" /> > - <CodeAnalysisRuleAssemblies Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'" /> > - <CodeAnalysisRuleSet Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">AllRules.ruleset</CodeAnalysisRuleSet> > - <CodeAnalysisRules Condition="'$(Configuration)|$(Platform)'=='Debug|x64'" /> > - <CodeAnalysisRuleAssemblies Condition="'$(Configuration)|$(Platform)'=='Debug|x64'" /> > - <CodeAnalysisRuleSet Condition="'$(Configuration)|$(Platform)'=='PGInstrument|Win32'">AllRules.ruleset</CodeAnalysisRuleSet> > - <CodeAnalysisRules Condition="'$(Configuration)|$(Platform)'=='PGInstrument|Win32'" /> > - <CodeAnalysisRuleAssemblies Condition="'$(Configuration)|$(Platform)'=='PGInstrument|Win32'" /> > - <CodeAnalysisRuleSet Condition="'$(Configuration)|$(Platform)'=='PGInstrument|x64'">AllRules.ruleset</CodeAnalysisRuleSet> > - <CodeAnalysisRules Condition="'$(Configuration)|$(Platform)'=='PGInstrument|x64'" /> > - <CodeAnalysisRuleAssemblies Condition="'$(Configuration)|$(Platform)'=='PGInstrument|x64'" /> > - <CodeAnalysisRuleSet Condition="'$(Configuration)|$(Platform)'=='PGUpdate|Win32'">AllRules.ruleset</CodeAnalysisRuleSet> > - <CodeAnalysisRules Condition="'$(Configuration)|$(Platform)'=='PGUpdate|Win32'" /> > - <CodeAnalysisRuleAssemblies Condition="'$(Configuration)|$(Platform)'=='PGUpdate|Win32'" /> > - <CodeAnalysisRuleSet Condition="'$(Configuration)|$(Platform)'=='PGUpdate|x64'">AllRules.ruleset</CodeAnalysisRuleSet> > - <CodeAnalysisRules Condition="'$(Configuration)|$(Platform)'=='PGUpdate|x64'" /> > - <CodeAnalysisRuleAssemblies Condition="'$(Configuration)|$(Platform)'=='PGUpdate|x64'" /> > - <CodeAnalysisRuleSet Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">AllRules.ruleset</CodeAnalysisRuleSet> > - <CodeAnalysisRules Condition="'$(Configuration)|$(Platform)'=='Release|Win32'" /> > - <CodeAnalysisRuleAssemblies Condition="'$(Configuration)|$(Platform)'=='Release|Win32'" /> > - <CodeAnalysisRuleSet Condition="'$(Configuration)|$(Platform)'=='Release|x64'">AllRules.ruleset</CodeAnalysisRuleSet> > - <CodeAnalysisRules Condition="'$(Configuration)|$(Platform)'=='Release|x64'" /> > - <CodeAnalysisRuleAssemblies Condition="'$(Configuration)|$(Platform)'=='Release|x64'" /> > - </PropertyGroup> > - <ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'"> > - <ClCompile> > - <Optimization>Disabled</Optimization> > - <BasicRuntimeChecks>EnableFastChecks</BasicRuntimeChecks> > - <RuntimeLibrary>MultiThreadedDebug</RuntimeLibrary> > - </ClCompile> > - <Link> > - <SubSystem>Console</SubSystem> > - </Link> > - </ItemDefinitionGroup> > - <ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'"> > - <Midl> > - <TargetEnvironment>X64</TargetEnvironment> > - </Midl> > - <ClCompile> > - <Optimization>Disabled</Optimization> > - <BasicRuntimeChecks>EnableFastChecks</BasicRuntimeChecks> > - <RuntimeLibrary>MultiThreadedDebug</RuntimeLibrary> > - </ClCompile> > - <Link> > - <SubSystem>Console</SubSystem> > - </Link> > - </ItemDefinitionGroup> > - <ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'"> > - <ClCompile> > - <Optimization>MaxSpeed</Optimization> > - <InlineFunctionExpansion>OnlyExplicitInline</InlineFunctionExpansion> > - <StringPooling>true</StringPooling> > - <RuntimeLibrary>MultiThreaded</RuntimeLibrary> > - <FunctionLevelLinking>true</FunctionLevelLinking> > - </ClCompile> > - <Link> > - <GenerateDebugInformation>false</GenerateDebugInformation> > - <SubSystem>Console</SubSystem> > - </Link> > - </ItemDefinitionGroup> > - <ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'"> > - <Midl> > - <TargetEnvironment>X64</TargetEnvironment> > - </Midl> > - <ClCompile> > - <Optimization>MaxSpeed</Optimization> > - <InlineFunctionExpansion>OnlyExplicitInline</InlineFunctionExpansion> > - <StringPooling>true</StringPooling> > - <RuntimeLibrary>MultiThreaded</RuntimeLibrary> > - <FunctionLevelLinking>true</FunctionLevelLinking> > - </ClCompile> > - <Link> > - <GenerateDebugInformation>false</GenerateDebugInformation> > - <SubSystem>Console</SubSystem> > - </Link> > - </ItemDefinitionGroup> > - <ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='PGInstrument|Win32'"> > - <ClCompile> > - <Optimization>MaxSpeed</Optimization> > - <InlineFunctionExpansion>OnlyExplicitInline</InlineFunctionExpansion> > - <StringPooling>true</StringPooling> > - <RuntimeLibrary>MultiThreaded</RuntimeLibrary> > - <FunctionLevelLinking>true</FunctionLevelLinking> > - </ClCompile> > - <Link> > - <GenerateDebugInformation>false</GenerateDebugInformation> > - <SubSystem>Console</SubSystem> > - <ImportLibrary> > - </ImportLibrary> > - </Link> > - </ItemDefinitionGroup> > - <ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='PGInstrument|x64'"> > - <Midl> > - <TargetEnvironment>X64</TargetEnvironment> > - </Midl> > - <ClCompile> > - <Optimization>MaxSpeed</Optimization> > - <InlineFunctionExpansion>OnlyExplicitInline</InlineFunctionExpansion> > - <StringPooling>true</StringPooling> > - <RuntimeLibrary>MultiThreaded</RuntimeLibrary> > - <FunctionLevelLinking>true</FunctionLevelLinking> > - </ClCompile> > - <Link> > - <GenerateDebugInformation>false</GenerateDebugInformation> > - <SubSystem>Console</SubSystem> > - <ImportLibrary> > - </ImportLibrary> > - <TargetMachine>MachineX64</TargetMachine> > - </Link> > - </ItemDefinitionGroup> > - <ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='PGUpdate|Win32'"> > - <ClCompile> > - <Optimization>MaxSpeed</Optimization> > - <InlineFunctionExpansion>OnlyExplicitInline</InlineFunctionExpansion> > - <StringPooling>true</StringPooling> > - <RuntimeLibrary>MultiThreaded</RuntimeLibrary> > - <FunctionLevelLinking>true</FunctionLevelLinking> > - </ClCompile> > - <Link> > - <GenerateDebugInformation>false</GenerateDebugInformation> > - <SubSystem>Console</SubSystem> > - <ImportLibrary> > - </ImportLibrary> > - </Link> > - </ItemDefinitionGroup> > - <ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='PGUpdate|x64'"> > - <Midl> > - <TargetEnvironment>X64</TargetEnvironment> > - </Midl> > - <ClCompile> > - <Optimization>MaxSpeed</Optimization> > - <InlineFunctionExpansion>OnlyExplicitInline</InlineFunctionExpansion> > - <StringPooling>true</StringPooling> > - <RuntimeLibrary>MultiThreaded</RuntimeLibrary> > - <FunctionLevelLinking>true</FunctionLevelLinking> > - </ClCompile> > - <Link> > - <GenerateDebugInformation>false</GenerateDebugInformation> > - <SubSystem>Console</SubSystem> > - <ImportLibrary> > - </ImportLibrary> > - <TargetMachine>MachineX64</TargetMachine> > - </Link> > - </ItemDefinitionGroup> > - <ItemGroup> > - <ClCompile Include="..\PC\w9xpopen.c" /> > - </ItemGroup> > - <Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" /> > - <ImportGroup Label="ExtensionTargets"> > - </ImportGroup> > -</Project> > \ No newline at end of file > diff --git a/PCbuild/w9xpopen.vcxproj.filters b/PCbuild/w9xpopen.vcxproj.filters > deleted file mode 100644 > --- a/PCbuild/w9xpopen.vcxproj.filters > +++ /dev/null > @@ -1,13 +0,0 @@ > -<?xml version="1.0" encoding="utf-8"?> > -<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> > - <ItemGroup> > - <Filter Include="Source Files"> > - <UniqueIdentifier>{abc2dffd-3f2a-47bd-b89b-0314c99ef21e}</UniqueIdentifier> > - </Filter> > - </ItemGroup> > - <ItemGroup> > - <ClCompile Include="..\PC\w9xpopen.c"> > - <Filter>Source Files</Filter> > - </ClCompile> > - </ItemGroup> > -</Project> > \ No newline at end of file > diff --git a/Tools/msi/msi.py b/Tools/msi/msi.py > --- a/Tools/msi/msi.py > +++ b/Tools/msi/msi.py > @@ -956,8 +956,6 @@ > # Add all executables, icons, text files into the TARGETDIR component > root = PyDirectory(db, cab, None, srcdir, "TARGETDIR", "SourceDir") > default_feature.set_current() > - if not msilib.Win64: > - root.add_file("%s/w9xpopen.exe" % PCBUILD) > root.add_file("README.txt", src="README") > root.add_file("NEWS.txt", src="Misc/NEWS") > generate_license() > > -- > Repository URL: http://hg.python.org/cpython > > _______________________________________________ > Python-checkins mailing list > Python-checkins(a)python.org > http://mail.python.org/mailman/listinfo/python-checkins > -- Thanks, Andrew Svetlov

8 years, 9 months

Is it possible to switch into the context of a child-process, spawned by "subprocess" module?

by Ajay Garg

Hi all. This is more of knowing whether something is possible in the core python architecture; hence the question to this mailing-list :) I have a situation where I am spawning a child process via "subprocess" module. This child process is equivalent to the process that would have been created, if I had run a vanilla python-script in another shell. In this (new) (child) process, new objects are instantiated, and methods get called on those objects as usual. Now, what I need is to somehow switch into this (new) (child) process from the current (parent) process, and be able to call methods-on-the-objects-of-the-child-process. Also, please note that since the child process contains GUI, I intend to have the results of calling the methods-on-the-objects-of-the-child-process being effective on the child-process GUI. Is it possible? Or am I trying to achieve something impossible as per python-core-architecture? I will be thankful for any pointers regarding this. Regards, Ajay

8 years, 9 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev December 2012