oscar.j.benjamin at gmail.com
Fri Feb 22 23:08:00 CET 2013
On 22 February 2013 21:37, <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)
> 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 == 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 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 these languages and designed 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
> 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.
If you want to be really careful you can use (feel free to add more brackets):
if (((condition == True) == True)):
Then you can be doubly sure it's true.
> 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?
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 "function" 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 preceded by "else" and not "el".
> 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!
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 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.
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.
More information about the Python-list