[Python-Dev] Is it possible to switch into the context of a child-process, spawned by "subprocess" module?
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Running GUI and "GObject.mainloop.run()" together?
Hi all. This is another question that arises as part of my efforts to run a GUI application, as well as a dbus-service within the same process. (The other question being at http://mail.python.org/pipermail/python-dev/2012-December/123287.html) 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. Thus, a) I subclassed the child-process "main" class with "dbus.service.Object"; however, I then got the error "metaclass conflict: the metaclass of a derived class must be a (non-strict)subclass of the metaclasses of all its bases " b) 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). c) I tried option b), but now instantiating "RemoteListener" in a separate thread; however, no improvement :( Is there a way to run GUI and a dbus-service together? Or is a dbus-service pure "backend" process? :P I will be grateful for any pointers; if you need me to test anything else, please let me know, I will be more than willing :) Regards, Ajay ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Fix #14470. Remove w9xpopen per PEP 11.
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
wrote:
> http://hg.python.org/cpython/rev/c903e4f1121d
> changeset: 81005:c903e4f1121d
> parent: 81003:e3d0417d8266
> user:Brian Curtin
> 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() >= 0x8000 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/support/kb/articles/Q150/9/56.asp)
> -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
> -#include
> -#include /* 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,
Re: [Python-Dev] [Python-checkins] cpython (3.3): Issue #16045: add more unit tests for built-in int()
On 23.12.12 22:03, Terry Reedy wrote: I think the above behavior is buggy and should be changed rather than frozen into CPython with a test. According to the docs, PyPy does it right. http://bugs.python.org/issue16761 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is it possible to switch into the context of a child-process, spawned by "subprocess" module?
On 12/24/2012 2:57 AM, Ajay Garg wrote: Hi all. This is more of knowing whether something is possible in the core python architecture; hence the question to this mailing-list :) The pydev list is for discussion of development of future Python, not for how to use current Python. Usage questions should go to python-list or other forums. (I am 99.99% sure the answer to this one is no.) -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3145 (With Contents)
What should I do in case Eric lost interest after his GSoC project for PSF appeared as useless for python-dev community? Should I rewrite the proposal from scratch? On Thu, Dec 20, 2012 at 11:18 PM, Brett Cannon wrote: > You cannot rewrite an existing PEP if you are not one of the original > owners, nor can you add yourself as an author to a PEP without permission > from the original authors. > > And please do not CC the peps mailing list on discussions. It should only > be used to mail in new PEPs or acceptable patches to PEPs. > > > On Wed, Dec 19, 2012 at 5:20 PM, anatoly techtonik wrote: > >> On Sun, Dec 9, 2012 at 7:17 AM, Gregory P. Smith wrote: >> >>> I'm really not sure what this PEP is trying to get at given that it >>> contains no examples and sounds from the descriptions to be adding a >>> complicated api on top of something that already, IMNSHO, has too much it >>> (subprocess.Popen). >>> >>> Regardless, any user can use the stdout/err/in file objects with their >>> own code that handles them asynchronously (yes that can be painful but that >>> is what is required for _any_ socket or pipe I/O you don't want to block >>> on). >>> >> >> And how to use stdout/stderr/in asynchronously in cross-platform manner? >> IIUC the problem is that every read is blocking. >> >> >>> It *sounds* to me like this entire PEP could be written and released as >>> a third party module on PyPI that offers a subprocess.Popen subclass adding >>> some more convenient non-blocking APIs. That's where I'd start if I were >>> interested in this as a future feature. >>> >> >> I've rewritten the PEP based on how do I understand the code. I don't >> know how to update it and how to comply with open documentation license, so >> I just attach it and add PEPs list to CC. Me too has a feeling that the PEP >> should be stripped of additional high level API until low level >> functionality is well understood and accepted. >> >> -- >> anatoly t. >> >> ___ >> Python-Dev mailing list >> [email protected] >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/brett%40python.org >> >> > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is it possible to switch into the context of a child-process, spawned by "subprocess" module?
El dic 24, 2012 4:59 a.m., "Ajay Garg" escribió: > > 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? > Hint: xmlrpclib. And that should be the end of this thread. Regards > > > I will be thankful for any pointers regarding this. > > Regards, > Ajay > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/joaquinsargiotto%40gmail.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is it possible to switch into the context of a child-process, spawned by "subprocess" module?
Terry, Sorry; and thanks for the info. Joaquin, Thanks for the pointer; I will investigate :) On Mon, Dec 24, 2012 at 7:56 PM, Joaquin Sargiotto < [email protected]> wrote: > > El dic 24, 2012 4:59 a.m., "Ajay Garg" escribió: > > > > > 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? > > > > Hint: xmlrpclib. > > And that should be the end of this thread. > > Regards > > > > > > > I will be thankful for any pointers regarding this. > > > > Regards, > > Ajay > > > > ___ > > Python-Dev mailing list > > [email protected] > > http://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/joaquinsargiotto%40gmail.com > > > > -- Regards, Ajay ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Fix #14470. Remove w9xpopen per PEP 11.
On Mon, Dec 24, 2012 at 2:36 AM, Andrew Svetlov wrote: > You missed artifacts in ./PC/VC6 ./PC/VS7.1 ./PC/VS8.0 ./PC/VS9.0 Fixed in http://hg.python.org/cpython/rev/deee9f0a4b98 Also reported http://bugs.python.org/issue16769 about removing some those directories because they are pretty much useless. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Use OESeeror instead of os.error (#16720)
On Mon, Dec 24, 2012 at 11:00 AM, andrew.svetlov wrote: > http://hg.python.org/cpython/rev/6cfe2982de42 > changeset: 81017:6cfe2982de42 > parent: 81011:a7c9869a5114 > user:Andrew Svetlov > 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? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Use OESeeror instead of os.error (#16720)
Sorry, my bad. Fixed in e2e5181b10f8 On Mon, Dec 24, 2012 at 9:16 PM, Jeremy Kloth wrote: > On Mon, Dec 24, 2012 at 11:00 AM, andrew.svetlov > wrote: >> http://hg.python.org/cpython/rev/6cfe2982de42 >> changeset: 81017:6cfe2982de42 >> parent: 81011:a7c9869a5114 >> user:Andrew Svetlov >> 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? -- Thanks, Andrew Svetlov ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Use OESeeror instead of os.error (#16720)
On 24.12.12 21:48, Andrew Svetlov wrote: Sorry, my bad. Fixed in e2e5181b10f8 It's my fault. Sorry. summary: Use OESeeror instead of os.error (#16720) But it's not my. ;) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3156 - Asynchronous IO Support Rebooted
On Dec 21, 2012, at 1:10 PM, Guido van Rossum wrote: > > > The transport is free to buffer the bytes, but it must eventually > > > cause the bytes to be transferred to the entity at the other end, and > > > it must maintain stream behavior. That is, t.write(b'abc'); > > > t.write(b'def') is equivalent to t.write(b'abcdef') > > > > I think this is a bad idea. The kernel's network stack should do the > > buffering (and choose appropriate algorithms for that), not the > > user-level framework. The transport should write the bytes as soon as > > the fd is ready for writing, and it should write the same chunks as > > given by the user, not a concatenation of them. > > I asked Glyph about this. It depends on the OS... Mac syscalls are so slow > that it is better to join in user space. This should really be up to the > transport, although for stream transports the given equivalency should > definitely hold. > It's not so much that "mac syscalls are slow" as that "syscalls are not free, and the cost varies". Older versions of MacOS were particularly bad. Some versions of Linux had bizarre regressions in the performance of send() or recv() or pipe(). The things that pass for syscalls on Windows can be particularly catastrophically slow (although this is practically a consideration for filesystem APIs, not socket APIs, who knows what this the future will hold). There are a number of other reasons why this should be this way as well. User-space has the ability to buffer indefinitely, and the kernel does not. Sometimes, send() returns a truncated value, and you have to deal with this. Since you've allocated the memory for the value you're calling write() with anyway, you might as well stash it away in the framework. The alternative is to let every application implement - and by implement, I mean "screw up" - a low-performance buffering implementation. User-space has more information about the type of information being sent. If the user does write() write() write() within one loop iteration, the framework can hypothetically optimize that into a single syscall using scatter-gather I/O. (Fun fact: we tried this, and it turns out that some implementations of scatter-gather I/O are actually *slower* than naive repeated calls; information like this should, again, be preserved within the framework.) In order to preserve compatibility with other systems (Twisted, Tornado, et. al.), the framework must be within its rights to do the buffering itself, even if it actually does exactly what you're suggesting because that happens to be better for performance in some circumstances. Choosing different buffering strategies for different applications is an important tuning option. Applications which appear to work in some contexts if the boundaries of data passed to send() are exactly the same as the boundaries of the data sent to write() should not be coddled; this just makes them harder to debug later. They should be broken as soon as possible. This is a subtle, pernicious and nearly constant error that people new to networking make and the sooner it surfaces, the better. The segments passed to data_received() should be as different as possible from the segments passed to write(). > > Besides, it would be better if transports weren't automatically > > *streaming* transports. There are connected datagram protocols, such as > > named pipes under Windows (multiprocessing already uses non-blocking > > Windows named pipes). > > I think we need to support datagrams, but the default ought to be stream. > In my humble (but entirely, verifiably correct) opinion, thinking of this as a "default" is propagating a design error in the BSD sockets API. Datagram and stream sockets have radically different semantics. In Twisted, "dataReceived" and "datagramReceived" are different methods for a good reason. Again, it's very very easy to fall into the trap of thinking that a TCP segment is a datagram and writing all your application code as if it were. After all, it probably works over localhost most of the time! This difference in semantics mirrored by a difference in method naming has helped quite a few people grok the distinction between streaming and datagrams over the years; I think it would be a good idea if Tulip followed suit. -glyph ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3156 - Asynchronous IO Support Rebooted
On Dec 21, 2012, at 1:10 PM, Guido van Rossum wrote: > > > TBD: Need an interface to wait for the first of a collection of Futures. > > > > Have you looked at Twisted's DeferredList? > > http://twistedmatrix.com/documents/12.1.0/api/twisted.internet.defer.DeferredList.html > > No, I am trying to stay away from them. > Those who do not understand Deferreds are doomed to re-implement them poorly ;-). (And believe me, I've seen more than a few poor re-implementations at this point...) -g___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3145 (With Contents)
Hey, Anatoly, you are free to modify the PEP and code. I do not have any plans to work on this right now. Eric On Mon, Dec 24, 2012 at 04:42:20PM +0300, anatoly techtonik wrote: > What should I do in case Eric lost interest after his GSoC project for PSF > appeared as useless for python-dev community? Should I rewrite the proposal > from scratch? > > On Thu, Dec 20, 2012 at 11:18 PM, Brett Cannon wrote: > > > You cannot rewrite an existing PEP if you are not one of the original > > owners, nor can you add yourself as an author to a PEP without permission > > from the original authors. > > > > And please do not CC the peps mailing list on discussions. It should only > > be used to mail in new PEPs or acceptable patches to PEPs. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3145 (With Contents)
On Mon, Dec 24, 2012 at 7:42 AM, anatoly techtonik wrote: > What should I do in case Eric lost interest after his GSoC project for PSF > appeared as useless for python-dev community? Should I rewrite the proposal > from scratch? Before you attempt that, start by trying to have a better attitude towards people's contributions around here. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
