Re: Without compilation, how to find bugs?

[sohcahtoa82]

On Friday, October 14, 2016 at 5:46:14 AM UTC-7, Steve D'Aprano wrote:
> On Fri, 14 Oct 2016 08:04 pm, BartC wrote:
> 
> > On 14/10/2016 01:59, sohcahto...@gmail.com wrote:
> >> On Thursday, October 13, 2016 at 4:06:36 PM UTC-7, pozz wrote:
> > 
> >>> Are the things exactly how I understood, or do I miss something in
> >>> Python?
> >>
> >> As others have said, user a linter.
> > 
> > With Python you're supposed to just be able run any source code
> > instantly; how will using a 'lint' tool impact that process? Or is it
> > only meant to be used infrequently?
> 
> The process is little different between C and Python:
> 
> With C: during development, you run the compiler (which includes built-in
> static analysis) or stand-alone linter, and optionally any tests you have,
> etc. The deployed software rarely if ever includes static analysis.
> 
> With Python: during development, you optionally run linters, static
> analysis, tests, etc. After deployment, you rarely run static tests,
> linting, etc.
> 
> 
> >> I'd go a step further and use an actual code editor or IDE that includes
> >> some basic static analysis.  Using this example that Skip used:
> >>
> >> def func2(a, b):
> >> print(a, b)
> >>
> >> def func1(a):
> >> print(a)
> >>
> >> func2(1)
> >>
> >> Any code editor worth using will highlight the ) on the last line and
> >> tell you that there's a missing parameter.
> 
> That's a matter of opinion.
> 

Fair enough.  vi/vim is a popular editor for writing code, but I personally 
can't stand them.

Of course, that's another subject entirely.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Without compilation, how to find bugs?

[sohcahtoa82]

On Friday, October 14, 2016 at 2:05:01 AM UTC-7, BartC wrote:
> On 14/10/2016 01:59, sohcahto...@gmail.com wrote:
> > On Thursday, October 13, 2016 at 4:06:36 PM UTC-7, pozz wrote:
> 
> >> Are the things exactly how I understood, or do I miss something in Python?
> >
> > As others have said, user a linter.
> 
> With Python you're supposed to just be able run any source code 
> instantly; how will using a 'lint' tool impact that process? Or is it 
> only meant to be used infrequently?

I'm not the person to ask about lint usage in Python.  I don't use a linter.  I 
just use the static analysis built into my IDE.

> 
> > I'd go a step further and use an actual code editor or IDE that includes 
> > some basic static analysis.  Using this example that Skip used:
> >
> > def func2(a, b):
> > print(a, b)
> >
> > def func1(a):
> > print(a)
> >
> > func2(1)
> >
> > Any code editor worth using will highlight the ) on the last line and tell 
> > you that there's a missing parameter.
> 
> How can that work? I thought one of the biggest deals with Python is 
> that you can re-bind function names to anything else. So:
> 
> if cond:
>  func2 = 38
> else:
>  func2 = func1
> 
> Then func2(1) can either be perfectly correct, or completely erroneous!
> 
> (I have my own suspicions that functions in Python are predominantly 
> used in a boring, predictable, static manner (so allowing certain 
> optimisations - or error checking), but I got the impression from some 
> threads here that many apparently do little else in their code but bind 
> and rebind function names.)
> 
> -- 
> Bartc

If you don't know if a variable is an integer or a function, then you've got 
other problems.  That just doesn't look like clean code.

And yes, I know, Python doesn't have "variables", but rather objects bound to 
names, or names bound to objects, or however you want to say it, the idea is 
similar.

Back on track, in the case you mentioned, my IDE does not flag any errors.  
Even if I do this:

def func(y):
return y

x = 0
if x:
f = 1
else:
f = func

f(0)

My IDE highlights the f(0) line and says that f is not callable.  Obviously 
it's wrong, but that just shows that my IDE's static analysis has its limits.

(For the record, my IDE is PyCharm 2.7.3, which I know is HORRENDOUSLY out of 
data, but it's what I'm stick with at work for now)

Anyways...if at any point in the execution of a program there's uncertainty 
whether a name could be bound to an integer OR a function, that seems like a 
code smell, especially when it's name looks like a function.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Without compilation, how to find bugs?

[breamoreboy]

