On Feb 13, 7:08 am, Anh Hai Trinh <anh.hai.tr...@gmail.com> wrote:
> > Objection! Does the defense REALLY expect this court to believe that
> > he can testify as to how MOST members of the Python community would or
> > would not favor bash over Python? And IF they do in fact prefer bash,
> > is this display of haughty arrogance nothing more than a hastily
> > stuffed straw-man presented to protect his own ego?
>
> Double objection! Relevance. The point is that the OP created another
> language that is neither Python nor Bash.
>
Triple objection! I think Rick's point was only that he didn't think
you were expressing the views of "most" people, which sort of came
across in your post.
To say I've created "another language" is misleading - it's just a
subset of Bash syntax, so you can do things like "echo foo; echo bar",
use "&&", "||" etc. (I used the Bash man page as my guide when
designing the parser.)
As an experiment on Windows, in a virtualenv, with GnuWin32 installed
on the path:
(venv) C:\temp>python
ActivePython 2.6.6.17 (ActiveState Software Inc.) based on
Python 2.6.6 (r266:84292, Nov 24 2010, 09:16:51) [MSC v.1500 32 bit
(Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from extproc import sh
>>> sh('echo foo; echo bar')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\temp\venv\lib\site-packages\extproc.py", line 412, in sh
f = Sh(cmd, fd=fd, e=e, cd=cd).capture(1).stdout
File "C:\temp\venv\lib\site-packages\extproc.py", line 202, in
capture
p = subprocess.Popen(self.cmd, cwd=self.cd, env=self.env,
stdin=self.fd[0],
stdout=self.fd[1], stderr=self.fd[2])
File "C:\Python26\Lib\subprocess.py", line 623, in __init__
errread, errwrite)
File "C:\Python26\Lib\subprocess.py", line 833, in _execute_child
startupinfo)
WindowsError: [Error 3] The system cannot find the path specified
>>> from sarge import capture_stdout
>>> capture_stdout('echo foo; echo bar').stdout.text
u'foo\r\nbar\r\n'
>>>
That's all from a single interactive session. So as you can see, my
use cases are a little different to yours, which in turn makes a
different approach reasonable.
> My respectful opinion is that the OP's approach is fundamentally flawed.
> There are many platform-specific issues when forking and threading are fused.
> My benign intent was to warn others about unsolved problems and
> scratching-your-head situations.
>
> Obviously, the OP can always choose to continue his direction at his own
> discretion.
I think you were right to bring up the forking+threading issue, but I
have addressed the points you made in this thread - please feel free
to respond to the points I made about the Linux Programming Blog
article. I've updated the sarge docs to point to that article, and
I've added a section on API stability to highlight the fact that the
library is in alpha status and that API changes may be needed based on
feedback.
I'm not being blasé about the issue - it's just that I don't want to
be too timid, either. Python does not proscribe using subprocess and
threads together, and the issues you mention could easily occur even
without the use of sarge. You might say that sarge makes it more
likely that the issues will surface - but it'll only do that if you
pass "a & b & c & d" to sarge, and not otherwise.
The other use of threads by sarge - to read output streams from child
processes - is no different from the stdlib usage of threads in
subprocess.Popen.communicate().
Possibly Rick was objecting to the tone of your comments, but I
generally disregard any tone that seems confrontational when the
benefit of the doubt can be given - on the Internet, you can never
take for granted, and have to make allowances for, the language style
of your interlocutor ... I think you meant well when you responded,
and I have taken your posts in that spirit.
Regards,
Vinay Sajip
--
http://mail.python.org/mailman/listinfo/python-list
