Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!eu.feeder.erje.net!xlned.com!feeder1.xlned.com!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <5c262e95-b3a8-4f2a-b752-84b30bf4f81e@googlegroups.com>
References: <cad0eacc-6040-4a00-bd05-7fabfd2fa70e@googlegroups.com> <5c262e95-b3a8-4f2a-b752-84b30bf4f81e@googlegroups.com>
From: Oscar Benjamin <oscar.j.benjamin@gmail.com>
Date: Thu, 21 Feb 2013 23:27:34 +0000
Subject: Re: Python Newbie
To: piterrr.dolinski@gmail.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Python List <python-list@python.org>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.2214.1361489278.2939.python-list@python.org>
Lines: 115
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:39489

On 21 February 2013 22:40,  <piterrr.dolinski@gmail.com> wrote:
> Thanks to all for quick relies.
>
> Chris, you are (almost) spot on with the if blocks indentation. This is w=
hat I do, and it has served me well for 15 years.
>
> code
> code
>
>    if (some condition)
>    {
>       code
>       code
>    }
>
> code
> code

So you already indent blocks in an "if" construct? This is good
practise in some languages and is enforced in Python. Once I got used
to it I found that the compulsory whitespace made it easier to read
conditional code blocks.

>
> This is what I call code clarity. With Python, I am having to do this
>
> code
> code
>
> ##############################
>
> if (some condition):
>   code
>   code
>
> ##############################
>
> code
> code
>
> It does the job, but is not ideal.

Do you mean that you literally insert a line of '#' characters before
and after in "if" block? There's no need to do that. Just allow
yourself to acclimatise to the significant whitespace and you'll find
that it's easy to see where the block begins and ends.

>
> I am nervous about using variables "out of the blue", without having to d=
eclare them. For example, when I write "i =3D 0" it is perfectly OK to Pyth=
on without 'i' being declared earlier. How do I know that I haven't used th=
is variable earlier and I am unintentionally overwriting the value? I find =
I constantly have to use the search facility in the editor, which is not fu=
n.
>
> You see, Javascript, for one, behaves the same way as Python (no variable=
 declaration) but JS has curly braces and you know the variable you have ju=
st used is limited in scope to the code within the { }. With Python, you ha=
ve to search the whole file.

No, you only have to search the whole function which for me is rarely
more than 20 lines. The statement "i=3D0" when inside a function will
not overwrite anything outside the function (unless you use the
global/nonlocal statements). I rarely use global variables or module
level variables and if I do then I usually have a special place in a
module/script for defining them. I also tend to name them in ALLCAPS
just like C-preprocessor macros that need to be carefully maintained
in a separate "namespace".

>
> Thanks to Chris, Ian and Dave for explaining the () issue around if and f=
or statement. I don't agree with this, but I understand your points. The re=
ason why I like parentheses is because they help with code clarity. I am ob=
sessed with this. :-) After all, there is a reason why so many languages ha=
ve required them for several decades.

You'll get used to using the colon in the same way.

>
> What about Python's ambiguity?
> For example, in C you would write
>
> if (myVar !=3D 0)
>   do something
>
> in Python, this is legal
>
> if (not myVar):
>   do something
>
> What does this mean? Is it a test for myVar being equal to zero or a test=
 for null, or else?

All of those things. It executes "do something" if myVar is
1) zero (whether int/float/complex etc.)
2) False
3) None
4) an empty collection (list/set/tuple etc.)
5) an empty string
6) and more...

If the context doesn't make it clear what you are testing for then use
a more specific test (myVar!=3D0 works just as well).

> I want to learn a new language but Python's quirks are a bit of a shock t=
o me at this point. I have been Pythoning only for about a week.
>
> In the mean time, thanks to most of you for encouraging me to give Python=
 a chance. I will do my best to like it, w/o prejudice.

Many of the things that have confused/concerned you are things that I
actually like about Python. Given time you may do as well.


Oscar