On Friday, October 14, 2016 at 12:06:36 AM UTC+1, pozz wrote:
> I come from the C language, that is a compiled and strongly typed 
> language.

Python is compiled and dynamically and strongly typed but C is compiled and 
statically and weakly typed.

> 
> All the tricks have a common goal: to discover bugs as soon as possible, 
> mostly during compilation process. Indeed I usually find some bugs 
> during compilation (or static analysis). It seems to me very important.

As others have all ready mentioned there are plenty of static analysis tools 
for Python.

> 
> Now I'm learning Python and it appears to me very simple, but at the 
> same time highly dangerous. For example, I can write a function that 
> accepts two arguments and call it with only one argument. I can execute 
> the script without any problem and I will not notice the bug until I 
> test exactly the erroneous line of code (the call with only one argument).

On the other hand some errors occur far less frequently in Python than in C, 
for example off-by-one, or the memory management being done for you.

> 
> However, I think the language interpreter could emit the error before 
> launching the script even without executing the wrong instruction, 
> because it perfectly knows how many arguments the function wants and 
> that one instruction calls it with a wrong number of arguments.
> 
> Are the things exactly how I understood, or do I miss something in Python?

You've missed plenty but please stick with it, you'll learn :)

Kindest regards.

Mark Lawrence.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Without compilation, how to find bugs?

[Steve D'Aprano]

On Fri, 14 Oct 2016 08:04 pm, BartC wrote:

> On 14/10/2016 01:59, sohcahto...@gmail.com wrote:
>> On Thursday, October 13, 2016 at 4:06:36 PM UTC-7, pozz wrote:
> 
>>> Are the things exactly how I understood, or do I miss something in
>>> Python?
>>
>> As others have said, user a linter.
> 
> With Python you're supposed to just be able run any source code
> instantly; how will using a 'lint' tool impact that process? Or is it
> only meant to be used infrequently?

The process is little different between C and Python:

With C: during development, you run the compiler (which includes built-in
static analysis) or stand-alone linter, and optionally any tests you have,
etc. The deployed software rarely if ever includes static analysis.

With Python: during development, you optionally run linters, static
analysis, tests, etc. After deployment, you rarely run static tests,
linting, etc.


>> I'd go a step further and use an actual code editor or IDE that includes
>> some basic static analysis.  Using this example that Skip used:
>>
>> def func2(a, b):
>> print(a, b)
>>
>> def func1(a):
>> print(a)
>>
>> func2(1)
>>
>> Any code editor worth using will highlight the ) on the last line and
>> tell you that there's a missing parameter.

That's a matter of opinion.



> How can that work? I thought one of the biggest deals with Python is
> that you can re-bind function names to anything else. So:
> 
> if cond:
>  func2 = 38
> else:
>  func2 = func1
> 
> Then func2(1) can either be perfectly correct, or completely erroneous!

Of course. Unless the compiler can perform full-program analysis and rule
out the possibility that func2(1) has been rebound to something that will
accept a single argument, it cannot reject that code. The design principle
here is that anything which isn't provably wrong should be allowed, in case
the programmer knows better than the compiler.

A corollary of this is that most (all?) existing Python compilers are quite
simple-minded and naive. As has been pointed out, even the most obviously
wrong code:

x = 1 + "2"

is not rejected until runtime. Why not? You'd have to ask Guido for a
ruling, but I think he would say:

- he's not interested in making static analysis part of the language
specification;

- as far as the CPython reference implementation is concerned, he thinks it
is a waste of time and effort to do such static analysis in the compiler/
interpreter;

- but third-party tools (linters, IDEs, code checkers, etc) or compilers are
welcome to do so if they choose.

(I stress that I don't *know* this is what Guido will say, I'm just
guessing.)

As external tools, linters and IDEs etc aren't constrained by that strict
rule "never reject code that isn't provably wrong". They are permitted to
make a reasonable guess. They are only giving optional warnings which
indicate something which *might* be incorrect.


> (I have my own suspicions that functions in Python are predominantly
> used in a boring, predictable, static manner (so allowing certain
> optimisations - or error checking), 

Indeed. I have a vague memory of somebody actually doing a survey of some
large code base, and finding that (excluding decorators, which technically
perform a rebinding) something like 98% or more of functions and classes
were used in a boring, static manner.

But of course, that's partly a matter of convention and coding styles. Some
code bases are written in a boring, static manner because the corporate
style prohibits dynamic rebinding of functions.


> but I got the impression from some 
> threads here that many apparently do little else in their code but bind
> and rebind function names.)

