Python Newbie

[Mitya Sirenef]

On 02/22/2013 04:37 PM, piterrr.dolinski at gmail.com wrote:
> Thanks to everyone for all the  posts, some friendly some not. I read all of them with genuine interest.
 >
 > So I am continuing to learn Python, here are my new observations for 
your consideration.
 >
 > There seems to be a "heated" argument about Python's apparently
 > intentional ambiguity in conditional statements. Specifically, the
 > issue is, is it more appropriate to write (as an example)


I would say it's not a case of ambiguity but that you want the language
syntax to provide you hints that are not directly relevant to the logic
of a statement.

if mylist:  # unambiguous check for whether mylist evaluates to boolean True

if mylist == []:  # gives you a hint that mylist is meant to be an empty
                     # or a non-empty list

But what if I have:

process(mylist)

where is my hint? Why is hint required in an if statement but not
required in other cases when mylist is used: function calls, loops,
summation, etc?

The point is, if variables have good names, the hint is not necessary
and if variables have terrible names, you have bigger problems to deal
with.

>
 > if (some statement): # short form
 >
 > rather than
 >
 > if (some statement == true): # long form
 >
 > Some 50(?) years ago, C was designed so that everything other than 0
 > evaluated to true and was false otherwise. Fast forward to recent
 > memory, when C# was designed, Microsoft claims they reviewed all the
 > features of C, C++ and Java, pulled the best features from each of


Fun fact: few language designers claim they took all the _worst_
features from other languages, or that they took a random sampling of
worst, best and middling features.

> these languages and designed a  new language that would help minimize
 > the potential for planting bugs. Say what you want about MS
 > inventions, but my experience is that to require the long form
 > notation was a good decision. For me the fact that the short notation
 > is legal in Python is a stepback in language design. Python inventors,
 > when creating what is after all considered a contemporary language,
 > should have known better. Call me psychopath if you will (have seen
 > this in one post), but I shall continue to use the aforementioned long
 > form as I always have, and no Python is going to change that.
 >
 >
 > Today I learned the hard way that all function parameters in Python
 > are passed by reference (meaning whatever happens to them inside a
 > function, new values are always passed to caller). Not good. I got
 > caught up on this. To combat the mostly unwanted behavior, inside a
 > function I have to reassign variables intended to be local to new
 > variables. A pain. Can anyone offer ONE reason why Python was designed
 > that way?


The idea is that copying should always be explicit so that if you don't
want the object to be copied, you pass it around and change it as
needed, and if you want the copy, you make a copy explicitly.

It makes sense to me because if you had a large sequence or mapping and
passed it to a hundred (or a thousand) functions, you'd have a hundred
or thousand copies - not good for performance. When you need a copy -
make a copy, what can be simpler than that?

>
 > Out of curiosity, does anyone have any idea why function declarations
 > are preceded by the keyword "def" rather than something more intuitive
 > like "function" or at least "func", perhaps?

But it's not a function, it's a function definition! Why are you not
demanding 'function definition' instead? function implies the function
object, which is what you use after you define the function definition.

Def is a bit aesthetically better and unambiguous (I thought you were a
fan of that?). func sounds like you work on a tough project and get too
deep in it and forget to shower for a few weeks no I mean days, what a
silly mistake to make (I guess I could just go back and fix it), but my
point is, function would work too but def is perfectly short and clear.

>
 > Does anyone know what the benefit of writing the cryptic "elif" to
 > mean "else if" is? Curiously, the default statement in an if/else
 > chain is preceded by "else" and not "el".


ruby, unix shells, c preprocessor also use elif; perl uses elsif, php
uses elseif.

It's a judgement call, I for one like elif a bit better because it's
shorter without sacrificing clarity.

>
 > Someone said I am too narrow-sited appreciating C# and not open to
 > alternate approaches to language design. Well if that someone says
 > "def" is better than "function" and "elif" is better than "else if",
 > then dare I say, you are obsessed with Python!
 >
 > So far I am getting the impression that Python is a toy language of
 > some kind (similar to Basic of the early 80's), not really suitable
 > for serious work. The only difference between these languages
 > (admittedly, a serious one) is the existence of extensive libraries.
 > Otherwise there would be no good reason for Python to exist.
 > Nevertheless, it does exist and I have to learn it. As long as someone
 > is paying for my time, that's OK with me.


It's been used for many important projects by a huge number of big
companies:

http://www.python.org/about/success/

Unlike Java and C#, it's not backed by a marketing effort of a large
company, so its success is entirely due to its value.

  -m


-- 
Lark's Tongue Guide to Python: http://lightbird.net/larks/

A conception not reducible to the small change of daily experience is like
a currency not exchangeable for articles of consumption; it is not a
symbol, but a fraud.  George Santayana