Python Language Annoyances

[mouser]

the importance of declaration for readability's sake.

I should have said in my original post why implicit variable declaration is such an incredibly bad idea -- it's not an issue of readability, it's much more fundamental and important.

Surely there must be a witty concise design principle term that covers this issue, but i can't recall what it might be so i'll just try to describe it as best as i can:

When writing code, there are a huge number of ways to make mistakes.  No one writes perfect code all the time every time.

When an error in your code triggers a syntax error, or a fatal runtime error or exception -- the problem is often trivial to identify and correct.

The bugs that keep you awake all night (or all week or all month in some nightmare scenarios) are those that do NOT cause a program-halting error, but whose effects are only seen indirectly, and happen silently, in some mystery location in your code, far away from the source of the problem.

The reason that requiring explicit variable declaration (keep in mind we aren't talking about static typing now, i.e. saying what kind of data the variable holds; we are just talking about declaring that you are going to be using a variable named xyz) is so important, is that it is an immense safeguard and aid in locating a particularly common and hard to otherwise identify bugs.

Forcing the programmer to explicitly declare variable names that are going to be used is important because it allows the language to flag as errors any occasion where the programmer misspells a variable (or uses a variable name outside of its lifetime scope, etc.).

This happens frequently.  And without a requirement for explicit variable declaration, instead what happens is that the program often marches on using invalid data without any sign that something is wrong -- leaving the programmer to try to figure out why the values being computed are not correct.

[wraith808]

Well, when we get to the basics of why I agree that implicit variable declarations are a bad thing, at the root of the problem we have the corollary that variables are never explicitly typed.  There is a belief floating around that implicit typing makes programming easier to do and learn, and I can say from my experience with my brother-in-law and his voyage into the programming world that this just isn't true.

In order to explain why the following Python code is bad to a beginner you still have to explain the concept of types:

Code: Python [Select]

1. >>> x = 12
2. >>> y = "13"
3. >>> x + y
4. TypeError: cannot concatenate 'str' and 'int' objects

The error message is hard for a new programmer to understand because str and int aren't tangible. Also, when I'm helping him debug his Python programs, accidental type conversions is one of the most common error I see him make (the second being the indentation problem).  It's quite annoying to have to track these down by first running the program, and having to test every single corner of the code. Static typing eliminates the need for type testing.

In the end I see absolutely no advantage circumventing the few keystrokes it takes to explicitly write:

Code: C# [Select]

1. string x = "12";
2. int y = 13;

Now when the programmer writes: x + y the inevitable type-error message that results is no longer something cryptic.

In the relatively rare case a programmer truly needs a variant type, it is easy enough to just use something like variant or object.

If I had it all to do over again, I'm not sure whether I'd pick to teach him Python as a first language.  I'm not sure if the short-term benefits outweigh the long term handicaps.

I found this argument against implicit type declarations, and I have to say it's better written than anything I could have done: http://bit.ly/abVONc

[mouser]

Excellent link -- that page does a very good job of explaining why implicit variable declaration is a bad idea, and has some good links of its own.

Direct link again: http://blog.dev-scen...riable-declarations/

Let's just make sure we don't make the situation more confusing with your example above.  There are two similar but *not* identical issues raised in your example, the first is about requiring explicit declaration of variables, and the second is about static typing of variables.

Roughly speaking (there is some fuzzyness and refinement in the language community), this is explicit declaration without static typing:

[Select]

var x = "12";
var y = 13;

This is explicit static typing:

[Select]

string x = "12";
int y = 13;

I'd argue that the first case, explicit variable declaration, should be taught in language design 101, and there is no excuse for EVER allowing implicit variable declaration.

The case of static vs. dynamic typing is much, much more debatable -- and much easier to make a case for the value of dynamic typing (or it's variations) in many cases.

[mouser]

From the link above also comes a mention of this nice article on Good vs Bad Redundancy in programming languages:
http://dobbscodetalk...s.html&Itemid=29

A good redundancy detects faults by having two independent paths to the same result. A failure in one path does not affect the other, so the discrepancy in result indicates an error.  A bad redundancy is distinguished by either not providing a checkable result, or by having the redundant paths dependent on each other in such a way that an error in one path propagates to the other, so the wrong results agree.

[vixay]

I think the issue is like one poster said meta-programming. Like the list below, moving up you move to a higher level of abstraction and higher level of programming. So some of your gripes about hiding details, old syntax ...etc is necessary. The higher you go the less you care about the implementation in the layers below.

English/Ideas/Abstract concepts/thought
Frameworks/Django/...etc
Python/Javascript
C++
C
Assembly

I frankly can't wait until we get to the ' just express an idea, and poof program done' stage .
What debuggers/compilers/run-time checking do is give feedback on your ideas, about feasibility, errors ...etc, which is what they should continue doing. I'd rather have computers working harder, than people, as resource wise people are more expensive

some other valid comparisons were, newbie to programming's introduction to python experience is different, compared to an experienced programmer learning it.

Anyway I just learn python from diveintopython a couple of weeks ago, and since then i've used it to solve a couple of puzzles, and I had fun... The old style program was like this:

[Select]

##def hours12():
##    #using loops
##    li = []
##    for h in range(1,13):
##        for m in range(60):
##            li.append('%02d%02d' %(h, m))
##    return li
##
##def hours12_b(): # this version is faster
##    #using list comprehension
##    return ['%02d%02d' %(h, m) for h in range(1,13) for m in range(60)]
##
##def duplicates(li):
##    li2 = []
##    for t in li:
##        dup = 0
##        old_d = t[0]
##        for d in t[1:]:
##            if d == old_d:
##                dup += 1
##            elif 0 < dup < 2:
##                dup = 0 #reset duplicate count if non consecutive duplicates found
##            old_d = d
##               
##        if dup >= 2:
##            # print t, dup
##            li2.append(t)
##    #print len(li2)
##    return li2
##
##import re
##repattern = re.compile(r'(\d)\1{2}')
##
##def duplicates_b(li):
##    li2 = []
##    # print 'testing regular expressions for matching duplicates'
##    for el in li:
##        result = repattern.search(el)
##        if result:
##            li2.append(el)
##            # print result.group()
##    #print len(li2)
##    return li2
##
##def duplicates_c(li): #this version is fastest
##    li2 = filter(repattern.search, li)
##    #print len(li2)
##    #return [x.group() for x in li2]
##    return li2
##
##import timeit
##li = hours12_b()
##
##ta = timeit.Timer('digits_in_clock.duplicates(digits_in_clock.li)','import digits_in_clock')
##tb = timeit.Timer('digits_in_clock.duplicates_b(digits_in_clock.li)','import digits_in_clock')
##tc = timeit.Timer('digits_in_clock.duplicates_c(digits_in_clock.li)','import digits_in_clock')
##print 'a dup method', ta.repeat(1,1000)
##print 'b dup method', tb.repeat(1,1000)
##print 'c dup method', tc.repeat(1,1000)
####li2 = duplicates(li)
####print li2
####li2 = duplicates_b(li)
####print li2

and the python way in the end was like this

[Select]

import re
repattern = re.compile(r'(\d)\1{2}')#find a number followed by 2 consecutive duplicates
# the \1 is for first number that we match
li = ['%02d%02d' %(h, m)
      for h in range(1,13)
      for m in range(60)]
li2 = filter(repattern.search, li)
print li2
print len(li2)

Frankly I like the list comprehension idea, and how intuitive and simple python makes it.

[Armando]

I just read the 2 linked articles above and really liked them. Thanks !

Apart from the good summary on the importance of good redundancy, here's an excerpts I particularly liked... in relation to "implicit variable declaration":

[...] when you’re designing an interface for programmers, even yourself, the real important thing suddenly becomes “How can I prevent the programmer from messing up?”. It’s like designing any interface, the weakest link is always the human factor. Even if it’s the best programmer in the world, a highly unreliable computer will still make that human look like a giant pile of shoddy engineering. So it’s your job, as the language/interface/API designer, to do whatever you can to minimize that risk of programmer error.
Another way to think of the issue is in terms of “good redundancy versus bad redundancy”. [...] Walter Bright explains it best:
“[...] since the compiler can figure the need for declarations from the context, [variable] declarations seem like prime redundancies that can be jettisoned. This is called implicit variable declaration. It sounds like a great idea, and it gets regularly enshrined into new languages. The problem is, the compiler cannot tell the difference between an intended new declaration and a typo - and the poor maintenance programmer can’t tell, either. After a while, though, the lesson about redundancy is learned anew, and a special switch will be added to require explicit declaration.”

-Abscissa's Page

(My emphasis)