470,591 Members | 1,484 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,591 developers. It's quick & easy.

cgi, classes and their instances

Hello,

code (1) works, code (2) doesn't.

(1)
data = cgi.FieldStorage()
comment = data.getvalue("comment")
user_name = data.getvalue("user_name")

(2)
data = cgi.FieldStorage()
comment = cgi.FieldStorage().getvalue("comment")
user_name = cgi.FieldStorage().getvalue("user_name")

This doesn't seem to be caused by general properties of objecthood
in Python. Cf. (3).

(3)
class TestClass:
x = "bar"
y = "foo"
print TestClass().x
print TestClass().y

So, what is the reason for the difference between (1) and (2)?

Thanks for any hints,

Klaus
Jul 18 '05 #1
4 2257
On Tue, 13 Jul 2004, Klaus Neuner wrote:

KN> code (1) works, code (2) doesn't.

Are you using POST method? In this case data come from stdin,
which can be read only once, so the second call to constructor
recieves nothing.

KN> (1)
KN> data = cgi.FieldStorage()
KN> comment = data.getvalue("comment")
KN> user_name = data.getvalue("user_name")
KN>
KN> (2)
KN> data = cgi.FieldStorage()
KN> comment = cgi.FieldStorage().getvalue("comment")
KN> user_name = cgi.FieldStorage().getvalue("user_name")

BTW, I'd suggest using getfirst/getlist methods of FieldStorage,
since their behavior is the same independent on form content.
Thus you need less code to check.

--
Denis S. Otkidach
http://www.python.ru/ [ru]
Jul 18 '05 #2
> Are you using POST method? In this case data come from stdin,
which can be read only once, so the second call to constructor
recieves nothing.


Yes, that was the problem. Thanks a lot.

Klaus
Jul 18 '05 #3
kl************@yahoo.de (Klaus Neuner) wrote in message news:<3e**************************@posting.google. com>...
Hello,

code (1) works, code (2) doesn't.

(1)
data = cgi.FieldStorage()
comment = data.getvalue("comment")
user_name = data.getvalue("user_name")

(2)
data = cgi.FieldStorage()
comment = cgi.FieldStorage().getvalue("comment")
user_name = cgi.FieldStorage().getvalue("user_name")
The only response to this that I've seen so far covers the
"accidental" properties that the second case has in the context of the
cgi library. But what's actually going on here is that you're creating
a new instance of FieldStorage for each value you're trying to access:

cgi.FieldStorage() # This creates a new object.

And since you've already obtained such an object, there's no point in
creating more of them. In the context of the cgi library, you observe
that not all such objects contain the same data, too. Regardless of
whether you think this is a bad thing, it is useful to consider the
potential source of your confusion...
This doesn't seem to be caused by general properties of objecthood
in Python. Cf. (3).

(3)
class TestClass:
x = "bar"
y = "foo"
print TestClass().x
print TestClass().y
The x and y attributes are class attributes - they are shared between
all instances of TestClass. When you instantiate TestClass...

TestClass() # This is a new TestClass object.

....you can access these class attributes and observe that they are
shared between the separate instances:

TestClass().x == TestClass().x # Is true, since we're referring
# to the same thing.

You can actually access them directly on the class, too:

TestClass.x

However, these attributes are not instance attributes and can
therefore not be described as being covered by the "properties of
objecthood". Instead, you should write something like this:

class TestClass:
def __init__(self, x, y):
self.x = x
self.y = y

And to deal with instances of this class (ie. objects):

obj = TestClass("bar", "foo")
print obj.x
print obj.y

You could actually omit the constructor and just assign directly to
the instance attributes:

class TestClass:
pass

obj = TestClass()
obj.x = "bar" # Note that this is on the object, not the class.
obj.y = "foo"
print obj.x
print obj.y

But if you were to casually create two such objects without setting
the same values on the instance attributes, comparing those attributes
could easily produce a non-true result.

obj2 = TestClass()
obj2.x = "pub"
print obj2.x
obj.x == obj2.x # Is false.
So, what is the reason for the difference between (1) and (2)?


Now, you're probably about to respond to this with a remark about how
you knew all this already. ;-) But it is interesting to consider why
the FieldStorage object uses instance attributes to store its data, as
it clearly must do if the second example doesn't work. If you look at
the definition of the FieldStorage class (by digging inside the Lib
directory in your Python installation), you'll see that there are a
lot of "hidden", optional parameters to the initialiser, and the most
interesting one is that which takes a stream from which data will be
read in order to produce the conveniently accessible form field
values.

When you instantiate FieldStorage, the results of reading from the
specified stream will be stored as instance attributes. On subsequent
instantiations (looking at your second example), that stream will not
yield any useful information, and the resulting instance attributes
will not be set (or at least not in the same, meaningful way) on the
subsequent instances of FieldStorage. Therefore, querying each
subsequent object will produce different results from any querying of
the first object that was created.

Now I suppose you could suggest that FieldStorage should employ class
attributes to store form field values, but consider that stream
parameter again - while you might be using FieldStorage in a CGI
environment (where the default stream is sys.stdin and where there is
only one source of such values), FieldStorage can potentially be used
in other environments. Certainly, the use of class attributes would be
limiting in such environments, and the usage pattern depicted in the
second example, being a highly unusual approach in the simple CGI
case, would possibly be quite inappropriate in those other
environments.

Although verbose, I hope that this explanation makes the observed
behaviour more obvious.

Paul
Jul 18 '05 #4
> Although verbose, I hope that this explanation makes the observed
behaviour more obvious.


It does. Thanks for pointing this out to me.

Klaus
Jul 18 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

145 posts views Thread by David MacQuigg | last post: by
1 post views Thread by Eric Wilhelm | last post: by
12 posts views Thread by Ron Garret | last post: by
2 posts views Thread by | last post: by
27 posts views Thread by Keith Wilby | last post: by
5 posts views Thread by Andy B | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.