Why is Python like this?

[Wardog]

I've just completed a beginners course on Python coding.

I've passed it fine, and don't (currently) have any questions about how to do things. But (having used a number of other programming languages over the years) I do have a number of questions about why Python is designed to work in the way it does.

1) Indents. Why? Why is it beneficialy to do away with next/wend/loop until statements, and instead use indentation to mark the structure of loops?

2) Iterating loops. In BASIC (and equivilent code in all other languages I've used), this loop would repeat 10 times:
For i = 1 to 10
print i
Next

However, the Python equivilent:
for i in range(1,10):
print(i)

only repeats 9 times (the loop exits as soon as i reaches 10, rather than completing). What is the design reason for this? It seems counter-intuitive, and at odds with all other languages I've used.

3) Declaring variables. The first language I learned to program in (Locomotive BASIC) didn't require you to declare variables before using them. When I first encountered the requirement in other languages, I initially thought it was a waste of time, but soon learned that it was a useful way to a) make you think about what you need, b) make it clear to anyone looking at the code what variables are being used, and c) avoid errors due to typos.

As such, Python's design of (sort of) not requiring you to declare variables before using them seems a step back. And a rather strangely implemented one at that, as in a sense you do have to declare a variable (by assignin a value to it) before you modify it, and can change the type of a variable by assigning a different type of value to it.

4) More of a culture thing than a design question, but ever since you stopped having to use characters on the end of variable names to define their type (e.g. name$ for a string), all programming courses I've done have encouraged you to use a letter to indicate the type. E.g. iCount for an integer, sName for a string, etc). The Python course I took didn't follow this convention, and other Python training material I've looked at on the web didn't either.

Is this a Python thing, or a change in programming culture in general? And if so, why?

[gomipile]

1) Indenting loops has been a best practice since well before I took my first programming course in 1995. Enforcing it as syntax doesn't phase me, since I do it automatically anyway. The lack of unindented closing syntax for loops in Python does bother me, though.

2) One is generally expected to use the base form "for i in range(0,n):" where a loop starts at 0 and ends after n total steps. Yes, it makes the syntax look weird when one wants to start at 1 as in your code. I suppose it's to encourage young coders to start at 0 in their loops? It's a programming culture thing.

3) This is the way variable declarations worked in the first Microsoft BASIC versions that supported subroutines and other modern conveniences. QuickBASIC, for example. Lots and lots of people used to bang out quick calculation and simulation programs or other fast proof-of-concept code in QuickBASIC 4.5. I there is an overlap between QuickBASIC and/or Visual Basic's old user base and the creators and maintainers of Python.

4) I know what you're talking about here, but I have no clue why it's that way, either. /shrug

[factotum]

I'm not particularly familiar with Python, but my guesses on some of your questions:

1) It's an attempt by the language designers to force a level of readability into the language. You only have to look at some of the hugely obfuscated garbage that's legal C syntax to see why they did this.

2) Things like this aren't even consistent between different versions of BASIC. For example, if you declare an array in BASIC as number(10), some dialects will declare that as having 10 elements (1-10) and others will have 11 (0-10). In C, on the other hand, if you declare an array with 10 elements then you access those as 0-9. This probably explains why there are so many buffer overflow and bounds checking bugs in the world!

3) No idea on that one, I think it's generallly a good idea to declare variables before use anyway.

4) I was never taught to do that explicitly. In Windows programming it was customary to use "Hungarian notation" for variables (so a huge pointer to a zero-terminated string would have its name prefaced with hpsz), but this is entirely a cultural thing--there are probably Python teachers in the world who teach adding types to variable names. However, it might also be because of the rise of object-oriented languages--one of the main things about that is that you can have polymorphic types and types which inherit stuff from other types, so decoration becomes largely meaningless; after all, if I have a variable of type "bar" which is inherited from class "foo", how do I decorate that?

[jayem]

1)
It's a decision, but basically on anything sufficiently interesting, 95% of the time you need indentation to see what your doing anyway. Most of the time the indentation and brackets mismatching cause problems the indentation is more right. And why duplicate things.
2)
The mid point is the range also goes (1,2,3,4,5,6,7,8,9). I'm not quite sure why that is, but it's the same convention that is often used for arrays etc...
In many languages you also have variants of for(i=0;i<10;i++) which has the same pattern, so it's one you'd have to get used to.
3)
Part of that I think is to do with the history, python is a scripting language, and can also be used interactively. It's also made the deliberate decision that it doesn't care about what something is, so a significant portion of the time the declaration would just be that the thing exists. And that you can mess around quite deeply if you want and change things on the fly.
As you note many typos do actually get caught, it's only a problem when you assign to the wrong variable.

So basically it kind of shifts the balance, but does have the costs you mention.
(there's a bit of me that would like the option of having a more rigorous python flavour, that could perhaps be compiled deeper. But that may be naive of me)

4)
I guess the thing is there are now so many (virtual) types, that you'd need to have a whole word. And especially in python you often either don't care what it is but what it can do, or more generally if your writing something that long that you need to remember something else is wrong.

[Lacuna Caster]

