Re: Newbie : checking semantics
[EMAIL PROTECTED] (Bengt Richter) writes: [block end statements] Training wheels do no belong as a permanent part of a bicycle, Yes, but they would be useful for example in web programming (embedding Python into HTML), too. So they are not only training wheels. But that's not so important. What Python got really wrong is mixing binding and assignment (because this way you have little chance to catch typos in identifiers). -- Stefan. -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie : checking semantics
Op 2005-05-16, Bengt Richter schreef [EMAIL PROTECTED]: On Mon, 16 May 2005 18:40:43 +0200, Stefan Nobis [EMAIL PROTECTED] wrote: rbt [EMAIL PROTECTED] writes: 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. Training wheels do no belong as a permanent part of a bicycle, IMO. But what is a training wheel depends on your point of view. IMO the required indentation is more like permanent training wheels than end block-markers would be. A structure in general has a begin marker and an end marker. Even python has them in some cases like lists and tuples. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie : checking semantics
Dennis Lee Bieber [EMAIL PROTECTED] writes: 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 -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie : checking semantics
LDD [EMAIL PROTECTED] writes: 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... :) -- Stefan. -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie : checking semantics
Stefan Nobis wrote:
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
[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
Re: Newbie : checking semantics
Andrew Dalke wrote:
Stefan Nobis wrote:
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
[EMAIL PROTECTED]
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.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Newbie : checking semantics
Andrew Dalke [EMAIL PROTECTED] writes: 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie : checking semantics
rbt [EMAIL PROTECTED] writes: 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. -- Stefan. -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie : checking semantics
Stefan Nobis wrote: rbt [EMAIL PROTECTED] writes: 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. 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. 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie : checking semantics
Stefan Nobis wrote: 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. I also taught a beginning programming course. I found that the hard thing was learning the concept of an algorithm. I don't recall people getting confused over the indentation part that much. Python's block indentation is derived from ABC. ABC did various human factors studies to test how to make a language easier to use by beginning programmers. Combining that with my own experience both using and teaching the language make me distrustful of anyone else's evidence based only on anecdotal accounts. Leaving out the easy of learning aspect, there are two other reasons for the indentation: http://python.fyxm.net/doc/essays/foreword.html ] Perhaps Python's most controversial feature is its use of indentation ] for statement grouping, which derives directly from ABC. It is one of ] the language's features that is dearest to my heart. It makes Python ] code more readable in two ways. First, the use of indentation reduces ] visual clutter and makes programs shorter, thus reducing the attention ] span needed to take in a basic unit of code. Second, it allows the ] programmer less freedom in formatting, thereby enabling a more uniform ] style, which makes it easier to read someone else's code. 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). See the program pindent.py in the Python distribution under Tools/scripts # This file contains a class and a main program that perform three # related (though complimentary) formatting operations on Python # programs. When called as pindent -c, it takes a valid Python # program as input and outputs a version augmented with block-closing # comments. When called as pindent -d, it assumes its input is a # Python program with block-closing comments and outputs a commentless # version. When called as pindent -r it assumes its input is a # Python program with block-closing comments but with its indentation # messed up, and outputs a properly indented version. # A block-closing comment is a comment of the form '# end keyword' # where keyword is the keyword that opened the block. If the # opening keyword is 'def' or 'class', the function or class name may # be repeated in the block-closing comment as well. Here is an # example of a program fully augmented with block-closing comments: # def foobar(a, b): #if a == b: #a = a+1 #elif a b: #b = b-1 #if b a: a = a-1 ## end if #else: #print 'oops!' ## end if # # end def foobar Andrew [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie : checking semantics
Andrew Dalke [EMAIL PROTECTED] writes: See the program pindent.py Thanks for the hint, i didn't know about it. -- Stefan. -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie : checking semantics
On Mon, 16 May 2005 18:40:43 +0200, Stefan Nobis [EMAIL PROTECTED] wrote: rbt [EMAIL PROTECTED] writes: 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. Training wheels do no belong as a permanent part of a bicycle, IMO. If you want to show newbies Python code with block bracketing, please program up a suitable code viewer for them ;-) Regards, Bengt Richter -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie : checking semantics
[EMAIL PROTECTED] wrote: snip 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 KR 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie : checking semantics
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie : checking semantics
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie : checking semantics
On 8 May 2005 02:59:22 -0700, LDD [EMAIL PROTECTED] wrote: 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 -- http://mail.python.org/mailman/listinfo/python-list
Newbie : checking semantics
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie : checking semantics
On Sat, 07 May 2005 15:05:20 -0700, LDD wrote: 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie : checking semantics
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie : checking semantics
LDD [EMAIL PROTECTED] writes: 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. -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie : checking semantics
On 7 May 2005 15:05:20 -0700, LDD [EMAIL PROTECTED] wrote: 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie : checking semantics
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie : checking semantics
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 :) -- http://mail.python.org/mailman/listinfo/python-list