Heh, everybody loves to talk about the most extreme forms of Python
dynamicism, but hardly anyone uses them often. But they are used, just
enough to rule out banning them.

You may be interested in some work being done by one of the core developers.
One of the features of Python that keeps it relatively slow is that
function calls are resolved at runtime: calling len(x) has to do a runtime
search for the name "len" before calling it. Victor Stinner is working on
run-time optimizations which can detect when it is safe to replace that
run-time search with a compile-time static call.

That's also one of the future optimizations Nuitika is looking at.

And of course PyPy does a similar thing, except as just-in-time compilation
rather than ahead-of-time.



 

-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Without compilation, how to find bugs?

[Chris Angelico]

On Fri, Oct 14, 2016 at 8:04 PM, BartC  wrote:
> On 14/10/2016 01:59, sohcahto...@gmail.com wrote:
>>
>> On Thursday, October 13, 2016 at 4:06:36 PM UTC-7, pozz wrote:
>
>
>>> Are the things exactly how I understood, or do I miss something in
>>> Python?
>>
>>
>> As others have said, user a linter.
>
>
> With Python you're supposed to just be able run any source code instantly;
> how will using a 'lint' tool impact that process? Or is it only meant to be
> used infrequently?
>

In any serious project (in any language), you should have unit tests.
Python doesn't force you to run those every time you build - nor does
C, nor does any other language. It's up to you how often you run your
tests. Linters are basically just heuristic testing systems - less
precise, but more general. Type checkers in Python are the same.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Without compilation, how to find bugs?

[BartC]

On 14/10/2016 01:59, sohcahto...@gmail.com wrote:

On Thursday, October 13, 2016 at 4:06:36 PM UTC-7, pozz wrote:



Are the things exactly how I understood, or do I miss something in Python?


As others have said, user a linter.


With Python you're supposed to just be able run any source code 
instantly; how will using a 'lint' tool impact that process? Or is it 
only meant to be used infrequently?



I'd go a step further and use an actual code editor or IDE that includes some 
basic static analysis.  Using this example that Skip used:

def func2(a, b):
print(a, b)

def func1(a):
print(a)

func2(1)

Any code editor worth using will highlight the ) on the last line and tell you 
that there's a missing parameter.


How can that work? I thought one of the biggest deals with Python is 
that you can re-bind function names to anything else. So:


if cond:
func2 = 38
else:
func2 = func1

Then func2(1) can either be perfectly correct, or completely erroneous!

(I have my own suspicions that functions in Python are predominantly 
used in a boring, predictable, static manner (so allowing certain 
optimisations - or error checking), but I got the impression from some 
threads here that many apparently do little else in their code but bind 
and rebind function names.)


--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Without compilation, how to find bugs?

[Marko Rauhamaa]

pozz :

> All the tricks have a common goal: to discover bugs as soon as possible,
> mostly during compilation process. Indeed I usually find some bugs
> during compilation (or static analysis). It seems to me very important.

Yes, it can be very useful, and with Python, you sacrifice that.

> I will not notice the bug until I test exactly the erroneous line of
> code (the call with only one argument).

Everything must be tested anyway, and even that may not be enough.
Recently, I was guilty of an atrocious buffer overflow in C. It wasn't
caught by the compiler or testing -- during the test run, the stack
happened to contain a series of zeros.

> Are the things exactly how I understood, or do I miss something in
> Python?

What you don't yet appreciate is how Python adds to program quality.
With its concise, high-level constructs, you end up expressing more with
far less code and far less boilerplate. Your code is far easier to get
right, and you can put together more complicated solutions that are
still robust.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Without compilation, how to find bugs?

[sohcahtoa82]

