On 21 February 2013 22:40, <piterrr.dolin...@gmail.com> wrote:
> Thanks to all for quick relies.
>
> Chris, you are (almost) spot on with the if blocks indentation. This is what
> 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
> declare them. For example, when I write "i = 0" it is perfectly OK to Python
> without 'i' being declared earlier. How do I know that I haven't used this
> 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 fun.
>
> 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 just
> used is limited in scope to the code within the { }. With Python, you have 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=0" 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 for
> statement. I don't agree with this, but I understand your points. The reason
> why I like parentheses is because they help with code clarity. I am obsessed
> with this. :-) After all, there is a reason why so many languages have
> 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 != 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!=0 works just as well).
> I want to learn a new language but Python's quirks are a bit of a shock to 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
--
http://mail.python.org/mailman/listinfo/python-list
