Re: manipulating files within 'for'

[Ben Keshet]

Emile van Sebille wrote:

Ben Keshet wrote:

>Hi Pythoneers,

I have a question about a code I wrote with the help of someone. The
code below copy a few lines from different files into one file. It
works fine as it is given here and generates the new file
'pockets.out ' correctly, but says:"....py returned exit code 0".
However, if I add more values to 'receptor' (say, receptor = ['1AZM'
'1ADS'])

At risk of stating the obvious, you _did_ put this in properly as

receptors = ['1AZM', '1ADS']

...right?

Emile

....wrong. I thought I should omit the comma and didn't put it. I guess
that stating the obvious should be the first attempt with beginners like
me. Thanks for thinking about it (it's running perfect now).

BK

>
it gives an

>error: "Exception raised while running script".

Can anyone please advice me? Why is it giving an error on multiple x
but runs well with one (I made sure that all files and folders exist,
etc.). What does exit code 0 mean?

No error

>what does "exception raised" mean?

Error

--
http://mail.python.org/mailman/listinfo/python-list

[bearophileHUGS]

Ben Keshet:

...wrong. I thought I should omit the comma and didn't put it. I guess
that stating the obvious should be the first attempt with beginners like
me. Thanks for thinking about it (it's running perfect now).

In CLisp, Scheme etc, lists such commas aren't necessary, but in
Python if you don't separate strings with a comma they become merged
into a single string:

>>'foo', 'bar'

('foo', 'bar')

>>'foo' 'bar'

'foobar'

Your mistake is caused by Python not following one of its general
rules:

Explicit is better than implicit.

In such case the string concatenation (+) is done implicitly. It's a
little handy feature once in a while (but not for me so far), while it
may cause bugs, so I don't like this little feature of Python and I
may like to see it removed, because it may bite you in similar
situations, where you forgot a comma for mistake:

parts = ["foo", "bar" "baz"]

Bye,
bearophile

[Matt Nordhoff]

be************@ lycos.com wrote:

Ben Keshet:

>...wrong. I thought I should omit the comma and didn't put it. I guess
that stating the obvious should be the first attempt with beginners like
me. Thanks for thinking about it (it's running perfect now).

In CLisp, Scheme etc, lists such commas aren't necessary, but in
Python if you don't separate strings with a comma they become merged
into a single string:

>>>'foo', 'bar'

('foo', 'bar')

>>>'foo' 'bar'

'foobar'

Your mistake is caused by Python not following one of its general
rules:

Explicit is better than implicit.

In such case the string concatenation (+) is done implicitly. It's a
little handy feature once in a while (but not for me so far), while it
may cause bugs, so I don't like this little feature of Python and I
may like to see it removed, because it may bite you in similar
situations, where you forgot a comma for mistake:

parts = ["foo", "bar" "baz"]

Bye,
bearophile

It's useful when wrapping a line. For lack of better lorem ipsum:

whatever = some_function(" Your mistake is caused by Python not "
"following one of its general rules:\n\n"
"Explicit is better than implicit.")

You can also use backslashes, and probably even + if you want to, but
the implicit concatenation is prettier (IMO, at least ;-).

But you do have a point. I have never thought about the problems it
could cause.

BTW, I could easily be wrong, but I think C behaves the same way as Python.
--

[bearophileHUGS]

Matt Nordhoff:

It's useful when wrapping a line. For lack of better lorem ipsum:

whatever = some_function(" Your mistake is caused by Python not "
"following one of its general rules:\n\n"
"Explicit is better than implicit.")

You can also use backslashes, and probably even + if you want to, but
the implicit concatenation is prettier (IMO, at least ;-).

Adding a + at the end of lines isn't much extra work:

whatever = some_function(" Your mistake is caused by Python not " +
"following one of its general rules:\n\n" +
"Explicit is better than implicit.")

Or even:

whatever = "Your mistake is caused by Python not " + \
"following one of its general rules:\n\n" + \
"Explicit is better than implicit."

But you do have a point. I have never thought about the problems it
could cause.

Probably such problems aren't much common, because common bugs are
already prevented by Python designers :-) But I think once I have
written a bug like this:

parts = ["foo", "bar" "baz", "spam"]

Where I meant a list of 4 strings.

BTW, I could easily be wrong, but I think C behaves the same way as Python.

I know, but here changing the behavior respect to C doesn't cause bugs
to C programmers, because in that situation their Python program just
doesn't run. So it's not a Python syntax that looks like a C syntax
that behaves in a different way (this rule is used by the D designer
too: when something behaves differently from C (often to avoid a
common C pitfall), it has a different syntax. Where the D syntax is
the same of C syntax, then the D behavior is generally the same. This
avoids several problems to programmers coming from C/C++).

Bye,
bearophile

[bearophileHUGS]

Matt Nordhoff:

BTW, I could easily be wrong, but I think C behaves the same way as Python.

C syntax has many traps that are much better out of modern languages
like Python/D/etc.

I think C has that feature because it lacks an operator for string
concatenation, while both Python and D have one (+ and ~. D uses the ~
to avoid any programmer confusion with the mathematical summing
operator), so the situation of Python/D is different.

Bye,
bearophile