Am I not seeing the Error?

[Devyn Collier Johnson]

I am checking my 1292-line script for syntax errors. I ran the following
commands in a terminal to check for errors, but I do not see the error.

collier@Nacho-Laptop:/media/collier/AI/Pysh$ python3 -m py_compile
../beta_engine
File "./beta_engine", line 344
JOB_WRITEURGFILES =
multiprocessing.Process(write2file('./mem/ENGINE_PID', ENGINEPID);
write2file(SENTEMPPATH, ''); write2file(INPUTMEM, ''));
JOB_WRITEURGFILES.start()
^
SyntaxError: invalid syntax
collier@Nacho-Laptop:/media/collier/AI/Pysh$ pylint ./beta_engine
No config file found, using default configuration
************* Module beta_engine
E:344,0: invalid syntax


Here is line 344:

JOB_WRITEURGFILES =
multiprocessing.Process(write2file('./mem/ENGINE_PID', ENGINEPID);
write2file(SENTEMPPATH, ''); write2file(INPUTMEM, ''));
JOB_WRITEURGFILES.start()

The ENGINEPID is a variable containing a string. My write2file function is

def write2file(openfile, WRITE):
with open(openfile, 'rw') as file:
file.write(WRITE)


Mahalo,

(e-mail address removed)

 

[John Gordon]

I am checking my 1292-line script for syntax errors. I ran the following
commands in a terminal to check for errors, but I do not see the error.

File "./beta_engine", line 344
JOB_WRITEURGFILES =
multiprocessing.Process(write2file('./mem/ENGINE_PID', ENGINEPID);

You have too many ('s this line.

write2file(SENTEMPPATH, ''); write2file(INPUTMEM, ''));

And too many )'s on this one.

 

[Denis McMahon]

I am checking my 1292-line script for syntax errors. I ran the following
commands in a terminal to check for errors, but I do not see the error.

JOB_WRITEURGFILES =
multiprocessing.Process(write2file('./mem/ENGINE_PID', ENGINEPID);
write2file(SENTEMPPATH, ''); write2file(INPUTMEM, ''));
JOB_WRITEURGFILES.start()

When I expand this out to one item per line,

JOB_WRITEURGFILES =
multiprocessing.Process
(
write2file
(
'./mem/ENGINE_PID'
,
ENGINEPID
)
;
write2file
(
SENTEMPPATH
,
''
)
;
write2file
(
INPUTMEM
,
''
)
)
;
JOB_WRITEURGFILES.start()

and I wonder (not being familiar with multiprocessing) if perhaps there
should have been a third ";" after the third write2file in the job
definition.

 

[Dave Angel]

When I expand this out to one item per line,

JOB_WRITEURGFILES =
multiprocessing.Process
(
write2file
(
'./mem/ENGINE_PID'
,
ENGINEPID
)
;
write2file
(
SENTEMPPATH
,
''
)
;
write2file
(
INPUTMEM
,
''
)
)
;
JOB_WRITEURGFILES.start()

and I wonder (not being familiar with multiprocessing) if perhaps there
should have been a third ";" after the third write2file in the job
definition.

The mistake is not that it's missing the 3rd, but that the first two
semicolons should have been commas. These are parameters to a function
call multiprocessing.Process()

 

[MRAB]

When I expand this out to one item per line,

JOB_WRITEURGFILES =
multiprocessing.Process
(
write2file
(
'./mem/ENGINE_PID'
,
ENGINEPID
)
;
write2file
(
SENTEMPPATH
,
''
)
;
write2file
(
INPUTMEM
,
''
)
)
;
JOB_WRITEURGFILES.start()

and I wonder (not being familiar with multiprocessing) if perhaps there
should have been a third ";" after the third write2file in the job
definition.

No, there shouldn't be _any_ semicolons.

Basically it should be something like:

my_process = multiprocessing.Process(target=my_function)
my_process.start()

 

[Ned Batchelder]

The mistake is not that it's missing the 3rd, but that the first two
semicolons should have been commas. These are parameters to a function
call multiprocessing.Process()

Everyone: this program seems to be a direct and misguided
transliteration from a bash script. There are dozens of mis-uses like
this of multiprocessing.Process(), due to a severe misunderstanding of
what it does and how it works.

