Python Newbie

[rurpy at yahoo.com]

On 02/26/2013 01:32 AM, Larry Hudson wrote:
> On 02/24/2013 02:43 PM, piterrr.dolinski at gmail.com wrote:
> <snip>
>> ...  But for the moment I am trying to imitate familiar ground.
> <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.

> <snip>
>> I wanted Python to register what type of variable I'm after...
> 
> 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.