3) Declaring variables. The first language I learned to program in (Locomotive BASIC) didn't require you to declare variables before using them. When I first encountered the requirement in other languages, I initially thought it was a waste of time, but soon learned that it was a useful way to a) make you think about what you need, b) make it clear to anyone looking at the code what variables are being used, and c) avoid errors due to typos.

As such, Python's design of (sort of) not requiring you to declare variables before using them seems a step back. And a rather strangely implemented one at that, as in a sense you do have to declare a variable (by assignin a value to it) before you modify it, and can change the type of a variable by assigning a different type of value to it.

Static vs. dynamic typing is one of the deep cultural and philosophical divides in programming, and I don't think I can give you a definite answer on this point. I'll just say that Python is optimised for minimising the amount of (keyboard) typing that you need to do, because that tends to be the main bottleneck on productivity for top-class programmers, so it doesn't include any syntax that isn't absolutely required to get the job done.

Optional typing in python is available, if you really want it.

The naming conventions that I think you're referring to sound similar to Hungarian Notiation, which I've never personally had much use for. Statically typed languages and modern IDEs will tell you the type of a variable anyway, and dynamically-typed languages treat the fungibility of data as an asset, not a drawback.

[Douglas]

4) More of a culture thing than a design question, but ever since you stopped having to use characters on the end of variable names to define their type (e.g. name$ for a string), all programming courses I've done have encouraged you to use a letter to indicate the type. E.g. iCount for an integer, sName for a string, etc). The Python course I took didn't follow this convention, and other Python training material I've looked at on the web didn't either.

Is this a Python thing, or a change in programming culture in general? And if so, why?

That practice originated as a terrible misinterpretation of a superficially similar good idea. Read up on Apps Hungarian notation, with more in depth information here.

[Wardog]

Thanks all.

On point 4 - I hadn't heard the term before, but it was "systems Hungarian" that I'd been encouraged to use - and I can see now why it is deprecated. That said, I have found it useful in the past when for example I've had two variables of different types where the shortest and most obvious name was the same for both. And arguably I can also see it being useful in Python specifically, given that you can e.g. inadvertantly turn a number into a string and then multiply it by another number.

On indentation - I know indenting is good practice for readability. Its really just (as gomipile says) that the lack of closing syntax seem weird, plus it breaks principle of "whitespace doesn't affect the code". Personally, I think "like Python, but with a loop end statement" would be the neatest and most intuitive solution - although I suppose that fact that Python manages without it proves its unnecessary, and there's no point in obliging you to use more lines than neccessary.

[Douglas]

Yeah, systems Hungarian is a lot more meaningful in languages that don't have ways built into the language to specify that a particular variable is a particular type (this is called "strong typing"). Weak typing is in my opinion a very bad idea, but it's unfortunately part of several widely used languages.

Humans make mistakes. Programmers are humans. The more capability a computer has to detect and point out those mistakes, the better. Strong typing is a very powerful tool for detecting and preventing some major categories of common mistakes, and leaving it out of a language makes that language much more prone to those kinds of mistakes.

On indentation - I know indenting is good practice for readability. Its really just (as gomipile says) that the lack of closing syntax seem weird, plus it breaks principle of "whitespace doesn't affect the code".

There's a language where whitespace IS the code.

On a more serious note, I think one of python's design goals was to be easy for beginning programmers to start using. For rather a lot of beginning programmers, "it makes the code more readable" is not a sufficiently convincing argument to get them to actually do it with any meaningful consistency. So, to force these beginners to get into the habit of doing proper indentation, they made it part of the language syntax so that the much stronger "it's required for the program to work" argument is available. Once these beginners learn the habit of good indentation, they'll bring that habit with them into other languages - properly indenting their own new code, but also reacting to bad indentation with "what is this unreadable mess?"

Also, leaving out the loop end marker makes the code shorter.

[FreddyNoNose]

I've just completed a beginners course on Python coding.

I've passed it fine, and don't (currently) have any questions about how to do things. But (having used a number of other programming languages over the years) I do have a number of questions about why Python is designed to work in the way it does.

1) Indents. Why? Why is it beneficialy to do away with next/wend/loop until statements, and instead use indentation to mark the structure of loops?

2) Iterating loops. In BASIC (and equivilent code in all other languages I've used), this loop would repeat 10 times:
For i = 1 to 10
print i
Next

However, the Python equivilent:
for i in range(1,10):
print(i)

only repeats 9 times (the loop exits as soon as i reaches 10, rather than completing). What is the design reason for this? It seems counter-intuitive, and at odds with all other languages I've used.

3) Declaring variables. The first language I learned to program in (Locomotive BASIC) didn't require you to declare variables before using them. When I first encountered the requirement in other languages, I initially thought it was a waste of time, but soon learned that it was a useful way to a) make you think about what you need, b) make it clear to anyone looking at the code what variables are being used, and c) avoid errors due to typos.

As such, Python's design of (sort of) not requiring you to declare variables before using them seems a step back. And a rather strangely implemented one at that, as in a sense you do have to declare a variable (by assignin a value to it) before you modify it, and can change the type of a variable by assigning a different type of value to it.

