R
Rui Maciel
Mitya said:
The Go programming language makes that style mandatory.
Rui Maciel
The Go programming language makes that style mandatory.
Rui Maciel
C
Chris Angelico
[citation needed]
What do you mean by "that style"? The OP's style with the 'if'
indented? I just checked out golang.org for examples, and they're
written in OTBS.
ChrisA
R
Rui Maciel
Chris said:
Read Mitya Sirenef's post, specifically the bit I've replied to.
Rui Maciel
C
Chris Angelico
I did read it, and grammatically, your statement means that Go
mandates the OP's style. Hence my statement that golang.org has code
examples in OTBS, ergo Go cannot mandate the OP's style.
Or else golang.org is wrong. That's certainly possible, but you know
what they say about extraordinary claims.
ChrisA
S
Steve Simmons
Oooh, this is making my head spin. Are you saying that the OP's
question about proper indentation has resulted in an incorrectly
answered post due to poor indentation of a reference to the indentation
of another reference?
Steve
C
Chris Angelico
............
I think I'll go back to compiling and installing non-free NVIDIA
drivers for Debian Unstable on a vital production server. Fraught with
less danger.
ChrisA
P
piterrr.dolinski
Thanks to everyone for all the posts, some friendly some not. I read all ofthem 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 intentionalambiguity in conditional statements. Specifically, the issue is, is it more appropriate to write (as an example)
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 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 ONEreason why Python was designed that way?
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 precededby "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!
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 learnit. As long as someone is paying for my time, that's OK with me.
Peter
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 intentionalambiguity in conditional statements. Specifically, the issue is, is it more appropriate to write (as an example)
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 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 ONEreason why Python was designed that way?
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 precededby "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!
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 learnit. As long as someone is paying for my time, that's OK with me.
Peter
P
piterrr.dolinski
Thanks to everyone for all the posts, some friendly some not. I read all ofthem 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 intentionalambiguity in conditional statements. Specifically, the issue is, is it more appropriate to write (as an example)
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 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 ONEreason why Python was designed that way?
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 precededby "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!
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 learnit. As long as someone is paying for my time, that's OK with me.
Peter
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 intentionalambiguity in conditional statements. Specifically, the issue is, is it more appropriate to write (as an example)
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 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 ONEreason why Python was designed that way?
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 precededby "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!
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 learnit. As long as someone is paying for my time, that's OK with me.
Peter
O
Oscar Benjamin
That should be some *expression* rather than some *statement*. Some
languages allow all statements to be expressions but Python does not.
There is no heated argument about whether to do this. The long form is
pointless except perhaps in a test suite.
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.
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.
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).
These things are just not that important. Every language has keywords
that need to be learned. Would you prefer the C version "void f()"?
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
I
Ian Kelly
Nobody would advocate that particular comparison. If the result of
"some statement" is already a boolean value, then just use that
expression in your if statement. Checking "if True == True:" is a
pointlessly verbose comparison when you can just check "if True:".
The tension here is not between "short form" and "long form" if
statements, but between using conditional expressions that evaluate to
booleans versus using conditional expressions that are implicitly
interpreted as booleans. Some people prefer only the former. Others
see value in the latter for some (not all!) conditions.
The usual advice given for implicit interpretation is that it is a
test for "something" versus "nothing". If I do "if x:" and it
evaluates as true, then I know there is something in x. Otherwise, I
have nothing: None, or zero, or an empty sequence, etc. Generally the
context will give you more information about what types are expected.
Personally, I find that this tends to be most useful as a test for
whether a sequence contains elements.
At least one part of the reason that Python does not specifically
require booleans in conditions is that the language did not originally
have a boolean type; 1 and 0 were generally used instead. The bool
type was not added until version 2.3, and requiring booleans in
conditions at that point would have broken a large amount of code.
Not quite. Python uses pass-by-object (also known as
"pass-by-sharing") semantics. The argument seen by the function is
the same object that was passed to it. The name bound to the object
inside the function is unrelated to the name bound to the object in
the caller's context, so that if you assign something else to the
name, it will not affect the object or its binding to the external
name. Since it's the same object, though, you can mutate the object
and then later observe those changes in the external context.
Note that this is only relevant for mutable data types. For immutable
types such as strings and ints, you cannot alter the passed-in object,
so it is semantically equivalent to pass-by-value without the overhead
of actually copying anything.
Reassigning the objects to new variables would make no difference, as
you would still be dealing with the same objects. You would have to
actually copy the objects in order that changes to them would only be
local to the function. You would then be free to assign the copied
objects back to the original variable name, and then you would no
longer have any reference to the original objects within the function.
In other words, this will protect a list passed in from being mutated:
def foo(my_list):
my_list = list(my_list)
...
This will not:
def foo(my_list):
another_name_for_my_list = my_list
...
How about because the overhead of copying every object passed into
every function would be inefficient?
What Python does here is not all that different from how .NET
reference types are passed by default. The call semantics of these
two examples are basically the same:
# Python:
def foo(index, my_list):
my_list[index] = 42
/* C Sharp */
void foo(int index, int[] my_list)
{
my_list[index] = 42;
}
In both cases, reassigning index would have no effect outside the
function. In C#, it's because the argument is passed by value; in
Python, it's because the assignment merely binds a different object to
the name. In both cases, reassigning my_list would have no effect
outside the function, for the same reasons.
In both cases, modifying index without reassigning it would still have
no effect outside the function. In C#, this is because int is a value
type; in Python, it's because ints are immutable in the first place.
Finally, in both cases, modifying the contents of my_list *does* have
a visible effect outside the function. In C#, it's because arrays are
a reference type; in Python, it's because the list object is shared by
the caller and callee.
So with that in mind, I have a hard time understanding why you might
be finding this strange and unexpected.
Because that's what Guido picked when he started writing the language
in 1989, and it's too late to change it.
Lots of languages use "elif" or "elsif" or "elseif" or some variation
thereof. Why does it matter?
P
piterrr.dolinski
Hi Ian,
Thanks for typing all this for me. Really useful. I did some googling of myown and I found that there was no concept of boolean in older versions of Python like you said. (BTW, how does this omission go well with proper language design, as Oscar seems to have hinted?) I think this obvious shortcomming is the main reason that, for example, when x holds the value of 5, x isconsidered to be "true". You see, I have to maintain Python files (ubuntu server scripts) which are 2000 lines long, all sequential code, no functions. While the person who wrote them should be shot
, the fact that there is inherent ambiguity with value, none, null 0, you name it, in conditional statements is not helping me understand the code, and this adds to my frustration.
I messed up my
if (some statement): # short form
in the example I gave, but you figured exactly what I mean. Of course if the condition (some statement) is boolean there is no point adding "== true" or similar. But if (some statement) represents a value this is where I have trouble and again the origins of this date back to when Python had no boolean type. So now at least I understand it.
Btw, there are still languages with no boolean type today, MySQL for one. This creates big efficiency problems when fetching data from the database into a C# program - what should be a bool is fetched as an 8-byte integer! But that's a different story. I shut up now.
As I said I am new to Python, learning it, I have to get more experience with passing parameter values to functions, as I do with mostly everything else.
Cheers.
Peter
Thanks for typing all this for me. Really useful. I did some googling of myown and I found that there was no concept of boolean in older versions of Python like you said. (BTW, how does this omission go well with proper language design, as Oscar seems to have hinted?) I think this obvious shortcomming is the main reason that, for example, when x holds the value of 5, x isconsidered to be "true". You see, I have to maintain Python files (ubuntu server scripts) which are 2000 lines long, all sequential code, no functions. While the person who wrote them should be shot
, the fact that there is inherent ambiguity with value, none, null 0, you name it, in conditional statements is not helping me understand the code, and this adds to my frustration.I messed up my
if (some statement): # short form
in the example I gave, but you figured exactly what I mean. Of course if the condition (some statement) is boolean there is no point adding "== true" or similar. But if (some statement) represents a value this is where I have trouble and again the origins of this date back to when Python had no boolean type. So now at least I understand it.
Btw, there are still languages with no boolean type today, MySQL for one. This creates big efficiency problems when fetching data from the database into a C# program - what should be a bool is fetched as an 8-byte integer! But that's a different story. I shut up now.
As I said I am new to Python, learning it, I have to get more experience with passing parameter values to functions, as I do with mostly everything else.
Cheers.
Peter
P
piterrr.dolinski
Hi Ian,
Thanks for typing all this for me. Really useful. I did some googling of myown and I found that there was no concept of boolean in older versions of Python like you said. (BTW, how does this omission go well with proper language design, as Oscar seems to have hinted?) I think this obvious shortcomming is the main reason that, for example, when x holds the value of 5, x isconsidered to be "true". You see, I have to maintain Python files (ubuntu server scripts) which are 2000 lines long, all sequential code, no functions. While the person who wrote them should be shot, the fact that there is inherent ambiguity with value, none, null 0, you name it, in conditional statements is not helping me understand the code, and this adds to my frustration.
I messed up my
if (some statement): # short form
in the example I gave, but you figured exactly what I mean. Of course if the condition (some statement) is boolean there is no point adding "== true" or similar. But if (some statement) represents a value this is where I have trouble and again the origins of this date back to when Python had no boolean type. So now at least I understand it.
Btw, there are still languages with no boolean type today, MySQL for one. This creates big efficiency problems when fetching data from the database into a C# program - what should be a bool is fetched as an 8-byte integer! But that's a different story. I shut up now.
As I said I am new to Python, learning it, I have to get more experience with passing parameter values to functions, as I do with mostly everything else.
Cheers.
Peter
Thanks for typing all this for me. Really useful. I did some googling of myown and I found that there was no concept of boolean in older versions of Python like you said. (BTW, how does this omission go well with proper language design, as Oscar seems to have hinted?) I think this obvious shortcomming is the main reason that, for example, when x holds the value of 5, x isconsidered to be "true". You see, I have to maintain Python files (ubuntu server scripts) which are 2000 lines long, all sequential code, no functions. While the person who wrote them should be shot
, the fact that there is inherent ambiguity with value, none, null 0, you name it, in conditional statements is not helping me understand the code, and this adds to my frustration.I messed up my
if (some statement): # short form
in the example I gave, but you figured exactly what I mean. Of course if the condition (some statement) is boolean there is no point adding "== true" or similar. But if (some statement) represents a value this is where I have trouble and again the origins of this date back to when Python had no boolean type. So now at least I understand it.
Btw, there are still languages with no boolean type today, MySQL for one. This creates big efficiency problems when fetching data from the database into a C# program - what should be a bool is fetched as an 8-byte integer! But that's a different story. I shut up now.
As I said I am new to Python, learning it, I have to get more experience with passing parameter values to functions, as I do with mostly everything else.
Cheers.
Peter
S
Steven D'Aprano
They must be true?
"Extraordinary claims are always true" would be an extraordinary claim,
and therefore true. I learned this from Weekly World News, the world's
only reliable newspaper.
http://weeklyworldnews.com/headlines/44680/pteranodon-terrifies-wyoming-town/
C
Chris Angelico
I think this obvious shortcomming is the main reason that, for example, when x holds the value of 5, x is considered to be "true". You see, I have to maintain Python files (ubuntu server scripts) which are 2000 lines long, all sequential code, no functions. While the person who wrote them should be shot
When you want to clearly ask if something is the specific value True,
you can do that thus:
if x is True:
That's the canonical ("pythonic") way to explicitly check for a
boolean value, in the same way that PHP scripts test
strpos(...)===FALSE.
It's really not that big a deal to have or not have an explicit
boolean type. Ultimately, the CPU is going to work with integers,
booleans, strings, and so on, in the same way, and that most likely
will be an integer of at least 4 bytes in size - the "machine word"
for your architecture. Asking for anything smaller comes with a
performance hit. So it's easier to store and manage booleans as 4-byte
or 8-byte integers containing either 1 or 0, than to have some kind of
"bit" type - unless we're talking about a *set* of booleans, which is
sometimes implemented as bitflags.
Really, there are worse things in the world. Don't get het up about
boolean types.
ChrisA
C
Chris Angelico
It's probably escaped from the town of Eureka, from the Syfy series
(now cancelled, more's the pity) of the same name.
In fact, if that happened in Eureka, it either wouldn't be remarkable,
or would be this episode's Monster of the Week. Bit of a toss-up
which, actually.
ChrisA
T
Terry Reedy
On 2/22/2013 4:37 PM, (e-mail address removed) wrote:
Yours is the first post here, that I know of, from someone 'forced' to
learn and use Python at their job. Several people have instead
complained about being prohibited from using Python at work. I am sorry
that you have been introduced to it in such a poor way.
I am doubly sorry that your first Python job is to work with a monstrous
script that most of us would likely also hate. I am sure anyone
responding here would have split 2000 lines into multiple testable
functions even if every function was called just once (other than in the
test code).
I came to Python from C. It took me about 2 weeks to grok the difference
between being object based and memory-block based. I am glad someone who
knows something of C# could say more.
About 'if obj: pass'. Simplifying just a bit, the interpreter executes
that internally as 'if obj.__bool__() ...'. It adds the implicit call so
you do not have to write it, or an equivalent expression. For each
class, the method gives an appropriate default classification. For
numbers, 'if x' means 'if x != 0'. For collections, 'if c' means 'if
len(c) != 0'. Once one gets used to it, it is a great saving in writing
and reading. If the default classification is not the one you want, you
write an explicit expression that is the one you want.
I too would have preferred fun or func, but I live with def.
As for function calling, forget 'pass by value' versus 'pass by
reference'. Both mislead in certain situations.
x = y+3
computes an object from 'y+3', looking up name 'y' in the current
namespaces, and associates the object with name 'x' in the current local
namespace. (This assumes the default situation with no 'global x' or
'nonlocal x' declarations.)
def f(x): return 2*x
f(y+3)
computes an object from 'y+3' looking up name 'y' in the current
namespaces, makes the local namespace of f the current local namespace,
and associates the object with the name 'x' in the new local namespace.
Toy? I think the first 'killer app' for Python was nuclear weapon
calculations at U.S. National Labs (Livermore and Los Alamos), where
numerical python started. The current version, numpy, along with scipy
and many other packages, is used throughout the sciences.
On the other hand, Python is the most fun language for most of us, so in
that sense it's a great toy. And I also think it a great replacement for
Basic.
Yours is the first post here, that I know of, from someone 'forced' to
learn and use Python at their job. Several people have instead
complained about being prohibited from using Python at work. I am sorry
that you have been introduced to it in such a poor way.
I am doubly sorry that your first Python job is to work with a monstrous
script that most of us would likely also hate. I am sure anyone
responding here would have split 2000 lines into multiple testable
functions even if every function was called just once (other than in the
test code).
I came to Python from C. It took me about 2 weeks to grok the difference
between being object based and memory-block based. I am glad someone who
knows something of C# could say more.
About 'if obj: pass'. Simplifying just a bit, the interpreter executes
that internally as 'if obj.__bool__() ...'. It adds the implicit call so
you do not have to write it, or an equivalent expression. For each
class, the method gives an appropriate default classification. For
numbers, 'if x' means 'if x != 0'. For collections, 'if c' means 'if
len(c) != 0'. Once one gets used to it, it is a great saving in writing
and reading. If the default classification is not the one you want, you
write an explicit expression that is the one you want.
I too would have preferred fun or func, but I live with def.
As for function calling, forget 'pass by value' versus 'pass by
reference'. Both mislead in certain situations.
x = y+3
computes an object from 'y+3', looking up name 'y' in the current
namespaces, and associates the object with name 'x' in the current local
namespace. (This assumes the default situation with no 'global x' or
'nonlocal x' declarations.)
def f(x): return 2*x
f(y+3)
computes an object from 'y+3' looking up name 'y' in the current
namespaces, makes the local namespace of f the current local namespace,
and associates the object with the name 'x' in the new local namespace.
Toy? I think the first 'killer app' for Python was nuclear weapon
calculations at U.S. National Labs (Livermore and Los Alamos), where
numerical python started. The current version, numpy, along with scipy
and many other packages, is used throughout the sciences.
On the other hand, Python is the most fun language for most of us, so in
that sense it's a great toy. And I also think it a great replacement for
Basic.
M
Mitya Sirenef
I was referring to different indentation of the if block, not to braces
style. -m
M
Mitya Sirenef
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.
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.
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?
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.
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.
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
S
Steven D'Aprano
+1 QOTW
Well said. While Sun (now Oracle) have spent millions marketing Java, and
Microsoft done the same for C#, Python has got where it is almost
entirely on merit and word-of-mouth.
C
Chris Angelico
It's worth noting, though, that there are self-perpetuating aspects to
it. I can happily distribute a .py file to a Linux audience, because
many Linux distros come with a Python already installed, or at very
least can grab one easily via the package manager. No matter how
awesome Fred's Awesome Internet Language is, it's not going to be as
good a choice as something that people can simply 'apt-get install',
'yum install', or whatever they're most familiar with. I don't have
enough history with Python to know when that status began to be
achieved, nor how it happened, but I'd guess that exciting/interesting
a distro manager is different from being the best choice for writing
an application.
That said, though, Python is very good at both halves. But there might
very well be a language far superior for writing (say) a GUI app, that
just doesn't have the traction that Python does thanks to its
usefulness in the plumbing.
ChrisA