We've tried offering help, and all that's happened is we've been told
that this strange coding style is easier to read.

--Ned.

 

[Gregory Ewing]

Everyone: this program seems to be a direct and misguided
transliteration from a bash script.

Not a particularly well-written bash script, either --
it's full of superfluous uses of 'cat'.

 

[Joshua Landau]

Not a particularly well-written bash script, either --
it's full of superfluous uses of 'cat'.

What's wrong with cat? Sure it's superfluous but what makes it *bad*?
Personally I often prefer the pipe "cat x | y" form to "x < y"... or
"< y x".

There seems to be a militant "cat is evil" attitude where I feel it's
just normally just people who want to show others they know more bash
than they do.

 

[Chris Angelico]

What's wrong with cat? Sure it's superfluous but what makes it *bad*?
Personally I often prefer the pipe "cat x | y" form to "x < y"... or
"< y x".

What's the use of it, in that situation? Why not simply use
redirection? (Though you have the letters backward; "cat y | x" would
be the equivalent of your others. Typo, I assume.) You're forking a
process that achieves nothing, if your cat has just one argument.

Of course, there ARE many good uses for cat. If you give it multiple
arguments, or if you have arguments that modify the output on the way
through (eg "cat -n"), then it's not the same as redirection. And some
programs behave differently if stdout is a tty, so the quickest way to
get the porcelain version of something is to append "|cat" to the
command. Or maybe you need to retrieve something that only root can
read, so you use "sudo cat /x/y/z|somescript". But if you could spell
it "x < y", then why not do so?

ChrisA

 

[Joshua Landau]

What's the use of it, in that situation? Why not simply use
redirection? (Though you have the letters backward; "cat y | x" would
be the equivalent of your others. Typo, I assume.) You're forking a
process that achieves nothing, if your cat has just one argument.

Of course, there ARE many good uses for cat. If you give it multiple
arguments, or if you have arguments that modify the output on the way
through (eg "cat -n"), then it's not the same as redirection. And some
programs behave differently if stdout is a tty, so the quickest way to
get the porcelain version of something is to append "|cat" to the
command. Or maybe you need to retrieve something that only root can
read, so you use "sudo cat /x/y/z|somescript". But if you could spell
it "x < y", then why not do so?

Because "cat y | x" often reads nicer. It's the whole "input ->
function -> function -> ... -> output" thing.

I especially hate "y < input > output" which reads awfully not matter
where you chuck the spaces. "cat input | y > output" however, is
acceptable.

Honestly I do think Python would do well to get a pipe operator,
because in some circumstances it's just cleaner.

 

[Roy Smith]

What's the use of it, in that situation? Why not simply use
redirection? (Though you have the letters backward; "cat y | x" would
be the equivalent of your others. Typo, I assume.) You're forking a
process that achieves nothing, if your cat has just one argument.

This is waaaaayyyy off-topic for a Python discussion, but...

There's two reasons UUOC is a silly issue. First, it may save human
effort. I like to build up long complicated commands and pipelines one
bit at a time, and look at the intermediate results. Let's say I'm
starting with a sed command (abstracted from my current shell history)

$ sed -e 's/.*; iOS/iOS/' -e 's/;.*//' -e 's/\..*//' x

When I want to add the next "-e whatever" to the command, I need to get
it in front of the "x". If I had written it as:

$ cat x | sed -e 's/.*; iOS/iOS/' -e 's/;.*//' -e 's/\..*//'

I just have to stick it at the end, which is easier; I just type
control-p and add what I want. Or, "!!" and keep typing. A small
amount of human convenience (especially when it's mine) is worth a lot
of wasted CPU time.

Second, in some cases, the extra "cat" process may actually speed up
overall command execution because it provides additional I/O buffering.
The cat process will read ahead from the disk file and block only when
its output pipe buffers are full. When the sed command is ready to
process more input, it only has to read from the pipe, not wait for a
(very slow, by comparison) disk read. Yeah, I know, modern kernels do
lots of read-ahead buffing on their own. This gives you more.

Sure, it costs something to fork/exec another process. So what? The
computer exists to do my bidding, not the other way around.