4) More of a culture thing than a design question, but ever since you stopped having to use characters on the end of variable names to define their type (e.g. name$ for a string), all programming courses I've done have encouraged you to use a letter to indicate the type. E.g. iCount for an integer, sName for a string, etc). The Python course I took didn't follow this convention, and other Python training material I've looked at on the web didn't either.

Is this a Python thing, or a change in programming culture in general? And if so, why?

Suppose you wanted python to be EXACTLY like some other language like say Java. The result would be that you have Java not Python. You just need to learn what the details are of this language. If you want to become a software developer, you just have to deal with it.

[Knaight]

There's a language where whitespace IS the code.

It's just this side of Malbolge in terms of being ridiculously aggravating too.

[Jasdoif]

2) Iterating loops. In BASIC (and equivilent code in all other languages I've used), this loop would repeat 10 times:
For i = 1 to 10
print i
Next

However, the Python equivilent:
for i in range(1,10):
print(i)

only repeats 9 times (the loop exits as soon as i reaches 10, rather than completing). What is the design reason for this? It seems counter-intuitive, and at odds with all other languages I've used.

It does make it consistent with slice notation. I mean, [:10] selects the first ten elements of an iterable, exactly like [0:10] would. range also only requires a single argument, so range(10) matching range(0,10) is consistent; and range(10) having ten elements makes sense if you're only interested in how many times you're running a loop.

3) Declaring variables. The first language I learned to program in (Locomotive BASIC) didn't require you to declare variables before using them. When I first encountered the requirement in other languages, I initially thought it was a waste of time, but soon learned that it was a useful way to a) make you think about what you need, b) make it clear to anyone looking at the code what variables are being used, and c) avoid errors due to typos.

As such, Python's design of (sort of) not requiring you to declare variables before using them seems a step back. And a rather strangely implemented one at that, as in a sense you do have to declare a variable (by assignin a value to it) before you modify it, and can change the type of a variable by assigning a different type of value to it.

4) More of a culture thing than a design question, but ever since you stopped having to use characters on the end of variable names to define their type (e.g. name$ for a string), all programming courses I've done have encouraged you to use a letter to indicate the type. E.g. iCount for an integer, sName for a string, etc). The Python course I took didn't follow this convention, and other Python training material I've looked at on the web didn't either.

Is this a Python thing, or a change in programming culture in general? And if so, why?

These sound like dynamic typing things. It is a little weird to get used to if you've started with a few decades' experience with static typed languages....


With most static typing languages, to use an attribute named "fancyThing" on a variable; the variable has to be of a type of a class that has an attribute named "fancyThing", and the object referenced by the variable has to be of that class in order for it to be assigned in the first place. That's why you normally need to declare a variable with a type: so the language knows what you're doing with the variable.

With Python, the object referenced by the variable needs to have an attribute named "fancyThing". That's it; there's no type dependency going on. Because of that, there's no sense or need for a variable to be defined with a type; and because of that, there's no substantial advantage to declaring a variable prior to using it...or for throwing a variable's type into its name. Trying to use a variable you haven't set a value to gives a clear error that the variable with the name isn't defined, and if you're mixing up your variables you...should probably consider how you're naming your variables.


This is without getting into the workarounds for workarounds for needing to accomplish these kind of things in statically typed languages....Like in .NET, you can define a collection to use an interface (basically a stub class with a set of method signatures, for different classes to override) so you can have completely different kinds of classes in there as long as they have that set of method names...which is fine for the most part, but does mean an object coming out of the collection has the interface as its type. So if the collection's the only way to get at an object, and you need to work with a method that isn't part of the interface, you have to cast the object back into its full type and into a variable with that type first. It's not hard, per se, but it's awfully tedious.

---

In Windows programming it was customary to use "Hungarian notation" for variables (so a huge pointer to a zero-terminated string would have its name prefaced with hpsz), but this is entirely a cultural thing--there are probably Python teachers in the world who teach adding types to variable names.

Even Microsoft's published coding standards discourage using Hungarian prefixes these days; I believe because it gets counterintuitive in a hurry if the type of the variable changes in the future.

[Lacuna Caster]

Humans make mistakes. Programmers are humans. The more capability a computer has to detect and point out those mistakes, the better. Strong typing is a very powerful tool for detecting and preventing some major categories of common mistakes, and leaving it out of a language makes that language much more prone to those kinds of mistakes.

Yes, but the solution to humans being error-prone is thorough automated testing. Do that and the problems associated with weak typing disappear. Don't, and strong typing will probably not save you.

[Douglas]

Yes, but the solution to humans being error-prone is thorough automated testing. Do that and the problems associated with weak typing disappear. Don't, and strong typing will probably not save you.

Thorough automated testing is another very powerful tool for detecting mistakes in programming, but it depends on human programmers thinking of - and implementing - a sufficiently comprehensive suite of tests. And again, humans make mistakes. A good test suite will catch most bugs. It hardly ever catches all bugs, every potential bug you want it to check for requires more work from the programmer, and there are usually potential (and actual) bugs that no one even thinks of to be able to consider checking for.

