Python Newbie

[Dennis Lee Bieber]

condition1 = long_condition_expression_1
condition2 = long_condition_expression_2
condition3 = long_condition_expression_3

if condition1 and condition2 and condition3:
STUFF

No multiline needed. If you have *many* conditions, then:

Except that Python does short-circuit evaluation; your scheme will
fail in some situations:
.... print "we passed"
....Traceback (most recent call last):

 

[Chris Angelico]

The decision whether to call it JavaScript or ECMAScript really comes
down to, "Do you want to be correct, or do you want people to know what
you're talking about?"

"JavaScript/ECMAScript" works in many situations.

Wait, let me rephrase that.

The expression "JavaScript/ECMAScript" works in many situations.

ChrisA

 

[J.R.]

The decision whether to call it JavaScript or ECMAScript really comes
down to, "Do you want to be correct, or do you want people to know what
you're talking about?"

I was giving the reason why I used the language standardized name
(ECMAScript) in the previous paragraph that you snipped. However it is
perfectly okay using the term "JavaScript" when referring to an
ECMAScript implementation. The same happens when you ask for a Band-Aid,
not a bandage; or ask for Kleenex, not tissue, or when you “Google” for
a word instead of searching for it.

 

[Joshua Landau]

Except that Python does short-circuit evaluation; your scheme will
fail in some situations:

... print "we passed"
...
Traceback (most recent call last):

Yeah, well... context*.

There are perfectly legitimate ways of doing that too.

A simple one would be:

supercondition = (
long_condition_expression_1 and
long_condition_expression_2 and
long_condition_expression_3
)

if supercondition: ...

Please note the problem of the original is that the indentation dedents and
indents in too quick a sequence:

if (
something_here): # Where do I indent this to?
something_else

There are standards, but I don't like the style. I thought it worth
mentioning as we were all being subjective anyway ;P. It's much worse than:

if something_here: something_else #on the same line

which is already explicitly advised against.

* By which I mean: fair point

 

[Serhiy Storchaka]

By the way, when you're asking a completely new question, it usually
helps to do so as a brand new thread (not a reply) and with a new
subject line. Otherwise, you risk people losing the new question among
the discussion of the old.

You risk people losing your answer when you're answering such question.

 

[Nick Mellor]

Hi Piterr,

It's interesting how strong our habits are, isn't it? It's most likely you've just got a bit of culture shock.

I've used C# quite a bit as well as Python. I like them both.

What I like about Python is how it manages to be clear and terse at the same time.

if (flag==1) {
code
}

