Python Newbie

[Chris Angelico]

On Fri, Feb 22, 2013 at 8:26 AM, Piterrr <piterrr.dolinski at gmail.com> wrote:
> Hi folks.
> I am a long time C sharp dev, just learning Python now due to job requirements. My initial impression is that Python has got to be the most ambiguous and vague language I have seen to date. I have major issues with the fact that white space matters. How do you deal with this? For example, you open a source file in different editors and the indentation levels change even though i only have spaces, no tabs (compare Windows Notepad and Notepad++). Which editor do you trust? In addition, code is difficult to read because you cannot lay it out in easily discernable blocks. For example, I always tend to indent a full 'if' statement block so that it is easier to see where the if block starts and ends. Can't do that in Python. What is even more frustrating is that Python is inconsistent with its syntax. For example, when I write "if (myVariable != 0):" then this is OK but "for (i in intAry):" results in syntax error. Apparently Python has problems with my use of parentheses. How retarded. I
>  think I will rather find another job than eat my nerves with Python.
> Any comments on this before I quit my job?

The first comment I would make is this: Every language you learn MUST
teach you something new about programming, otherwise you haven't
really learned a new language (just a new dialect of an old one).
Embrace Python's differences, get to know how things work, then make
your decision as to what you like and what you don't :)

When there's a question of trust involving Windows Notepad, by default
trust the other option. Notepad *sucks* for pretty much everything.
Notepad++ is far more reliable. So is NoteTab, so is SciTE, so is
pretty much anything else on the market (though the Open Watcom editor
is designed exclusively for C, and may not be suitable for Python - it
has a habit of converting tabs to spaces, so you may run into
problems).

The issue of parentheses is one of syntax. Anything that's an
expression can have an extra set of parens around it; anything that's
not, can't. The same will happen in most languages; I daresay C# won't
let you put parentheses around the semicolon at the end of a
statement, for instance. In a for loop, the 'in' keyword separates two
expressions, so you can't have parens around it.

I'm not sure what you mean by "indenting a full 'if' statement block".
Do you mean this:

code
code
    if (some condition) {
    code
    code
    }
code
code

? Because that's a distinctly weird way to lay out code, and would be
against the style guides of many organizations (definitely against any
style guide that I write). Python forces you to use one of the more
common styles:

code
code
if (some condition) {
    code
    code
}
code
code

Since the braces are omitted in Python, the same Python code can
equally well represent the C standards of OTBS (as shown above),
Allman (with the opening brace on the next line, which is my
preference when writing C)... actually, every style in
http://en.wikipedia.org/wiki/Indent_style#Styles follows the pattern
of having 'if' not indented and the body indented, which is what
Python enforces. So this might be a change for you, but if you quit
your job, chances are you'll find an identical change as you conform
to some other workplace's style guide :)

Of course, Python does allow and encourage the use of blank lines to
help lay out your code. So if you're having trouble with the
readability of statements, try judiciously adding blanks before and/or
after, and see if that helps.

And if all that doesn't make you happy with Python, then do look for a
better job. Not every language is for everyone, and you'll produce
better code as a contented C# programmer than as a miffed Python
programmer :) But do consider learning multiple languages. Eric
Raymond states in one of his essays [1] that you would do well to
learn five basic languages: Python, C/C++, Java, Perl, and LISP.
They're distinctly different from each other, and will teach different
things about how to *code*, which is a skill separate from how to
*code C* or how to *code Perl*.

[1] http://www.catb.org/esr/faqs/hacker-howto.html

ChrisA