Preventing bugs in software is a job where defense in depth is called for. Language syntax requirements, compiler checks, static analysis tools, code reviews, automated tests, manual tests, and more. No single thing will prevent all bugs, but the more you have the fewer bugs will slip through.

Strong typing will catch a lot of bugs and, perhaps more importantly, it will do so extremely quickly with negligible effort while the programmer is still actively working on the code at the site of the bug. The longer it takes between a bug being written and it being detected, the more effort it takes to find, analyze, and fix. With modern IDEs underlining such errors in red while you type, a bug detected by strong typing is often found and fixed in seconds. Just about any other detection method will take orders of magnitude more time.

[Excession]

I've just completed a beginners course on Python coding.

I've passed it fine, and don't (currently) have any questions about how to do things. But (having used a number of other programming languages over the years) I do have a number of questions about why Python is designed to work in the way it does.

1) Indents. Why? Why is it beneficialy to do away with next/wend/loop until statements, and instead use indentation to mark the structure of loops?

Having a loop ending symbol increases the amount of text on the screen, without really adding any extra information. Readability was a big goal for the designer of Python, and as I understand it removing what he saw as unnecessary or overly long syntax is part of that.

2) Iterating loops. In BASIC (and equivilent code in all other languages I've used), this loop would repeat 10 times:
For i = 1 to 10
print i
Next

However, the Python equivilent:
for i in range(1,10):
print(i)

only repeats 9 times (the loop exits as soon as i reaches 10, rather than completing). What is the design reason for this? It seems counter-intuitive, and at odds with all other languages I've used.

The Python for loop is designed for looping over elements of a sequence. Simply incremented a number, without that number then being used for indexing a sequence, is not that common in real programs. The normal use for it is:

for thing in list_of_things:
    print thing

If you need the index as well, you do this:

for index, thing in enumerate(list_of_things):
    print index, thing

So the real question here is why "range" doesn't include the target value. As others have said, the behaviour is consistent with slicing and zero-based lists, and a few other things I can't remember off the top of my head.

3) Declaring variables. The first language I learned to program in (Locomotive BASIC) didn't require you to declare variables before using them. When I first encountered the requirement in other languages, I initially thought it was a waste of time, but soon learned that it was a useful way to a) make you think about what you need, b) make it clear to anyone looking at the code what variables are being used, and c) avoid errors due to typos.

As such, Python's design of (sort of) not requiring you to declare variables before using them seems a step back. And a rather strangely implemented one at that, as in a sense you do have to declare a variable (by assignin a value to it) before you modify it, and can change the type of a variable by assigning a different type of value to it.

Declaring variables was never about helping programmers, but about helping the compiler. With more modern compilers, lots of languages now require less manual declarations, letting you use "auto x = ..." in C++ for example, where the type is inferred from what is assigned to it. If the type of a variable isn't obvious to the reader from how it is used, you can and should add a comment explaining yourself. For function arguments you can also check the type manually if you need to:

def foo(a, b):
    assert isinstance(a, int), "First argument of foo should be an int"
    x = bar()  # a list of strings

Note that using isinstance has a downside. Requiring that an argument be of particular type stops someone from passing something that behaves the same but isn't exactly that type (called duck-typing) but can sometimes be useful to add internal consistency checks to code.

4) More of a culture thing than a design question, but ever since you stopped having to use characters on the end of variable names to define their type (e.g. name$ for a string), all programming courses I've done have encouraged you to use a letter to indicate the type. E.g. iCount for an integer, sName for a string, etc). The Python course I took didn't follow this convention, and other Python training material I've looked at on the web didn't either.

Is this a Python thing, or a change in programming culture in general? And if so, why?

As others have said, this practice isn't used much any more. Your variable names should be descriptive of what they're pointing to, but strict and hard to read rules like this aren't a great way to do it IMO. While "i" for int and "s" for string might be simple enough, when your types are CustomerOrderList and ComboOptionLimit or something the prefixes stop being useful.

Edit:

Thorough automated testing is another very powerful tool for detecting mistakes in programming, but it depends on human programmers thinking of - and implementing - a sufficiently comprehensive suite of tests. And again, humans make mistakes. A good test suite will catch most bugs. It hardly ever catches all bugs, every potential bug you want it to check for requires more work from the programmer, and there are usually potential (and actual) bugs that no one even thinks of to be able to consider checking for.

Preventing bugs in software is a job where defense in depth is called for. Language syntax requirements, compiler checks, static analysis tools, code reviews, automated tests, manual tests, and more. No single thing will prevent all bugs, but the more you have the fewer bugs will slip through.

Strong typing will catch a lot of bugs and, perhaps more importantly, it will do so extremely quickly with negligible effort while the programmer is still actively working on the code at the site of the bug. The longer it takes between a bug being written and it being detected, the more effort it takes to find, analyze, and fix. With modern IDEs underlining such errors in red while you type, a bug detected by strong typing is often found and fixed in seconds. Just about any other detection method will take orders of magnitude more time.