has quite a bit of redundancy in it (C or C#.) In Python:

if flag:
code

is a good shorthand that matches any non-zero value. Gone are the brackets and the braces and the meaning is crystal clear.

In the middle of a complex piece of code this clarity of syntax is fantastic for anyone reading the code-- so long as they know how Python works.

You may discover as you continue with Python that there is actually quite alot of freedom about how you use white space. Python doesn't much care *how* much you indent, just that you're consistent within the block:

if flag:
# do something
# do something else
# continue coding after the if stmt

is equivalent to

if flag:
# do something
# do something else
# continue coding after the if stmt

You're also allowed to break a line inside brackets, braces etc and use anyindenting you like:

if flag:
[o.process(i % 3 + w)
for i, o, w
in enumerate(zip(objects, words))
]
# do something else
# this is after the if block

The following is a good thread about "implied line continuation" (i.e. where line breaks and free indentation are allowed inside braces, square brackets or round brackets.)

http://stackoverflow.com/questions/53162/how-can-i-do-a-line-break-line-continuation-in-python

See also the Python style guide:

http://www.python.org/dev/peps/pep-0008/

There's also explicit line continuation, rather like Visual Basic:

if c + \
256 * \
(d + 256 * e) > 69427:
# do something
# do something else
# then leave the if block

Again, the line continuation doesn't mind what indent you use after it.

In this case you could put brackets around the expression and use implied line continuation:

if (c +
256 *
(d + 256 * e)) > 69427:
# do something
# do something else
# then leave the if block

This is the preferred method according to the Python style guide.

I hope you manage to give Python (and your job) a little longer to charm you


Cheers,

Nick

 

[rurpy]

On 02/24/2013 02:43 PM, (e-mail address removed) wrote:

<snip>
This is EXACTLY why you're having trouble grasping Python. Python is a different language and
requires a different mind-set and different approach. In this, it is NO different from ANY
other new (to you) programming language.

No. Programming languages have far more in common with other
languages than differences. This is particularly true of Python
which has always seemed to me as a very well-selected compilation
of existing programming language features rather than consisting
of groundbreaking new concepts.

Of course, don't forget general programming principles -- how to approach a problem, how to
select algorithms, and such. These apply to any language, but the details of syntax and such
ARE different in different languages. Trying to apply these old details to a new language only
hinders your learning process, it definitely does NOT help.

Actually, your comments and questions make me wonder HOW you are trying to learn Python. All
the things you're asking about are clearly and completely discussed in any decent book or
tutorial. It makes me speculate that you're simply trying to use a Python reference instead of
something that actually teaches anything. A reference may give you the rules and syntax, but
not much about how to apply them properly.

That is sadly true of the Python reference manuals (Language
and Library) but need not and should not be true in general.
There is no reason why someone with basic programming experience
in another similar language should not be able to learn a new
language from its *well written* reference manuals.

Please think about finding some better fundamental material -- there is a LOT available. And
please quit trying to force Python to be something it isn't. That is never going to be
effective and definitely harmful to your learning.

Part of learning, indeed much of the value in learning, a new
language when one already knows several others, is mentally
unifying the things that are similar in the old and new languages,
and distinguishing what is different.

You do NOT need to throw out everything you learned about those
other language to learn new one. Thinking of the features of the
new language in terms of the old one is a necessary part of this
process. I still think in terms of C pointers when thinking
about how Python references objects. The problem arises when
when one assumes that syntax that looks similar *should* behave
similarly.

As for migrating idioms from the previous language to the new
one, such as adding redundant parenthesis around the conditional
expression in an "if" statement, I think it is relatively
harmless. Contrary to previous claims, it will NOT result
in an "unmaintainable mess". I doubt if any maintainabilty
difference in such code could even be measured other than that
caused by a prima-donna-ish "eew, I'm not going to work on
that code because I think it is UGLY!" effect. Perhaps if
we were talking about a program manager setting such idioms
in stone for 100's of kilolines of code it would be different
but for the OPs situation, I see no harm in it.
If it helps the OP transition to python, then I say do it.

For the record, I did much the same thing coming to Python from
Perl. After a while I came to the common view that such parens
were more noise than clarifying but I reached that conclusion
based on my own experience rather than being bludgeoned into
it by extreme predictions of doom read here.

Python variables do NOT have any data type. The objects they reference have data types.
Variables can be assigned and RE-assigned to any data type at any time. Again, I emphasize,
QUIT THINKING IN ANOTHER LANGUAGE, it simply doesn't work. You might like it if it were so, but
it simply does not match reality.

I have no problem interpreting the OP's statement (as quoted
above) as meaning that he wanted to use a Python variable to
consistently reference a particular type and wanted a name
that would remind him of that type.

 

[Ethan Furman]

I have no problem interpreting the OP's statement
as meaning that he wanted to use a Python variable to
consistently reference a particular type and wanted a name
that would remind him of that type.

Which is all well and good, so long as the OP also realizes that the name does not have any restriction's on it from
Python's side, and certain functions will end up pointing the name at a different object with a possibly different type
than his original, as in my int/float example.

 

[rurpy]

Which is all well and good, so long as the OP also realizes
that the name does not have any restriction's on it from
Python's side, and certain functions will end up pointing
the name at a different object with a possibly different type
than his original, as in my int/float example.

Which I presume he did, given that he responded to your post with:

]