annoying behavior

[Elbert Lev]

# here is the problem I ran into:

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

def f(self):
if self.r:
#<do something>
pass
else:
#<do something else>
pass

f = foo("1234")

#here is the output:

#Traceback (most recent call last):
# File "G:\MyProjects\Python\Little\inconv.py", line 16, in ?
# f = foo("1234")
# File "G:\MyProjects\Python\Little\inconv.py", line 5, in __init__
# self.f()
# File "G:\MyProjects\Python\Little\inconv.py", line 9, in f
# if self.r:
#AttributeError: foo instance has no attribute 'r'

# I understand why does this happen, but, to tell the truth,
# this feature is very annoying.
# Are there any plans to relax this restriction?
# In 3.0 :)?

[Peter Hansen]

Elbert Lev wrote:

# here is the problem I ran into: [code that uses a name before it's bound to anything] #here is the output:
#AttributeError: foo instance has no attribute 'r'

# I understand why does this happen, but, to tell the truth,
# this feature is very annoying.
# Are there any plans to relax this restriction?
# In 3.0 :)?

Uh, what feature? You have a bug in your code. What
you showed is *no* different than doing this and
expecting something other than an error:

print x
x = 5

Please explain in more detail why you think this
shouldn't be giving an error, and what output you
think it should have given you.

-Peter

[Dave Brueck]

Elbert Lev wrote:

# here is the problem I ran into:

class foo:
def __init__(self, host):
self.f()
self.r = True [snip code using attribute before it existed] #here is the output:
#AttributeError: foo instance has no attribute 'r'

# I understand why does this happen, but, to tell the truth,
# this feature is very annoying.
This "feature" is pretty useful! :)
# Are there any plans to relax this restriction?
# In 3.0 :)?

Goodness, I sure hope not! (and I doubt it too) What behavior do you have in
mind? Anything different than the current behavior would be confusing/misleading
and would hide bugs like the one you encountered.

-Dave

[Jeremy Jones]

Elbert Lev wrote:

# here is the problem I ran into:

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

def f(self):
if self.r:
#<do something>
pass
else:
#<do something else>
pass

f = foo("1234")

#here is the output:

#Traceback (most recent call last):
# File "G:\MyProjects\Python\Little\inconv.py", line 16, in ?
# f = foo("1234")
# File "G:\MyProjects\Python\Little\inconv.py", line 5, in __init__
# self.f()
# File "G:\MyProjects\Python\Little\inconv.py", line 9, in f
# if self.r:
#AttributeError: foo instance has no attribute 'r'

# I understand why does this happen, but, to tell the truth,
# this feature is very annoying.
# Are there any plans to relax this restriction?
# In 3.0 :)?

Relax what restriction? Why should this behave any differently than it
is? I would kind of equate the above code to:

f = {}
f['a'] Traceback (most recent call last):
File "<stdin>", line 1, in ?
KeyError: 'a' f['a'] = 1

How should Python know that I'm going to assign f['a'] to anything
before it gets assigned? That's like expecting this:
f = {}
f['a']
#I'm planning on setting f['a'] to something in a little bit - maybe the Python interpreter can figure out what I'm going to do....
1 f['a'] = 1

to produce the results that I just typed in. You're calling method f()
before you are setting attribute r to anything, so when you call f(),
attribute r isn't set, so you get an exception. What restriction do you
want to relax? Do you want the Python interpreter to read ahead and
figure out if you were intending to set a variable and then use some
variable that you were planning on setting in the future? If so, what
if you set it and then set it again? Which one should it choose?

Jeremy

[Peter Otten]

Elbert Lev wrote:

# here is the problem I ran into:

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

def f(self):
if self.r:
#<do something>
pass
else:
#<do something else>
pass

f = foo("1234")

#here is the output:

#Traceback (most recent call last):
# File "G:\MyProjects\Python\Little\inconv.py", line 16, in ?
# f = foo("1234")
# File "G:\MyProjects\Python\Little\inconv.py", line 5, in __init__
# self.f()
# File "G:\MyProjects\Python\Little\inconv.py", line 9, in f
# if self.r:
#AttributeError: foo instance has no attribute 'r'

# I understand why does this happen, but, to tell the truth,
....you don't seem to. An attribute is not there until you set it.
# this feature is very annoying.
# Are there any plans to relax this restriction?
# In 3.0 :)?

No chance. Even as a non-developer I dare say that.
Either modify __init__():

def __init__(self):
self.r = False # for example
self.f()
self.r = True

or change f():

def f(self):
if hasattr(self, "r"):
# do something
else:
# do something else

Peter

[Daniel Dittmar]

Elbert Lev wrote:

# I understand why does this happen, but, to tell the truth,
# this feature is very annoying.
# Are there any plans to relax this restriction?
# In 3.0 :)?

You can relax this restriction yourself:
class foo:
r = None
def __init__(self, host):
self.f()
self.r = True

or if you prefer Perl-style attribute access:
class foo:
def __init__(self, host):
self.f()
self.r = True

def __getattr__ (self, name):
return None