I'm not sure myself if declaring every type is "negligible effort", especially when the type is "boost::shared_ptr<std::vector<app::MyDescriptiveN ame>>". That type declaration is a lot to type and to read, and it gets in the way every single time you read that code. In my experience working in Python for years, using the wrong type isn't a common enough mistake to justify all that extra reading. Also, static typing only catches a limited subset of bugs, while automated testing catches far more. If you're writing the tests anyway, the type declarations just end up looking like a waste.

If static types are useful for error checking, why stop here? Why not use full "design by contract"?

I will also note that, for the people that want it, Python 3 did add an entirely optional system for checking the types of function arguments, similar in some ways to TypeScript. It's still run time checking, but IDEs can parse it too; they also parse "assert isinstance(x, ...)" just fine.

[Sermil]

I'm not sure myself if declaring every type is "negligible effort", especially when the type is "boost::shared_ptr<std::vector<app::MyDescriptiveN ame>>". That type declaration is a lot to type and to read, and it gets in the way every single time you read that code. In my experience working in Python for years, using the wrong type isn't a common enough mistake to justify all that extra reading. Also, static typing only catches a limited subset of bugs, while automated testing catches far more. If you're writing the tests anyway, the type declarations just end up looking like a waste.

Well, by that standard, you could just write "void *" everywhere in C. People moved away from that because it sometimes caused unexpected run-time failures that could have been caught at compile time if the types had been properly declared.

The problem with assuming unit tests will catch type errors is that often the wrong type can be passed into an API. The unit tests for the lower-level piece of code (say, a network reader) don't catch it because the bug is in the caller. The unit tests for the caller don't catch it because the network reader has to be mocked out to avoid relying on the network during unit tests.

That leaves integration tests, which are larger, more difficult to write and run, and often can't test many logic branches (for instance, a unit test with a simulated clock can simulate a network drop at a very precise, but an integration test would need to actually kill the reader of the network connection at the exact microsecond between one packet and the next to exercise a particular branch. In multi-threaded code, simulated reads with mutexes controlled by the test code can easy produce race conditions that only happen once in a million times in an integration test, and so on).

Defense-in-depth is the key. All methods of showing software is correct have holes in them. To produce reliable software, have as many layers as possible -- compile time checks, unit tests, integration tests, end-to-ends simulations, code reviews, design reviews, static analysis -- and hope the holes don't line up.

[Excession]

Well, by that standard, you could just write "void *" everywhere in C. People moved away from that because it sometimes caused unexpected run-time failures that could have been caught at compile time if the types had been properly declared.

Yes, in some ways that is what Python does, except that the type is actually "PyObject*". The difference is that Python checks things at run time, so instead of a hard to debug crash (or a security problem) I get an exception and traceback that often tells me exactly what went wrong without any more debugging.

The problem with assuming unit tests will catch type errors is that often the wrong type can be passed into an API. The unit tests for the lower-level piece of code (say, a network reader) don't catch it because the bug is in the caller. The unit tests for the caller don't catch it because the network reader has to be mocked out to avoid relying on the network during unit tests.

Your mocked network call should be checking the type, and value, of what was passed to it though. Here's a simple example in Python of mocking a system call (the relevant code fragment is below). If "os.remove" is called with the wrong type then the value won't be equal to "any path" and the test will fail. And it's not just the type that gets checked, but the exact string.

class RmTestCase(unittest.TestCase):
    @mock.patch('mymodule.os')
    def test_rm(self, mock_os):
        rm("any path")
        # test that rm called os.remove with the right parameters
        mock_os.remove.assert_called_with("any path")

I can only speak from my own experience, but I just don't find that passing the wrong type is something that slips through testing that much. The frameworks we use, including ones we have written ourselves, do include type and interface checking so errors will occur sooner rather than later, but only where we feel it helps.

Efficiency of programming is also key. If a layer of defence catches only a subset of likely errors, and yet incurs a heavy cost in programming time, it may not be worth it. If you're working in a statically typed language, you get it for free because the compiler needs those declarations anyway. Except with type inference creeping in that isn't quite true any more. Would you avoid using "auto" in C++ because you prefer to type out every type so they get checked?

[Anonymouswizard]

On a more serious note, I think one of python's design goals was to be easy for beginning programmers to start using. For rather a lot of beginning programmers, "it makes the code more readable" is not a sufficiently convincing argument to get them to actually do it with any meaningful consistency. So, to force these beginners to get into the habit of doing proper indentation, they made it part of the language syntax so that the much stronger "it's required for the program to work" argument is available. Once these beginners learn the habit of good indentation, they'll bring that habit with them into other languages - properly indenting their own new code, but also reacting to bad indentation with "what is this unreadable mess?"

This is true. I've been programming for five, six years now and I still have problems making completely readable codes, generally through lack of commenting. I learnt to compensate by making my variable and function names as transparent as possible.

