Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!eu.feeder.erje.net!xlned.com!feeder5.xlned.com!news2.euro.net!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <928d2cf7-728b-4f35-b8c9-4c9b958507e5@googlegroups.com>
References: <cad0eacc-6040-4a00-bd05-7fabfd2fa70e@googlegroups.com> <mailman.2237.1361508661.2939.python-list@python.org> <kg7mfi$8oh$1@dont-email.me> <mailman.2259.1361535166.2939.python-list@python.org> <kg7t19$a63$1@dont-email.me> <XnsA16F92E78A66duncanbooth@127.0.0.1> <5127848B.1060004@gmail.com> <mailman.2271.1361545569.2939.python-list@python.org> <928d2cf7-728b-4f35-b8c9-4c9b958507e5@googlegroups.com>
From: Oscar Benjamin <oscar.j.benjamin@gmail.com>
Date: Fri, 22 Feb 2013 22:08:00 +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>, comp.lang.python@googlegroups.com
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.2306.1361570904.2939.python-list@python.org>
Lines: 95
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:39618

On 22 February 2013 21:37,  <piterrr.dolinski@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 intention=
al ambiguity in conditional statements. Specifically, the issue is, is it m=
ore appropriate to write (as an example)
>
> if (some statement):            # short form

That should be some *expression* rather than some *statement*. Some
languages allow all statements to be expressions but Python does not.

>
> rather than
>
> if (some statement =3D=3D true):    # long form

There is no heated argument about whether to do this. The long form is
pointless except perhaps in a test suite.

>
> Some 50(?) years ago, C was designed so that everything other than 0 eval=
uated 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 these languages and designe=
d a new language that would help minimize the potential for planting bugs.

I'm sure that they, like most people designing/developing languages,
did try to take the best features from other languages. Python does as
well.

> Say what you want about MS inventions, but my experience is that to requi=
re the long form notation was a good decision. For me the fact that the sho=
rt notation is legal in Python is a stepback in language design. Python inv=
entors, when creating what is after all considered a contemporary language,=
 should have known better. Call me psychopath if you will (have seen this i=
n one post), but I shall continue to use the aforementioned long form as I =
always have, and no Python is going to change that.

If you want to be really careful you can use (feel free to add more bracket=
s):
if (((condition =3D=3D True) =3D=3D True)):

Then you can be doubly sure it's true.

>
>
> Today I learned the hard way that all function parameters in Python are p=
assed 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 O=
NE reason why Python was designed that way?

New values are not passed. The same object is accessed in both places.
Sometimes this is useful and sometimes it is undesirable. The
important thing is to learn how to use the features of a language to
do what you want (instead of moaning about them for differing from
some other language).

>
> Out of curiosity, does anyone have any idea why function declarations are=
 preceded by the keyword "def" rather than something more intuitive like "f=
unction" or at least "func", perhaps?
>
> 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 preced=
ed by "else" and not "el".
>
> Someone said I am too narrow-sited appreciating C# and not open to altern=
ate approaches to language design. Well if that someone says "def" is bette=
r than "function" and "elif" is better than "else if", then dare I say, you=
 are obsessed with Python!

These things are just not that important. Every language has keywords
that need to be learned. Would you prefer the C version "void f()"?

>
> 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 on=
e) is the existence of extensive libraries. Otherwise there would be no goo=
d reason for Python to exist. Nevertheless, it does exist and I have to lea=
rn it. As long as someone is paying for my time, that's OK with me.

 Those extensive libraries would not have been created for a toy
language. Python had to have a reason to exist *before* people would
expend that much time, money and energy on it.


Oscar