and I'm sure metaclasses could also be used to good effect.

Daniel

[Larry Bates]

Elbert Lev wrote:

# here is the problem I ran into:

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

def f(self):
if self.r:
#<do something>
pass
else:
#<do something else>
pass

f = foo("1234")

#here is the output:

#Traceback (most recent call last):
# File "G:\MyProjects\Python\Little\inconv.py", line 16, in ?
# f = foo("1234")
# File "G:\MyProjects\Python\Little\inconv.py", line 5, in __init__
# self.f()
# File "G:\MyProjects\Python\Little\inconv.py", line 9, in f
# if self.r:
#AttributeError: foo instance has no attribute 'r'

# I understand why does this happen, but, to tell the truth,
# this feature is very annoying.
# Are there any plans to relax this restriction?
# In 3.0 :)?

Just put the lines in the correct order:

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

def f(self):
if self.r:
#<do something>
pass
else:
#<do something else>
pass

f = foo("1234")

You can't ask if self.r is True (which is what you do
in the second line of the f() method) before it actually
exists.

Larry Bates
Syscon, Inc.

----- Original Message -----
From: "Jeremy Jones" <za******@bellsouth.net>
To: "Elbert Lev" <el*******@hotmail.com>
Cc: <py*********@python.org>
Sent: Tuesday, September 28, 2004 1:13 PM
Subject: Re: annoying behavior

Jeremy!

Sure it would be nice if a the interpreter would give a warning before
really instantiating the instance of class foo (at least in "debug" mode).
In my case the error happened after the program ran about 30 minutes. I do
not think this is impossible.

[Elbert Lev]

Daniel Dittmar <da************@sap.corp> wrote in message news:<cj**********@news2.wdf.sap.corp>...

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?

[Michael Hoffman]

Elbert Lev wrote:

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?

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.
--
Michael Hoffman

[Dave Brueck]

Michael Hoffman wrote:

Elbert Lev wrote:

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?

Can you post the results of your PyChecker run and the exact input to it?

[snip] 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.

Also, it's not necessarily a mistake/bug, which is why it would make sense for
PyChecker to report it as a warning (if at all) and not the interpreter.

[Carlos Ribeiro]

On 28 Sep 2004 15:38:28 -0700, Elbert Lev <el*******@hotmail.com> wrote:

Daniel Dittmar <da************@sap.corp> wrote in message news:<cj**********@news2.wdf.sap.corp>...

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?

.... jumping in the discussion just to point out that you're now asking
for something reasonable, while on your first message you were asking
for the opposite -- to make the interpreter *less* restrict. It's no
wonder people answered like that...

BTW, the problem with pychecker, in my not-so-humble opinion, is that
it may be regarded as slow, or a little too obstrusive for continuous
usage. But that's my opinion anyway.

--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: ca********@gmail.com
mail: ca********@yahoo.com

[Steve Holden]

el*******@hotmail.com wrote:

----- Original Message -----
From: "Jeremy Jones" <za******@bellsouth.net>
To: "Elbert Lev" <el*******@hotmail.com>
Cc: <py*********@python.org>
Sent: Tuesday, September 28, 2004 1:13 PM
Subject: Re: annoying behavior

Jeremy!

Sure it would be nice if a the interpreter would give a warning before
really instantiating the instance of class foo (at least in "debug" mode).
In my case the error happened after the program ran about 30 minutes. I do
not think this is impossible.

If not thinking something impossible actually made it possible then it
would be possible for me to ignore this thread rather than responding to it.

Next you'll be asking us to modify the compiler so it produces an error
if someone feeds it a program that never terminates.

If your program ran for 30 minutes before this quite-obvious bug
appeared then I should suggest you do some serious reading on the
subjects of unit-testing and test-first programming.

Alternatively, look for a language with DWIM-mode :-)

regards
Steve

[Jeremy Jones]

Steve Holden wrote:

el*******@hotmail.com wrote:

----- Original Message -----
From: "Jeremy Jones" <za******@bellsouth.net>
To: "Elbert Lev" <el*******@hotmail.com>
Cc: <py*********@python.org>
Sent: Tuesday, September 28, 2004 1:13 PM
Subject: Re: annoying behavior

Jeremy!

Sure it would be nice if a the interpreter would give a warning before
really instantiating the instance of class foo (at least in "debug"
mode).
In my case the error happened after the program ran about 30 minutes.
I do
not think this is impossible.

If not thinking something impossible actually made it possible then it
would be possible for me to ignore this thread rather than responding
to it.

Next you'll be asking us to modify the compiler so it produces an
error if someone feeds it a program that never terminates.

If your program ran for 30 minutes before this quite-obvious bug
appeared then I should suggest you do some serious reading on the
subjects of unit-testing and test-first programming.

Alternatively, look for a language with DWIM-mode :-)

regards
Steve

I'm going out on a limb here, but is it _possible_ that you imported the
module that contained the offending class, then 30 minutes later an
instance of said offending class was created? Here's your response to
Daniel Dittmar:

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?