I do most of my programming in Javascript these days and so I stick any operation I do in a function just in case I need to call back to it later, so this makes it easy, although back when I primarily used C/C++ (not learnt how to do objects in C++ yet because the person teaching at university didn't seem to want to teach them) it was much harder to deal with it because I'd often have my main function as a confusing mess of control code. I also didn't bother using indentation until I started using a program that automated it for me, now I literally can't stop myself from using it.

On loops, 'check at start of loop' and 'check at end of loop' are generally options in most programming languages I've encountered, in C the first would be While or For loops while the latter would be Do-While loops (and maybe Do-For, I prefer using While loops because I find them easier to read, I've never checked). I remember having a lot of fun learning how to use loops properly and how to break them (I like infinite loops surrounding my progra), it was a brainwave when I realised a single function could have multiple Return statements.

[Leewei]

I'm a big fan of Python. It really is a breath of fresh air to use. Here's my take on the first 3 questions. Number 4 was answered definitively by Douglas.

1) In nearly every other language, the indentation is a human convention, while the syntax that governs program behavior is either key words such as BEGIN / END, or else some form of parenthesis - {} / (). Since humans are creating the code, indentation is a very elegant way to structure the code, since it enforces the code running exactly as it looks like it should to a human user. There is no possibility for ambiguous code behavior where something is indented one way, yet executed another. It also enforces the good programming practice of proper indentation.

2) This is certainly confusing at first. Something to keep in mind is that the Range type isn't required in a ForLoop. You can also use other types with iterators such as Lists (like [1, 2, 3]).

3) I agree. Some explicit typing in a Python declaration would be useful for preventing errors such as accidental additional name creation due to typo. Presumably some of this is addressed by extensive use of classes.

[wumpus]

1. I've always claimed that Python's indentation scheme is obviously the correct way to do things. If you indent your code in other (non-whitespace dependent) code you have the risk of the human following the indentation and the computer following the semicolons. In this case you need to run through a formating program to make sure the indentation is correct, or you could just use a scheme like Python. Allowing "incorrect" indentation is always a danger. Much of the complaints come from old geezers who remember FORTRAN and its bad use of whitespace (actually use of whitespace was tied to punchcards. FORTRAN is *old*).

2. I wouldn't use BASIC of an example of how good languages work. Also, range is typically used range(10) and naturally starts with 0 and loops 10 times.

