[ python-Feature Requests-1191964 ] asynchronous Subprocess
Feature Requests item #1191964, was opened at 2005-04-28 20:40 Message generated for change (Comment added) made by o You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1191964&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Peter Åstrand (astrand) Summary: asynchronous Subprocess Initial Comment: It would be terribly nice if the Popen class in the subprocess module would allow a programmer to easily say "send some data right now (if I have some to send) and receive whatever information is available right now". Essentially the equivalent of asyncore.loop(count=1), only that it returns the data received, instead of placing it in a buffer. Why would this functionality be useful? Currently, when using the subprocess module with pipes, the interaction with a pipe is limited to "send data if desired, close the subprocess' stdin, read all output from the subprocess' stdout, ...". Certainly one can pull the pipes out of the Popen instance, and perform the necessary functions on posix systems (with select or poll), but the additional magic on WIndows is a little less obvious (but still possible). There is a post by Paul Du Bois with an example using win32pipe.PeekNamedPipe: http://groups-beta.google.com/group/comp.lang.python/msg/115e9332cc1ca09d?hl=en And a message from Neil Hodgeson stating that PeekNamedPipe works on anonymous pipes: http://mail.python.org/pipermail/python-dev/2000-May/004200.html With this modification, creating Expect-like modules for any platform, as well as embedded shells inside any GUI with a text input widget, becomes easy. Heck, even Idle could use it rather than a socket for its interactive interpreter. -- Comment By: Benjamin (o) Date: 2006-12-31 15:19 Message: Logged In: YES user_id=1680023 Originator: NO If there were a blocking "read x bytes" type call, could you not do some non-blocking stuff afterwards? If you use the "read" method, with a byte limit, directly on the stdout member of Popen, that could return with your bytes, and then you do some non-blocking stuff afterwards. That's the external view of course, I suspect that you're saying there's some internal lower-level reason this is currently not possible. Thanks for your interim class BTW, it is proving to be very useful. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-12-30 23:21 Message: Logged In: YES user_id=341410 Originator: YES The way subprocess is currently written, if you were to use a blocking semantic, you would no longer be able to use an asynchronous semantic afterwards (it will read the result until there is nothing more to read). Note that this is the case whether it is mode or method based. -- Comment By: Benjamin (o) Date: 2006-12-30 21:45 Message: Logged In: YES user_id=1680023 Originator: NO I would also like to see this feature. I'm using Josiah Carlson's recipe for the time being. I'm agnostic about whether the asynchronicity is a "mode" or just a case of using different functions. However, if the former is chosen, then one should be able to switch modes at will, because sometimes I want blocking and sometimes I don't. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-09-21 20:55 Message: Logged In: YES user_id=341410 I've implemented this as a subclass of subprocess.Popen in the Python cookbook, available here: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/440554 -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-09-21 20:51 Message: Logged In: YES user_id=341410 I've implemented this as a subclass of subprocess.Popen in the Python cookbook, available here: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/440554 Essentially this is a request for inclusion in the standard library for Python 2.5 . -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-06-26 19:47 Message: Logged In: YES user_id=341410 How about if subprocesses have 3 new methods, send(input), recv(maxlen), and recv_stderr(maxlen). send(input) would perform like socket.send(), sending as much as it currently can, returning the number of bytes sent. recv(maxlen) and recv_stderr(maxlen) would recieve up to the provided number of bytes from the stdout or stderr pipes respectively. I currently have an implementation of the abov
[ python-Bugs-1625381 ] re module documentation on search/match is unclear
Bugs item #1625381, was opened at 2006-12-31 16:42
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1625381&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Richard Boulton (richardb)
Assigned to: Nobody/Anonymous (nobody)
Summary: re module documentation on search/match is unclear
Initial Comment:
Section 4.2.2 ("Matching vs Searching") of the Python Library Reference covers
the match and search methods of regular expression objects. However, it
doesn't begin by describing the difference between these methods. Each time I
try to remember which way round match and search are, it takes several minutes
of checking the documentation to work out which is which. I suggest that the
first paragraph of the section is replaced with the following text (in two
paragraphs), to make the distinction between the methods clearer:
"Python offers two different primitive operations based on regular expressions:
match and search. match() checks for a match at the beginning of the search
string, whereas search() checks for a match anywhere in the string.
If you want something equivalent to Perl's semantics, the search operation is
what you're looking for. See the search() function and corresponding method of
compiled regular expression objects."
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1625381&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1191964 ] asynchronous Subprocess
Feature Requests item #1191964, was opened at 2005-04-28 13:40 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1191964&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Peter Åstrand (astrand) Summary: asynchronous Subprocess Initial Comment: It would be terribly nice if the Popen class in the subprocess module would allow a programmer to easily say "send some data right now (if I have some to send) and receive whatever information is available right now". Essentially the equivalent of asyncore.loop(count=1), only that it returns the data received, instead of placing it in a buffer. Why would this functionality be useful? Currently, when using the subprocess module with pipes, the interaction with a pipe is limited to "send data if desired, close the subprocess' stdin, read all output from the subprocess' stdout, ...". Certainly one can pull the pipes out of the Popen instance, and perform the necessary functions on posix systems (with select or poll), but the additional magic on WIndows is a little less obvious (but still possible). There is a post by Paul Du Bois with an example using win32pipe.PeekNamedPipe: http://groups-beta.google.com/group/comp.lang.python/msg/115e9332cc1ca09d?hl=en And a message from Neil Hodgeson stating that PeekNamedPipe works on anonymous pipes: http://mail.python.org/pipermail/python-dev/2000-May/004200.html With this modification, creating Expect-like modules for any platform, as well as embedded shells inside any GUI with a text input widget, becomes easy. Heck, even Idle could use it rather than a socket for its interactive interpreter. -- >Comment By: Josiah Carlson (josiahcarlson) Date: 2006-12-31 10:04 Message: Logged In: YES user_id=341410 Originator: YES Unless you use PeekNamedPipe on Windows, there is no guarantee that the pipe will return *any* data until the process ends, even if you say pipe.read(1) and there is 1k of data already sent. Note that the two async reading methods that I provide (recv() and recv_err()) take a 'maximum bytes' argument. Just like I have written a 'send_all()' utility function, I (or you) can easily write a 'recv_exact()' utility function that receives an exact number of bytes before returning. That functionality would be more or less required for one of the expected use-cases I specify in the recipe, "writing a multi-platform 'expect' module". Stick with async calls (with the utility recv_exact()) until you need to use the .communicate() method. -- Comment By: Benjamin (o) Date: 2006-12-31 07:19 Message: Logged In: YES user_id=1680023 Originator: NO If there were a blocking "read x bytes" type call, could you not do some non-blocking stuff afterwards? If you use the "read" method, with a byte limit, directly on the stdout member of Popen, that could return with your bytes, and then you do some non-blocking stuff afterwards. That's the external view of course, I suspect that you're saying there's some internal lower-level reason this is currently not possible. Thanks for your interim class BTW, it is proving to be very useful. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-12-30 15:21 Message: Logged In: YES user_id=341410 Originator: YES The way subprocess is currently written, if you were to use a blocking semantic, you would no longer be able to use an asynchronous semantic afterwards (it will read the result until there is nothing more to read). Note that this is the case whether it is mode or method based. -- Comment By: Benjamin (o) Date: 2006-12-30 13:45 Message: Logged In: YES user_id=1680023 Originator: NO I would also like to see this feature. I'm using Josiah Carlson's recipe for the time being. I'm agnostic about whether the asynchronicity is a "mode" or just a case of using different functions. However, if the former is chosen, then one should be able to switch modes at will, because sometimes I want blocking and sometimes I don't. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-09-21 13:55 Message: Logged In: YES user_id=341410 I've implemented this as a subclass of subprocess.Popen in the Python cookbook, available here: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/440554
[ python-Bugs-1625509 ] 'imp' documentation does not mention that lock is re-entrant
Bugs item #1625509, was opened at 2006-12-31 18:22
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1625509&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dustin J. Mitchell (djmitche)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'imp' documentation does not mention that lock is re-entrant
Initial Comment:
My reading of import.c shows that imp.{acquire,release}_lock operate in the
fashion of a threading.RLock, rather than a threading.Lock. Of course, this
makes sense for the use to which it's put, but it would be great to have that
mentioned explicitly in the documentation. Suggestion (stolen from threading
documentation):
acquire_lock()
Acquires the interpreter's import lock for the current thread. This lock should
be used by import hooks to ensure thread-safety when importing modules.
Once a thread has acquired the import lock, the same thread may acquire it
again without blocking; the thread must release it once for each time it has
acquired it.
On platforms without threads, this function does nothing. New in version 2.3.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1625509&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1625576 ] add ability to specify name to os.fdopen
Bugs item #1625576, was opened at 2007-01-01 07:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1625576&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark Diekhans (diekhans) Assigned to: Nobody/Anonymous (nobody) Summary: add ability to specify name to os.fdopen Initial Comment: Please add an optional argument to os.fdopen() to specify the name field in the resulting file object. This would allow for a more useful name than: '...> -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1625576&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
