improving performance of writing into a pipe

[Michael Torrie]

Or rather: what would you try to catch in this particular case?

As Peter said, nothing for now. But you seem very resistant to telling
us what exception was raised.

Though looking at your code more closely I can see that likely the error
is related to the fact that /tmp/mypipe is not an executable program.
popen (which is deprecated and replaced by the subprocess module) is for
running programs and communicating with them over pipes created by the
popen function. So your code is not likely to ever work as it is
presently given.

Here's the bash equivalent of your code:

$ mkfifo /tmp/path
$ cat </tmp/path &
$ echo hello, world | /tmp/path

Bash will say, "bash: /tmp/path: Permission denied"

The correct bash line is:
$ echo hello, world > /tmp/path

popen() (and subprocess) is the equivalent of the first bash command.
open() is the equivalent of the second line.

Do you understand the difference?

 

[mikprog]

As Peter said, nothing for now. But you seem very resistant to telling

us what exception was raised.

Michael believe me:
I am not resistant or try to hide anything!
As written before, I don't know what exception to search for, so I wrote the (wrong) code:
except:
print "error"
Let's why I don't have a clue about it.
But someone already explained me that I should not do this.

Though looking at your code more closely I can see that likely the error

is related to the fact that /tmp/mypipe is not an executable program.

Yes it is and has rwx permissions.
Unfortunately I don't have access to the code in the pipe.

running programs and communicating with them over pipes created by the

popen function. So your code is not likely to ever work as it is

presently given.



Here's the bash equivalent of your code:



$ mkfifo /tmp/path

$ cat </tmp/path &

$ echo hello, world | /tmp/path



Bash will say, "bash: /tmp/path: Permission denied"



The correct bash line is:

$ echo hello, world > /tmp/path



popen() (and subprocess) is the equivalent of the first bash command.

open() is the equivalent of the second line.

Do you understand the difference?

I think I do now, thanks.
mik

 

[mikprog]

As Peter said, nothing for now. But you seem very resistant to telling

us what exception was raised.

Michael believe me:
I am not resistant or try to hide anything!
As written before, I don't know what exception to search for, so I wrote the (wrong) code:
except:
print "error"
Let's why I don't have a clue about it.
But someone already explained me that I should not do this.

Though looking at your code more closely I can see that likely the error

is related to the fact that /tmp/mypipe is not an executable program.

Yes it is and has rwx permissions.
Unfortunately I don't have access to the code in the pipe.

running programs and communicating with them over pipes created by the

popen function. So your code is not likely to ever work as it is

presently given.



Here's the bash equivalent of your code:



$ mkfifo /tmp/path

$ cat </tmp/path &

$ echo hello, world | /tmp/path



Bash will say, "bash: /tmp/path: Permission denied"



The correct bash line is:

$ echo hello, world > /tmp/path



popen() (and subprocess) is the equivalent of the first bash command.

open() is the equivalent of the second line.

Do you understand the difference?

I think I do now, thanks.
mik

 

[John Gordon]

As written before, I don't know what exception to search for, so I wrote
the (wrong) code:
except:
print "error"
Let's why I don't have a clue about it.
But someone already explained me that I should not do this.

If you don't know what exception is being raised, temporarily remove the
try/except statements and run the code directly. You'll get the exception,
and then you'll know which one it is.

 

[Oscar Benjamin]

Michael believe me:
I am not resistant or try to hide anything!
As written before, I don't know what exception to search for, so I wrote the (wrong) code:
except:
print "error"
Let's why I don't have a clue about it.
But someone already explained me that I should not do this.

You don't need to look for errors. If you remove the try/except then
they show up automatically. For example (in the interpreter):

$ python
Python 2.7.3 (default, Sep 26 2012, 21:51:14)
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.Traceback (most recent call last):
File "<stdin>", line 1, in <module>
IOError: [Errno 21] Is a directory: 'Desktop'

The last three lines above are the error message that people were
expecting you to show here. They contains lots of useful information:
1) The type of the error
2) A message "Is a directory" and in this case a cryptic code 21 (that
some might find useful).
3) The line of code that caused the error (this is more useful when
running code saved in a file).

What you are doing, however, is this:
.... open('Desktop')
.... except:
.... print('An error occurred...')
....
An error occurred...

Which gives a much less useful error message. So just remove the try/except.


Oscar