Newbie : checking semantics

[LDD]

Hi everyone,

I am new to python and was very enthustic about its possibilities when
I discover that python is really what it is : just a scripting
language.

What disappoints me is that pyton will happily accept and execute this
code :

if ( aConditionThatIsFalse ):
AFunctionThatIsntDefined()

print "Hello world"

The fact that python doesn't check if the symbol
AFunctionThatIsntDefined is defined, is really bad when you develop big
pieces of code. You will never be sure that your code is free of this
kind of dummy errors and testing every possible execution paths is
nightmarish !

Is there a way to force Python to check the definition of symbol ?

LDD

 

[Jeremy Bowers]

The fact that python doesn't check if the symbol
AFunctionThatIsntDefined is defined, is really bad when you develop big
pieces of code. You will never be sure that your code is free of this
kind of dummy errors and testing every possible execution paths is
nightmarish !

Your unsubstantiated claim flies in the face of many man-years of
experience writing Python programs... and also has been discussed here so
many times it's hardly possible to count them.

Summary: We know better, from experience. Quote dogma until you're blue in
the face, but nobody has managed to prove that large Python apps don't
exist, nor have they been able to show they were harder to write than
equivalent apps in more structured languages, which is also a tough sell
since they were easier.

To win this point, you need to produce evidence that doesn't exist.

Why not try opening your mind to the possibility that the dogma is wrong?

Points to ponder:

http://www.mindview.net/WebLog/log-0025
http://www.artima.com/weblogs/viewpost.jsp?thread=4639

The other point worth making is that if you want a language that you
already know, why not stick with it?

Is there a way to force Python to check the definition of symbol ?

Look up "pychecker", but beyond that, no. It turns out such a thing is
meaningless in the sense you are used to (static analysis), because a
symbol may not have a referent until much later, and based on arbitrary
code. Python is late-binding, unlike C/C++/Java and friends.

I think that about summarizes the current state of the art on this point.

 

[wittempj]

I do not know of a check like the one you desire. But you always can
use some clever testing, e.g. facilitated with the unittest module to
prevent situations like yours, see
http://docs.python.org/lib/module-unittest.html

 

[Mike Meyer]

I am new to python and was very enthustic about its possibilities when
I discover that python is really what it is : just a scripting
language.

That "just" covers a *very* big application space. So-called scripting
languages are being used in an ever-widening variety of ways.

The fact that python doesn't check if the symbol
AFunctionThatIsntDefined is defined, is really bad when you develop big
pieces of code. You will never be sure that your code is free of this
kind of dummy errors and testing every possible execution paths is
nightmarish !

Testing every possible execution path may be nighmarish, but it's a
*requirement* for writing robust software. This is true whether
undefined variables are caught at compile time, execution time, or
later(*). You're never sure your code is free of bugs no matter what
you do, but adequate testing can help eliminate most of the dummy
ones. Failure to do that testing will ensure the presence of dummy
bugs in the code if you're developing a big piece of code, no matter
when they are detected.

Personally, I'm neutral on this issue. Clearly, declaring variables
saves time by catching such typos early. Equally clearly, not
declaring the variables saves time in that you don't have to enter the
declarations. While most RAD languages don't use variable
declarations, there are a number of factors that contribute to them
being faster than conventional languages, so the individual
contribution of this particular factor is unclear.

<mike

*) There are languages out there that quietly plug in a default value
when you reference an unassigned variable. That means the bug doesn't
show up until you start checking output values, at which point you
find garbage. Adequate testing will uncover these bugs, but finding
the actual bug is a PITA.

 

[Bengt Richter]

Hi everyone,

I am new to python and was very enthustic about its possibilities when
I discover that python is really what it is : just a scripting
language. Not "just."

What disappoints me is that pyton will happily accept and execute this
code :

if ( aConditionThatIsFalse ):
AFunctionThatIsntDefined()

print "Hello world"

The fact that python doesn't check if the symbol
AFunctionThatIsntDefined is defined, is really bad when you develop big
pieces of code. You will never be sure that your code is free of this
kind of dummy errors and testing every possible execution paths is
nightmarish !

If you aren't going to test your functions, how will you know they don't
have dummy errors??

Is there a way to force Python to check the definition of symbol ?

If _are_ going to test your functions, how long will it take to discover that
a function doesn't exist?

IOW, do you mean that if you know a function is defined, you will assume
it is free of dummy errors? Such faith ;-)

Regards,
Bengt Richter

 

[George Sakkis]

What disappoints me is that pyton will happily accept and execute
this

code :

if ( aConditionThatIsFalse ):
AFunctionThatIsntDefined()

print "Hello world"

The fact that python doesn't check if the symbol
AFunctionThatIsntDefined is defined, is really bad when you develop big
pieces of code. You will never be sure that your code is free of this
kind of dummy errors and testing every possible execution paths is
nightmarish !