Here, you're complaining about no warning being given at import. This
error would not have been manifest at import time, but at instantiation
time. And to your point, "It would be nice for the interpreter to give
a warning before really creating an instance of the class, at least in
debug....".... I recommend that you take Steves advice on unit testing.
Or, you could put try: except: blocks around every instance of any class
you create :-) No, it is _not_ impossible for the interpreter to do
that, but what all do you want it to check? Maybe I want it to call all
of my methods with some parameters specified somehow in docstrings and
make sure no errors occur. What you're asking is really general. Too
general, I think, for new functionality to be placed in the
interpreter. Thus Steve's recommendation for unit testing. If you
write good unit tests, there's your verification in "debug" mode. You
run your tests as you're developing. That way, you can target your
specific needs and you don't pay _any_ penalty at runtime.

Jeremy

[Patrick Maupin]

<el*******@hotmail.com> wrote:

Jeremy!

Sure it would be nice if a the interpreter would give a warning before
really instantiating the instance of class foo (at least in "debug" mode).
In my case the error happened after the program ran about 30 minutes. I do
not think this is impossible.

But, in Python, instances are "open". This means that I can add
attributes to a class instance at _any_ time (well, if I don't use
__slots__). The classes are open, too. I could even add attributes
to the class definition, after import, and before creating any
instances of the class.

This openness allows for the creation of some really powerful
programs. It also allows for the creation of some really powerful
bugs, which is why you are being admonished to run unit tests.

One thing this openness makes very difficult is the sort of static
semantic check you seem to think the compiler should perform. If I
can add a variable to the class after I import it but before I
instantiate it, how would a checker know if it was a bug or not?
(This is not to say that there are not programs which can flag such
constructs as "suspect", and you are certainly free to use such
programs to improve your own code, but please don't attempt to foist
the rigors of a statically declared language on Python -- a lot of its
practitioners are escapees from such rigorous straightjackets.)

One quasi-rhetorical question, though -- I haven't used C++ in awhile
(and I've never used Java). Are the stock compilers actually powerful
enough to flag this sort of inter-method use of an instance member
variable before it has been initialized? If so, color me edified. If
not, why are you complaining that Python didn't find this soon enough,
rather than praising Python for finding it at all? Personally, I
would much rather debug from such a clean description of what went
wrong than go rummaging around the typical core dump you could get
from an uninitialized pointer in another language.

Regards,
Pat

[Elbert Lev]

Michael Hoffman <m.*********************************@example.com > wrote in message news:<cj**********@gemini.csx.cam.ac.uk>...

Elbert Lev wrote:

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?
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.

Here it is:

Processing test...
C:\Python23\python.exe
C:\Python23\Lib\site-packages\pychecker\checker.py
test.py
Caught exception importing module test:
File "C:\Python23\Lib\site-packages\pychecker\checker.py", line
576, in setupMainCode()
module = imp.load_module(self.moduleName, 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
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.

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]

Elbert Lev wrote:

Michael Hoffman <m.*********************************@example.com > wrote in message news:<cj**********@gemini.csx.cam.ac.uk>...

Can you post the results of your PyChecker run and the exact input to it?
Here it is:

Processing test...
C:\Python23\python.exe
C:\Python23\Lib\site-packages\pychecker\checker.py
test.py
Caught exception importing module test:
File "C:\Python23\Lib\site-packages\pychecker\checker.py", line
576, in setupMainCode()
module = imp.load_module(self.moduleName, 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

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.

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.
Sure not all!
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.
Isn't this what Python is about - fast and fun programming, not
frustration.
Yeah, but sometimes it's impossible
After all, if I want troubles, I always can use C or Java
:))

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

[Elbert Lev]

pm*****@speakeasy.net (Patrick Maupin) wrote in message news:<65**************************@posting.google. com>...

<el*******@hotmail.com> wrote:

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]

Elbert Lev wrote:

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

Isn't this obvious?
With regard to what you want, only to you.
Let's stop wasting time on this discussion and continue discussing
decorators :)

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]

Patrick Maupin wrote:

But, in Python, instances are "open". This means that I can add
attributes to a class instance at _any_ time

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 [phone] voice
7600 Sand Point Way NE [phone] fax
Seattle, WA 98115 [phone] main reception

Ch**********@noaa.gov

[Patrick Maupin]

el*******@hotmail.com (Elbert Lev) wrote:

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

Isn't this obvious?
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.
Let's stop wasting time on this discussion and continue discussing
decorators :)

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]

Christopher Barker <Ch**********@noaa.gov> wrote:

Patrick Maupin wrote:

But, in Python, instances are "open". This means that I can add
attributes to a class instance at _any_ time
Just to make it really clear what Patrick is saying:

... (code excised here) If you don't want a dynamic language, don't use Python!

-Chris

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]

pm*****@speakeasy.net (Patrick Maupin) wrote in message news:<65**************************@posting.google. com>...

el*******@hotmail.com (Elbert Lev) wrote:

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

Isn't this obvious?

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.

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

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

I respect you too.

Regards.
Lev.