On Thursday, October 13, 2016 at 4:06:36 PM UTC-7, pozz wrote:
> I come from the C language, that is a compiled and strongly typed 
> language.  I learned many good tricks to write good code in C: choose a 
> coding style, turn on as many warnings as possible, explicitly declare 
> static variables and functions (when needed), explicitly declare const 
> variables (if the piece of code will not change them), explicitly 
> declare all the functions, and so on.
> 
> All the tricks have a common goal: to discover bugs as soon as possible, 
> mostly during compilation process. Indeed I usually find some bugs 
> during compilation (or static analysis). It seems to me very important.
> 
> Now I'm learning Python and it appears to me very simple, but at the 
> same time highly dangerous. For example, I can write a function that 
> accepts two arguments and call it with only one argument. I can execute 
> the script without any problem and I will not notice the bug until I 
> test exactly the erroneous line of code (the call with only one argument).
> 
> However, I think the language interpreter could emit the error before 
> launching the script even without executing the wrong instruction, 
> because it perfectly knows how many arguments the function wants and 
> that one instruction calls it with a wrong number of arguments.
> 
> Are the things exactly how I understood, or do I miss something in Python?

As others have said, user a linter.

I'd go a step further and use an actual code editor or IDE that includes some 
basic static analysis.  Using this example that Skip used:

def func2(a, b): 
print(a, b) 

def func1(a): 
print(a) 

func2(1)

Any code editor worth using will highlight the ) on the last line and tell you 
that there's a missing parameter.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Without compilation, how to find bugs?

[Skip Montanaro]

One other thing. The OP mentioned coming from C. If you are old enough, you
will remember that many errors caught by gcc and other modern compilers
used to be detected by external checkers like lint. Most Makefiles had
"lint" targets in them.

So although you might associate all sorts of error detection and reporting
with the compiler, there is no particular reason it must be there.

Skip
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Without compilation, how to find bugs?

[Irmen de Jong]

On 14-10-2016 1:07, pozz wrote:
> All the tricks have a common goal: to discover bugs as soon as possible, 
> mostly during
> compilation process. Indeed I usually find some bugs during compilation (or 
> static
> analysis). It seems to me very important.

I wanted to reply a bit more to this paragraph as well.

I agree that finding bugs as soon as possible is nice, but the thing to keep in 
mind is
that the kind of bugs you find during compilation are almost always syntactic 
errors,
typos or other simple mistakes. I think semantic and logic errors are usually 
the ones
that have the biggest impact and take by far the most time to debug and fix. 
These bugs
mostly cannot be detected by compilers anyway. A syntactically valid program 
can do
something completely bogus (and almost always does because humans make mistakes 
when
designing and building it)

In my personal experience I find that I make a lot LESS syntactic errors and 
simple
mistakes in Python than in other languages. Mostly because Python produces very 
clear
and concise programs when compared to other languages (especially languages as 
low level
as C).  A function of 30 lines in Python has a lot less chance to have a bug 
than an
equivalent function that requires 300 lines to write elsewhere.

Bottom line: >I< don't really need static compiler checks when working in 
Python.  I do
miss them sometimes when refactoring stuff, but that's where a solid unit test 
suite
comes to the rescue.


Irmen

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Without compilation, how to find bugs?

[Ben Finney]

pozz  writes:

> All the tricks have a common goal: to discover bugs as soon as
> possible, mostly during compilation process. Indeed I usually find
> some bugs during compilation (or static analysis). It seems to me very
> important.

Do you also use static code analysis? Do you find that static code
analysis finds many types of bugs that compilation could not find?

Do you always write use unit tests for the code you write? For the
existing code you change? Do you specify the unit tests so that they
each assert one specific thing about the function's behaviour, and fail
unambiguously when that's not the observed behaviour?

Do you aim for complete unit test coverage of all branches in your code?
Do you treat un-covered code as dangerously unpredictable code?

If your answer is “no” to any of those, I think you may have a good
answer to your overall question :-)