You're absolutely right. Any real language should catch these types of
errors, just as it would verify that the program below is correct:


if (aCondition):
AFunctionThatIsDefined()
..
..
..
..
def AFunctionThatIsDefined():
return 0 / (0-0)


Moral: There are *many* more reasons for testing every execution path
than catching name or type errors.

George

 

[elbertlev]

I am new to python and was very enthustic about its possibilities
when

I discover that python is really what it is : just a scripting
language. .......
The fact that python doesn't check if the symbol ... is defined, is

really bad ...

1. For a language like Python full static checking is IMPOSSIBLE.
Consider setattr() with attribute name read from a file (f.e. names of
the "columns" in the database).

2. Trust me (and other Python programmers most likely would agree) this
type of error happens much more seldom then newbies (especially coming
from strongly typed languages) imagine while adjusting to the language.

3. Python advantages "overpower" drawbacks 10 to 1.

4. Most likely you never used Fortran

 

[John Machin]

Hi everyone,

I am new to python and was very enthustic about its possibilities when
I discover that python is really what it is : just a scripting
language.

What disappoints me is that pyton will happily accept and execute this
code :

if ( aConditionThatIsFalse ):
AFunctionThatIsntDefined()

print "Hello world"

and will happily and correctly print "Hello world" ... what's your
beef? You have tested one part of your program. Now, go away and test
the remainder of your program!

The fact that python doesn't check if the symbol
AFunctionThatIsntDefined is defined, is really bad

It does check, when you dereference the symbol.

If that dismays you, what about this:

def func1(argfunc):
argfunc()

or, a real practical example: reading a flat file with columnar data,
each column may need some conversion or data-fixing depending on its
type etc.

fixed_row = []
i = -1
for x in input_row:
i += 1
fixed_row.append([conv_func(x))

The dynamic nature of Python -- and there's a whole lot more than
functions (and methods) being first-class-citizen data objects --
allows much more code to be written faster cleaner fat-free and allow
more time for writing tests.

when you develop big
pieces of code. You will never be sure that your code is free of this
kind of dummy errors and testing every possible execution paths is
nightmarish !

What about
AFunctionThatIsDefinedButIsBuggyAndInsteadOfOrderingInPizzaLaunchesAPremptiveMissileStrike()

It is a nightmare, isn't it? If you are employed by a firm that makes
things like avionics, railway signalling equipment, or heart
pacemakers, would you please let us know the brand(s)?

Is there a way to force Python to check the definition of symbol ?

No. However you may use pychecker to pick up the spelling mistakes and
a whole lot more besides.

 

[LDD]

Be reassured, I'm not working in any business related to pacemakers,
avionics or railway signalling equipement ...

I'm just a guy who is learning Python because to me it seems to be the
best alternative to Perl, and trying to know what it is fit for.

 

[LDD]

To win this point, you need to produce evidence that doesn't exist.

I was not trying to win any point when I put my naive question on this
forum.
I'm just learning Python and trying to know what it is best made for.

So far I've learnt that Python is lazy about tyche-checking, it is
dynamic by nature and that there are areas which those qualities are
well fit for.

Still, I'm happy to learn that pychecker exists and helps you find
spelling mistakes that otherwise you would have found at execution time

 

[Bengt Richter]

Be reassured, I'm not working in any business related to pacemakers,
avionics or railway signalling equipement ...

I'm just a guy who is learning Python because to me it seems to be the
best alternative to Perl, and trying to know what it is fit for.

I see you as being in a place where they give away all kinds
of musical instruments for free, and I hear you saying you
want to know what they are "fit" for ;-)

Regards,
Bengt Richter

 

[beliavsky]

(e-mail address removed) wrote:

2. Trust me (and other Python programmers most likely would agree) this
type of error happens much more seldom then newbies (especially coming
from strongly typed languages) imagine while adjusting to the language.

3. Python advantages "overpower" drawbacks 10 to 1.

4. Most likely you never used Fortran

The Newbie is outnumbered on this issue in comp.lang.python, but he is
not alone . In Fortran 77 and earlier versions, many run-time errors
resulted from

(1) misspelling a variable name, since variable declarations were not
required and IMPLICIT NONE (forcing declarations) was standardized only
in Fortran 90.

(2) passing variables of the wrong type (real instead of double
precision, scalar instead of array, etc.) to a procedure -- this could
not be checked at compile-time if the procedure and caller were
compiled separately and then linked. Fortran 90 added MODULEs, partly
to fix this.

I programmed in Fortran 77 for years before using Fortran 90 and find
that in the latter version I am more productive, since a program that
compiled was much more likely to be correct. I think many Fortranners
concur.

