annoying behavior

[Elbert Lev]

Re: annoying behavior

Michael Hoffman <m.h.3.9.1.with out.dots.at.cam .ac.uk@example. com> wrote in message news:<cjcqao$ji 0$1@gemini.csx. cam.ac.uk>...[color=blue]
> Elbert Lev wrote:
>[color=green]
> > I think, it would be good, if some sort of warning is given during
> > import, but not during instantiating the instance of the class. At
> > least in a "debug" mode. What really did happen: the bug was reported
> > after the scrip was running for 30 minutes. PyCheck finds it
> > immediatelly. Why not to do the same kind of check in the interpreter?[/color]
>
> Can you post the results of your PyChecker run and the exact input to it?
>
> I just did a test myself:
>
> """
> $ cat test1.py
> class X(object):
> def __init__(self):
> self.f()
> self.r = True
>
> def f(self):
> print self.r
>
> def main():
> x = X()
>
> $ pychecker test1.py
> Processing test1...
>
> Warnings...
>
> test1.py:10: Local variable (x) not used
> """
>
> I think that what you want the Python compiler to do is harder than you
> think it is, and not all cases will be caught unless you actually run
> the program.
>
> I've forgotten to assign attributes and variables before using them in
> the past--it's just something you have to learn not to do.[/color]

Here it is:

Processing test...
C:\Python23\pyt hon.exe
C:\Python23\Lib \site-packages\pychec ker\checker.py
test.py
Caught exception importing module test:
File "C:\Python23\Li b\site-packages\pychec ker\checker.py" , line
576, in setupMainCode()
module = imp.load_module (self.moduleNam e, file, filename, smt)
File "test.py", line 16
f = foo("1234")
File "test.py", line 5, in __init__()
self.f()
File "test.py", line 9, in f()
if self.r:
AttributeError: foo instance has no attribute 'r'

Warnings...

test:1: NOT PROCESSED UNABLE TO IMPORT
[color=blue]
> I think that what you want the Python compiler to do is harder than you
> think it is, and not all cases will be caught unless you actually run
> the program.[/color]

Sure not all! I tell you more: in many cases after the program was
used for years, it contains errors. This does not stop people debuging
them :) Even if check does not finds all errors it will be very good.
Isn't this what Python is about - fast and fun programming, not
frustration. After all, if I want troubles, I always can use C or Java
:))

[Michael Hoffman]

Re: annoying behavior

Elbert Lev wrote:[color=blue]
> Michael Hoffman <m.h.3.9.1.with out.dots.at.cam .ac.uk@example. com> wrote in message news:<cjcqao$ji 0$1@gemini.csx. cam.ac.uk>...
>[color=green]
>>Can you post the results of your PyChecker run and the exact input to it?[/color]
>
> Here it is:
>
> Processing test...
> C:\Python23\pyt hon.exe
> C:\Python23\Lib \site-packages\pychec ker\checker.py
> test.py
> Caught exception importing module test:
> File "C:\Python23\Li b\site-packages\pychec ker\checker.py" , line
> 576, in setupMainCode()
> module = imp.load_module (self.moduleNam e, file, filename, smt)
> File "test.py", line 16
> f = foo("1234")
> File "test.py", line 5, in __init__()
> self.f()
> File "test.py", line 9, in f()
> if self.r:
> AttributeError: foo instance has no attribute 'r'
>
> Warnings...
>
> test:1: NOT PROCESSED UNABLE TO IMPORT
>[color=green]
>>I think that what you want the Python compiler to do is harder than you
>>think it is, and not all cases will be caught unless you actually run
>>the program.[/color][/color]

If you noticed from the output, PyChecker is testing your testcase by
actually *running the code.* If you just ran python test.py you would
have found the error just as quickly. If you ran PyChecker on my
testcase, or the original code that caused you problems (I'm guessing)
you wouldn't have found it.
[color=blue]
> Sure not all![/color]

How would you propose an algorithm that will find the majority of these
cases without running the code? I am claiming that this is nontrivial;
you are claiming that it is not, so you should provide an indication of
how this would be done.
[color=blue]
> Isn't this what Python is about - fast and fun programming, not
> frustration.[/color]

Yeah, but sometimes it's impossible
[color=blue]
> After all, if I want troubles, I always can use C or Java
> :))[/color]