-- 
 \   “A poet can survive everything but a misprint.” —Oscar Wilde, |
  `\   _The Children of the Poets_, 1886-10-14 |
_o__)  |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Without compilation, how to find bugs?

[Irmen de Jong]

On 14-10-2016 1:07, pozz wrote:
> I come from the C language, that is a compiled and strongly typed language. 

C is far from a strongly typed language, IMO...
You can convert (cast) almost anything to anything else without compiler errors.
Have a a float? Ah yes no I mean treat it as a pointer to a function taking a 
char*
instead. Things can blow up majorly at runtime (segfault or worse)
Python is much more strongly typed than this. You can never do something to an 
object
that is not defined in its interface, and an object is always exactly known to 
be of one
particular type.

Perhaps you're thinking about statically typed versus dynamically typed?

> I learned
> many good tricks to write good code in C: choose a coding style, turn on as 
> many
> warnings as possible, explicitly declare static variables and functions (when 
> needed),
> explicitly declare const variables (if the piece of code will not change 
> them),
> explicitly declare all the functions, and so on.
> 
> All the tricks have a common goal: to discover bugs as soon as possible, 
> mostly during
> compilation process. Indeed I usually find some bugs during compilation (or 
> static
> analysis). It seems to me very important.
> 
> Now I'm learning Python and it appears to me very simple, but at the same 
> time highly
> dangerous. For example, I can write a function that accepts two arguments and 
> call it
> with only one argument. I can execute the script without any problem and I 
> will not
> notice the bug until I test exactly the erroneous line of code (the call with 
> only one
> argument).
> 
> However, I think the language interpreter could emit the error before 
> launching the
> script even without executing the wrong instruction, because it perfectly 
> knows how many
> arguments the function wants and that one instruction calls it with a wrong 
> number of
> arguments.
> 
> Are the things exactly how I understood, or do I miss something in Python?

Python is a *very* dynamic language so static checks are usually extremely hard 
to do.
Recent IDEs and tools (checkers, linters) have made some progress though, and 
type hints
have been added to the language recently to support this.

The biggie I think is that in the Python world the concept of *unit tests* is an
extremely important one. That is (I feel) the major tool being used to not only 
find
existing bugs, but also to avoid introducing new ones while changing the 
program.

Something which I believe you need everywhere else as well, regardless of 
programming
language. Proper unit testing (and testing in general) is much more powerful 
than
placing a lot of trust in the compiler.


Irmen

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Without compilation, how to find bugs?

[Grant Edwards]

On 2016-10-13, pozz  wrote:

> However, I think the language interpreter could emit the error before 
> launching the script even without executing the wrong instruction, 
> because it perfectly knows how many arguments the function wants and 
> that one instruction calls it with a wrong number of arguments.
>
> Are the things exactly how I understood, or do I miss something in Python?

Python is a dynamic language, and it turns out it's very difficult to
know for sure, using static code analysis, at compiler time, what
function a name is going to be bound to at any particular point at run
time.

That said, there is pylint which does try to do as much static error
checking as possible.



-- 
Grant





-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Without compilation, how to find bugs?

[Skip Montanaro]

> I can execute the script without any problem and I will not notice the
bug until I
> test exactly the erroneous line of code (the call with only one argument).

The key phrase there being "until I test..."  There are static
analysis tools for Python like pylint. Given this simple module:

#!/usr/bin/env python

def func2(a, b):
print(a, b)

def func1(a):
print(a)

func2(1)

among other messages, pylint prints:

E:  9, 0: No value for argument 'b' in function call
(no-value-for-parameter)

where line 9 is the erroneous call to func2().

Static analysis tools like pylint aren't perfect, but do catch a bunch of
stuff. Also, given the run-time detection of errors, in dynamic languages
like Python, unit tests and code coverage are particularly important. Also,
check out type hints, mypy, and the typeshed project:

https://www.python.org/dev/peps/pep-0484/
http://mypy-lang.org/
https://github.com/python/typeshed

Skip
-- 
https://mail.python.org/mailman/listinfo/python-list

Without compilation, how to find bugs?

[pozz]

I come from the C language, that is a compiled and strongly typed 
language.  I learned many good tricks to write good code in C: choose a 
coding style, turn on as many warnings as possible, explicitly declare 
static variables and functions (when needed), explicitly declare const 
variables (if the piece of code will not change them), explicitly 
declare all the functions, and so on.


All the tricks have a common goal: to discover bugs as soon as possible, 
mostly during compilation process. Indeed I usually find some bugs 
during compilation (or static analysis). It seems to me very important.


Now I'm learning Python and it appears to me very simple, but at the 
same time highly dangerous. For example, I can write a function that 
accepts two arguments and call it with only one argument. I can execute 
the script without any problem and I will not notice the bug until I 
test exactly the erroneous line of code (the call with only one argument).


However, I think the language interpreter could emit the error before 
launching the script even without executing the wrong instruction, 
because it perfectly knows how many arguments the function wants and 
that one instruction calls it with a wrong number of arguments.


Are the things exactly how I understood, or do I miss something in Python?
--
https://mail.python.org/mailman/listinfo/python-list