3. Declaring variables. As mentioned, variables were originally declared for use by the compiler and not anything else [see below how FORTRAN didn't need declarations unless you were declaring a variable with the "wrong" starting letter]. There seems to be a specific movement (see ADA) that moved from the original K&R C from pretty much letting the programmer see an int as a "bag of bits" (like assembler, a language it was designed to replace for system software) and more towards a specific number not to be directly used as a pointer.

"Duck typing" was an obvious goal of creating python. Not only do the variables receive a "natural" type, they can have operations with other types and behave in a natural way. The real difference in Python is not that you don't have to explicitly give variables a type, but that you don't have to cast the variable every time you want to use it as an operand for a different type of use in an operation that accepts more than one type of variable.

I'd also note that I'm invariably "declaring" lists by "list_variable=[]" because I tend to use loops and list_variable.append() a lot. So I'm not quite convinced I save much time at all not declaring variables in Python.

I'll have to look into the "type" module. As the size of a python program grows, the less of an advantage it is to allow variables to freely mutate their type. I've had killer bugs that popped up because somewhere in my program a variable (or even class) changed its type to something I didn't want. I expect this also becomes a problem as the size of teams increase as well.

4. That is more of a coding style. As a one-time FORTRAN geezer, the old joke went "god is real, unless declared integer" [yes I learned FORTRAN when the punchcard use of whitespace was enforced, no the computer didn't use the card reader anymore (but it might have been hooked up for all I know)]. The first letter in FORTRAN determined the type of variable (this must have started back when only ints and reals existed), probably to allow FORTRAN compilers to ignore variable names after a few characters (yes, this was a thing back in the day). I'd be fairly shocked if modern compilers/interpreters allowed this type of thing.

[jayem]

1. I've always claimed that Python's indentation scheme is obviously the correct way to do things. If you indent your code in other (non-whitespace dependent) code you have the risk of the human following the indentation and the computer following the semicolons. In this case you need to run through a formating program to make sure the indentation is correct, or you could just use a scheme like Python. Allowing "incorrect" indentation is always a danger. Much of the complaints come from old geezers who remember FORTRAN and its bad use of whitespace (actually use of whitespace was tied to punchcards. FORTRAN is *old*).

There is a bit of a potential for confusion between tabs and spaces. In most cases this is much more easily resolved than the equivalent braces chase, where the actual problem is never where it's reported. But on occasion in can be a pain.

With C++ in particular I find the typing creates as many problems as it resolves. However this is normally an issue with resolving dependencies. By the time you've got things sorted, things aren't right, and normally it then takes ages to find get it to the point where you find the whole set-up is fundamentally backward from what you actually use. To be honest by that point on anything interesting there's normally plenty of opportunities for horrendous bugs to slip in over the typing (e.g. null pointers, lost references and pointers).

In Java by contrast the definitions are much more conveniently placed. Again on a sufficiently interesting project you suddenly find you need a property you thought you could ignore 5 calls back.

Python, you've discovered and fixed those bugs, and are rewriting it with the basis of experience.

It almost certainly does shift a bit in collaborative products and where aims are well defined before hand. I'm not sure how often that actually is ...

[NichG]

I use Python almost exclusively now, and it's a very hot/cold thing. Out of any language I've used, Python seems to attract libraries with the lowest boilerplate requirements before you can get them up and doing what you actually wanted them for. So rather than having to know the correct (and always the same) 20 lines of code to initialize the library, allocate memory, etc, etc, you can have three or four line programs that do fairly sophisticated tasks.

As far as I can tell, this feature of Python has absolutely nothing to do with the design decision to treat whitespace as code, which I absolutely loathe and which has cost me hours of debugging to find exactly which tab was silently replaced by 3 spaces by some text editor or copy-paste operation or whatever. It's especially bad for copying code from e.g. an email or website, which even if you preserve formatting correctly can throw an error in Python 3 if the code from the website was using three spaces but your code uses four spaces, or something like that.

But outside of that, I find the loose typing to be very useful in practice for things like data processing, where the community standard to cluster around NumPy means that you can generally interchangeably process a list or image or audio file as if it were a matrix or tensor without needing explicit inter-conversion steps along the way. Coming from C where a program doing, say, linear regression on fused features from images and audio taken from a video file would be 98% preprocessing and format conversion code, it's refreshing.

[Sermil]

Efficiency of programming is also key. If a layer of defence catches only a subset of likely errors, and yet incurs a heavy cost in programming time, it may not be worth it. If you're working in a statically typed language, you get it for free because the compiler needs those declarations anyway. Except with type inference creeping in that isn't quite true any more. Would you avoid using "auto" in C++ because you prefer to type out every type so they get checked?

I use "auto" all the time, but it's checked at compile-time, not run-time. There's no chance that using 'auto' will cause a run-time error.

[Douglas]

I use "auto" all the time, but it's checked at compile-time, not run-time. There's no chance that using 'auto' will cause a run-time error.

I use "var", the C# equivalent, if and only if it is obvious from immediately local context what the type is. Oh, and only if it actually does meaningfully shorten something - I don't replace "int" with "var" even when it is obvious.

[Rockphed]

I use Python almost exclusively now, and it's a very hot/cold thing. Out of any language I've used, Python seems to attract libraries with the lowest boilerplate requirements before you can get them up and doing what you actually wanted them for. So rather than having to know the correct (and always the same) 20 lines of code to initialize the library, allocate memory, etc, etc, you can have three or four line programs that do fairly sophisticated tasks.

As far as I can tell, this feature of Python has absolutely nothing to do with the design decision to treat whitespace as code, which I absolutely loathe and which has cost me hours of debugging to find exactly which tab was silently replaced by 3 spaces by some text editor or copy-paste operation or whatever. It's especially bad for copying code from e.g. an email or website, which even if you preserve formatting correctly can throw an error in Python 3 if the code from the website was using three spaces but your code uses four spaces, or something like that.

But outside of that, I find the loose typing to be very useful in practice for things like data processing, where the community standard to cluster around NumPy means that you can generally interchangeably process a list or image or audio file as if it were a matrix or tensor without needing explicit inter-conversion steps along the way. Coming from C where a program doing, say, linear regression on fused features from images and audio taken from a video file would be 98% preprocessing and format conversion code, it's refreshing.

Over the summer I did some work with Python. I still ended up with 80% of my code being pre-processing and post processing, but that was partially because the data was not in the format I wanted (so I had to write a program to put it in the format I wanted) and the format I could work on it in was not the same as the format I wanted out (which was the same as the format I got in), so I had to write about 50 lines of code to go each way. The whitespace-is-code thing is probably my least favorite thing about Python. Python is therefore my second favorite scripting language (after Matlab which doesn't do whitespace-as-code).

[wumpus]

Over the summer I did some work with Python. I still ended up with 80% of my code being pre-processing and post processing, but that was partially because the data was not in the format I wanted (so I had to write a program to put it in the format I wanted) and the format I could work on it in was not the same as the format I wanted out (which was the same as the format I got in), so I had to write about 50 lines of code to go each way. The whitespace-is-code thing is probably my least favorite thing about Python. Python is therefore my second favorite scripting language (after Matlab which doesn't do whitespace-as-code).

Was it python3? Where "bytes" an effective type to work? Back when Python 3 first came out, I had a lot of code that used strings as streams of binary data. When most of my code was useless with the then-new "bytes" type, I quickly ignored it and went back to Python 2 (while I was using unicode for all my text, the only strings my code needed to operate on where binary, so python 3 could only provide issues with libraries (the compatibility advantage is starting to swing toward python 3 now, years later).

The early versions of Python 3 left me completely unable to use "bytes" for anything but converting to and from text. Unlike the "duck typing" I was used to, bytes seemed to invoke "platypus typing". I hope it has been fixed.

[Rockphed]

Was it python3? Were "bytes" an effective type to work? Back when Python 3 first came out, I had a lot of code that used strings as streams of binary data. When most of my code was useless with the then-new "bytes" type, I quickly ignored it and went back to Python 2 (while I was using unicode for all my text, the only strings my code needed to operate on were binary, so python 3 could only provide issues with libraries (the compatibility advantage is starting to swing toward python 3 now, years later).

The early versions of Python 3 left me completely unable to use "bytes" for anything but converting to and from text. Unlike the "duck typing" I was used to, bytes seemed to invoke "platypus typing". I hope it has been fixed.

Python 2.7 actually. No, it was a library that had itself a proprietary data structure that was a pain to reshape in to the shape I wanted.

[pendell]

Aside not related to Python, but in Java and C# Hungarian notation is now considered an anti-pattern. For two reasons:

1) HN is all very well if you're writing in a text editor , but if you're using a modern IDE such as Eclipse or Visual Studio or IntelliJ, finding out the type of an object is as quick as hovering over it with your mouse.

So not only is Hungarian Notation redundant, it can be actively harmful if the type of the variable gets changed by the maintenance programmer without also changing the name; this happens more often than you might think. In this case it becomes misleading, and so actively harmful.

2) If you have polymorphism or some other OO device in use, Hungarian Notation can, again, make it more difficult to implement or change.

This is why Google, in its style guide, Explicitly and actively forbids its use . It was a very useful thing in the 80s and 90s since overtaken by technological change.

This little snippet from How to write unmaintainable code describes Hungarian notation thus:

Hungarian Notation

Hungarian Notation is the tactical nuclear weapon of source code obfuscation techniques; use it! Due to the sheer volume of source code contaminated by this idiom nothing can kill a maintenance engineer faster than a well planned Hungarian Notation attack. The following tips will help you corrupt the original intent of Hungarian Notation:

* Insist on using "c" for const in C++ and other languages that directly enforce the const-ness of a variable.

* Seek out and use Hungarian warts that have meaning in languages other than your current language. For example insist on the PowerBuilder "l_" and "a_ " {local and argument} scoping prefixes and always use the VB-esque style of having a Hungarian wart for every control type when coding to C++. Try to stay ignorant of the fact that megs of plainly visible MFC source code does not use Hungarian warts for control types.

* Always violate the Hungarian principle that the most commonly used variables should carry the least extra information around with them. Achieve this end through the techniques outlined above and by insisting that each class type have a custom wart prefix. Never allow anyone to remind you that no wart tells you that something is a class. The importance of this rule cannot be overstated: if you fail to adhere to its principles the source code may become flooded with shorter variable names that have a higher vowel/consonant ratio. In the worst case scenario this can lead to a full collapse of obfuscation and the spontaneous reappearance of English Notation in code!

* Flagrantly violate the Hungarian-esque concept that function parameters and other high visibility symbols must be given meaningful names, but that Hungarian type warts all by themselves make excellent temporary variable names.

* Insist on carrying outright orthogonal information in your Hungarian warts. Consider this real world example: "a_crszkvc30LastNameCol". It took a team of maintenance engineers nearly 3 days to figure out that this whopper variable name described a const, reference, function argument that was holding information from a database column of type Varchar[30] named "LastName" which was part of the table’s primary key. When properly combined with the principle that "all variables should be public" this technique has the power to render thousands of lines of source code obsolete instantly!


*Use to your advantage the principle that the human brain can only hold 7 pieces of information concurrently. For example code written to the above standard has the following properties:

a single assignment statement carries 14 pieces of type and name information.

a single function call that passes three parameters and assigns a result carries 29 pieces of type and name information.

Seek to improve this excellent, but far too concise, standard. Impress management and coworkers by recommending a 5 letter day of the week prefix to help isolate code written on ‘Monam’ and ‘FriPM’.

It is easy to overwhelm the short term memory with even a moderately complex nesting structure, especially when the maintenance programmer can’t see the start and end of each block on screen simultaneously.

Respectfully,

Brian P.

[Avilan the Grey]

I've only poked a little with a stick at Python.

Regarding loops though... If I remember correctly most languages go "N steps from 0". I recall a habit I have had many times of, for my own sake (easier to keep track of) doing a X= (insert loop syntax here) "1 to 11" or for that matter when not practical instead adding an extra row (add loop syntax here) N = 0 to 10, X = N+1.
Just to make it easier for me to remember that X (or N) is indeed a number between 1 and 10.

[Finlam]

From my limited experience, a programmer's fondness for Python directly correlates to the IDE they use when first introduced.

I, personally, prefer NPP and the good ole fashioned command window, but lately Sublime has been growing on me (it's fairly easy to turn on show whitespace in either). Then again, I am a bit weird.

The strength of Python is its readability: the whole point of the white-space as code is to force readable/meaningful indentation into the code. This is not the be-all-end-all of code readability, but it is an important aspect and it helps.

Of course, snake casing instead of camel casing increases readability significantly as well. *Ducks under a table*

[Knaight]

From my limited experience, a programmer's fondness for Python directly correlates to the IDE they use when first introduced.

Out of curiosity, what does your limited experience say about that first IDE being Matlab (which is also a language)?