Yeah, but Python is not a silver bullet.
--
Michael Hoffman

[Elbert Lev]

Re: annoying behavior

pmaupin@speakea sy.net (Patrick Maupin) wrote in message news:<653b7547. 0409281915.5ff0 d92e@posting.go ogle.com>...[color=blue]
> <elbertlev@hotm ail.com> wrote:[/color]

Making interpreter 100% "bullet prove" is impossible, finding errors,
which can be found, not only possible, but also very commendable.

Isn't this obvious?

Let's stop wasting time on this discussion and continue discussing
decorators :)

Regards

[Michael Hoffman]

Re: annoying behavior

Elbert Lev wrote:
[color=blue]
> Making interpreter 100% "bullet prove" is impossible, finding errors,
> which can be found, not only possible, but also very commendable.
>
> Isn't this obvious?[/color]

With regard to what you want, only to you.
[color=blue]
> Let's stop wasting time on this discussion and continue discussing
> decorators :)[/color]

If you wish. I think you might find it educational, however, to consider
what everyone else seems to be saying a little harder.
--
Michael Hoffman

[Christopher Barker]

Re: annoying behavior

Patrick Maupin wrote:[color=blue]
> But, in Python, instances are "open". This means that I can add
> attributes to a class instance at _any_ time[/color]

Just to make it really clear what Patrick is saying:

#!/usr/bin/env python2.3

class foo:
def __init__(self, host):
self.f()
self.r = True

def f(self):
if self.r:
print "r is True"
else:
print "r is not True"


# now I'll add foo.r, before initialization:
foo.r = False

f = foo("1234")


and this runs just fine:

junk $ ./junk.py
r is not True

If you don't want a dynamic language, don't use Python!

-Chris


--
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@no aa.gov

[Patrick Maupin]

Re: annoying behavior

elbertlev@hotma il.com (Elbert Lev) wrote:
[color=blue]
> Making interpreter 100% "bullet prove" is impossible, finding errors,
> which can be found, not only possible, but also very commendable.
>
> Isn't this obvious?[/color]

Not yet, but once you submit a patch for the compiler which will do
what you want (without slowing down imports tremendously for everybody
else), I'm sure it will be such a thing of beauty that it will, in
retrospect, be obvious, and you will be hailed by one and all as the
man who finally added true error detection to Python.
[color=blue]
> Let's stop wasting time on this discussion and continue discussing
> decorators :)[/color]

I agree that this discussion is wasted on a man of your capabilities,
but so is the discussion about decorators. I'd rather see that patch.

Regards,
Pat

[Patrick Maupin]

Re: annoying behavior

Christopher Barker <Chris.Barker@n oaa.gov> wrote:
[color=blue]
> Patrick Maupin wrote:[color=green]
> > But, in Python, instances are "open". This means that I can add
> > attributes to a class instance at _any_ time[/color]
>
> Just to make it really clear what Patrick is saying:[/color]
... (code excised here)[color=blue]
> If you don't want a dynamic language, don't use Python!
>
> -Chris[/color]

This is a great example, but just to make sure that no beginners are
confused, I would like to point out that this example is of an actual
class (rather than a class instance) being modified dynamically (when
foo.r is assigned the value False), which was discussed in the
original post, but not in the snippet above the example.

Regards,
Pat

[Elbert Lev]

Re: annoying behavior

pmaupin@speakea sy.net (Patrick Maupin) wrote in message news:<653b7547. 0409291137.6846 793e@posting.go ogle.com>...[color=blue]
> elbertlev@hotma il.com (Elbert Lev) wrote:
>[color=green]
> > Making interpreter 100% "bullet prove" is impossible, finding errors,
> > which can be found, not only possible, but also very commendable.
> >
> > Isn't this obvious?[/color]
>
> Not yet, but once you submit a patch for the compiler which will do
> what you want (without slowing down imports tremendously for everybody
> else), I'm sure it will be such a thing of beauty that it will, in
> retrospect, be obvious, and you will be hailed by one and all as the
> man who finally added true error detection to Python.
>[color=green]
> > Let's stop wasting time on this discussion and continue discussing
> > decorators :)[/color]
>
> I agree that this discussion is wasted on a man of your capabilities,
> but so is the discussion about decorators. I'd rather see that patch.
>
> Regards,
> Pat[/color]

I respect you too.

Regards.
Lev.