ANSI C 89 provides for more static type checking than the original K&R
C, and I think most C programmers appreciate this.

Looking at how other programming languages evolved, based on hard-won
experience, Python looks like a move in the opposite direction -- less
"compile-time" checking.

 

[Dennis Lee Bieber]

Looking at how other programming languages evolved, based on hard-won
experience, Python looks like a move in the opposite direction -- less
"compile-time" checking.

OTOH, less "'compile-time' checking" is required. FORTRAN, C,
similar languages, are so tied to the hardware that, for example,
passing an integer to a routine that expects a double-precision real
could, theoretically, result in a run-time memory access violation or
otherwise overwrite other data. Python passes reference to objects that,
internally, know what memory is theirs to work with.

Or the infamous, and maybe urban legend, of the early FORTRAN
compiler in which literal constants weren't...

call inc(1)
write(6, 100) 1
100 format("I5")
.....

subroutine inc(i)
i = i + 1
return

.... would print " 2"

--

 

[Mike Meyer]

Or the infamous, and maybe urban legend, of the early FORTRAN
compiler in which literal constants weren't...

call inc(1)
write(6, 100) 1
100 format("I5")
....

subroutine inc(i)
i = i + 1
return

... would print " 2"

It's not an urban legend. I used to sit in a booth and answer student
programmers questions at a university, and saw this bug more than once
from people learning FORTRAN on an IBM 370.

<mike

 

[Stefan Nobis]

The fact that python doesn't check if the symbol
AFunctionThatIsntDefined is defined, is really bad when you
develop big pieces of code.

Yes, that's one of my two points, that i think are misfeatures in
Python, too. The problem is, that Python don't distinguish between
defining/binding a variable and setting a value (for example in
contrast to Lisp, where binding and setting are two separate
operations (namley let and setq)).

The other point is a missing (optional) statement to end blocks
(so you optional don't have to mark block via whitespace). IMHO
this comes very handy in some cases (like mixing Python and HTML
like in PSP). From my experience i also would say beginners have
quite some problems with only whitespace marking blocks (but it
also has some benefits). So i'm not as sure about this as the
above point.

BTW: I would also appreciate a nicer syntax for classes (no
explicit self, no masses of _). But that's another story...

 

[Andrew Dalke]

The other point is a missing (optional) statement to end blocks
(so you optional don't have to mark block via whitespace). IMHO
this comes very handy in some cases (like mixing Python and HTML
like in PSP). From my experience i also would say beginners have
quite some problems with only whitespace marking blocks (but it
also has some benefits).

When you say "beginners" is that people with no previous
programming experience or those who have done C/Java/etc. language
which uses {}s?


Andrew
(e-mail address removed)

 

[rbt]

When you say "beginners" is that people with no previous
programming experience or those who have done C/Java/etc. language
which uses {}s?


Andrew
(e-mail address removed)

True beginners (no programming experience whatsoever) don't have to deal
with unlearning stuff such as the bracket plague. So, I'd say that he's
talking about beginners who have used other languages and who have grown
accustomed to the bracket plague.

 

[Stefan Nobis]

When you say "beginners" is that people with no previous
programming experience

From time to time I teach some programming (in an institution
called "Volkshochschule" here in Germany -- inexpensive courses
for adults). My Python course is for absolute beginners with no
previous programming experience of any kind.

And yes, this people have quite some difficulties to get their
blocks indented right. Before Python I used C++ in this beginner
course and at least setting the boundaries for blocks was a little
less of a problem.

So I would appreciate optional statements to end a block
(indentation rules may be mandatory). This comes also very handy
in something like Python Server Pages of mod_python (where a
comment line to explicitly end a block is sometimes needed).

 

[Stefan Nobis]

True beginners (no programming experience whatsoever) don't have
to deal with unlearning stuff such as the bracket plague.

That's true. But they also not very used to give nothing (->
whitespace) a meaning. I teached quite some beginners and most of
them had problems to get the indentation right.

At least in the very beginning IMHO it would be useful to
explicitly end a block with some kind of an end statement.

Meaningful whitespache is not a big problem (as many people seems
to think) but it's also not very obvious and sometimes it causes
at least a little bit trouble.

 

[rbt]

That's true. But they also not very used to give nothing (->
whitespace) a meaning. I teached quite some beginners and most of
them had problems to get the indentation right.

At least in the very beginning IMHO it would be useful to
explicitly end a block with some kind of an end statement.

You have a very good point. Understanding the flow of a program and the
indentation or brackets that go with logical blocks of code would be
difficult for those who have never had to think like a programmer before
to grasp.

Have you read the book titled, "How to think like a Computer Scientist"?
It's very good for true beginners and it's free. It uses Python too.
It's good at teaching scope and how to recognize blocks of code.