Prev: numpy arrays to python compatible arrays
Next: Py++, boost and python type mismatch error
From: Stephen Hansen on 11 Jun 2010 15:43
... This is the first time you've actually clearly expressed what you're
doing.

On 6/11/10 12:11 PM, Victor Subervi wrote:

I dub thee Script1.py:
> *** RIGHT HERE! ***
>
> print "<input type='text' size='2' maxlength='2'
> name='new_passengers_curr_customers' /><br />"
>
> *** SEE IT? ***

Mmhmm.

I dub thee Script2.py:
> *** NOTE THIS: ****
> new_passengers_curr_customers = New_Passengers_Curr_Customers(customers,
> flights)
> *** THAT LINE ****

Okay.

I dub thee Script3.py:
> import cgitb; cgitb.enable()
> import cgi
>
> form = cgi.FieldStorage()
>
> def New_Passengers_Curr_Customers(customers, flights):
>
> *** RIGHT HERE. SEE THIS LINE? WHY DOES IT WORK HERE AND NOT IN THE 2ND
> SCRIPT IN THIS HERE EMAIL WHERE IT SHOULD WORK???***
> new_passengers_curr_customers =
> int(form.getfirst('new_passengers_curr_customers', 0))
> *** THAT LINE ABOVE. RIGHT ABOVE HERE. OK?? ***

The only reason that moving the lines
form = cgi.FieldStorage()
and
blah = int(form.getfirst("blah", 0))

from Script3 to the exact place in Script2 (notwithstanding my not
wanting to type absurdly long variable names :P) wouldn't work, is if
you didn't move the lines correctly. Those will absolutely work just
fine in Script2.py. You had to have done it wrong. Maybe typo'd.

Show the traceback.

Hint: Never say it "doesn't work", or "I can't do this here", or "it
won't" or "it can't. Show the actual traceback and the actual (not
retyped) chunk of code.

--

Stephen Hansen
... me+list/python (AT) ixokai (DOT) io

From: MRAB on 11 Jun 2010 15:49
Victor Subervi wrote:
> Ok. Starting over. Here is the script that "generates" the variable
> "new_passengers_curr_customers":
>
[snip]
> Now, here's the form that *should* be able to access that variable:
>
> !/usr/bin/python
>
> import cgitb; cgitb.enable()
> import cgi
> import sys,os
> sys.path.append(os.getcwd())
> import MySQLdb
> from login import login
> import fpformat
> from New_Passengers_Curr_Customers import New_Passengers_Curr_Customers

This imports from module New_Passengers_Curr_Customers, which calls:

cgi.FieldStorage()

> from New_Passengers_Addl_Customers import New_Passengers_Addl_Customers
> from New_Passenger import New_Passenger
>
> form = cgi.FieldStorage()
>
[snip]

Another call to:

cgi.FieldStorage()

>
> *** NOTE THIS: ****
> new_passengers_curr_customers =
> New_Passengers_Curr_Customers(customers, flights)
> *** THAT LINE ****
>
> if new_passengers_curr_customers > 0:
> print "<input type='submit' value=' Send ' />"
> print '</body>\n</html>'
> cursor.close()
>
> create_edit_passengers3()
>
>
> See that line that I marked right at the end? So here's that script:
>
> #!/usr/bin/python
>
[snip]

> import cgitb; cgitb.enable()
> import cgi
>
> form = cgi.FieldStorage()
>
> def New_Passengers_Curr_Customers(customers, flights):
>
> *** RIGHT HERE. SEE THIS LINE? WHY DOES IT WORK HERE AND NOT IN THE 2ND
> SCRIPT IN THIS HERE EMAIL WHERE IT SHOULD WORK???***
> new_passengers_curr_customers =
> int(form.getfirst('new_passengers_curr_customers', 0))
> *** THAT LINE ABOVE. RIGHT ABOVE HERE. OK?? ***
>
[snip]
>
> Ok. So I think that was clear now.
> TIA,
> beno
>
The documentation for cgi.FieldStorage() says:

""To get at submitted form data, it�s best to use the FieldStorage
class. The other classes defined in this module are provided mostly for
backward compatibility. Instantiate it exactly once, without arguments.
This reads the form contents from standard input or the environment
(depending on the value of various environment variables set according
to the CGI standard). Since it may consume standard input, it should be
instantiated only once.""

It might be that the first call to cgi.FieldStorage() is consuming the
data, so the second call sees no data.

You could ensure that there are only 2 types of source file:

1. Script: called by CGI (not sure about the terminology here). It
fetches the values from the form using:

form = cgi.FieldStorage()

2. Module: imported to provide supporting functions. It never calls
cgi.FieldStorage(). If an imported function needs the form then it's
passed in explicitly.
From: Dave Angel on 11 Jun 2010 16:09
Victor Subervi wrote:
> Ok. Starting over. Here is the script that "generates" the variable
> "new_passengers_curr_customers":
> <snip>
>

> Now, here's the form that *should* be able to access that variable:
>
> !/usr/bin/python
>
> import cgitb; cgitb.enable()
> import cgi
> import sys,os
> sys.path.append(os.getcwd())
> import MySQLdb
> from login import login
> import fpformat
> from New_Passengers_Curr_Customers import New_Passengers_Curr_Customers
> from New_Passengers_Addl_Customers import New_Passengers_Addl_Customers
> from New_Passenger import New_Passenger
>
> form = cgi.FieldStorage()
>
> <snip>
I have to guess here, since I have very limited CGI experience, and the
FieldStorage() function/class isn't listed in my 2.6 docs.

But my guess is that you only get to parse the cgi stuff once. So when
you import another module that calls that same function, it clears it
out so it's no longer accessible to you here. Think of a file open.
Once read, the file-ptr is at the end, and further reads won't see anything.

If I'm right, then you'd need something like "rewind". Or if you just
want this script to access the data, then move that line before the
three imports.

Your question would have been much easier to understand if you had
referred to "form field" rather than variable, since I assumed you
really meant Python variable. Also, this script is a CGI script,
written in Python. But the other files that you import are python
modules, not scripts.

I'd also suggest you not use the same name for the module that you use
for the function in that module. That's the cause of another confusion
I had with your message.

But back to your problem.

I'd suggest you do all your form interaction from a single script, and
pass any needed data explicitly to functions in the other modules,
rather than having them try to look it up themselves.

DaveA
From: Stephen Hansen on 11 Jun 2010 16:46
On 6/11/10 1:09 PM, Dave Angel wrote:
> Your question would have been much easier to understand if you had
> referred to "form field" rather than variable, since I assumed you
> really meant Python variable. Also, this script is a CGI script,
> written in Python. But the other files that you import are python
> modules, not scripts.

Yeah, those exact terminology issues tripped me up very hard in
understanding what was going on.

--

Stephen Hansen
... me+list/python (AT) ixokai (DOT) io

From: Stephen Hansen on 12 Jun 2010 11:46
On 6/12/10 6:19 AM, Victor Subervi wrote:
> You will note those very first lines. This also addresses two other
> responders who believed perhaps I had called the variable from the form in
> question more than once and that it had been "used up/consummed" in the
> first call. Here, the first call is the first line in "Script 2" and it
> prints the value "0", when the value gathered in the very next line from the
> call to "Script 3" is "2", not "0".

Assuming:

-- You have only one "form" construction reading the FieldStorage in
any module around that's imported or loaded,
-- That the New_Passengers_Whatever_Other module has no top-level code
which executes as a side-effect that may be changing things
-- And that between the 'def New_Passengers_Whatever_Other' and the
form, then the call to get the value from the FieldStorage, you are not
doing any other actions which may be messing with stuff, then--

I call bullshit :)

You're doing something that you're not telling us. There's something
else going on. There's no way that form.getfirst() being in another file
will in and of itself (notwithstanding possibilities of the second
invocation actually not working at all due to reading the input) return
different results.

> With respect to Stephens playful jibe about my "absurdly long [variable]
> names", they're long because they're descriptive, and other posters not so
> playfully jibed me about my absurdly short nondescriptive names. Hey, could
> you guys coordinate your jibes so you're all on the same page? ;/

Its a question of balance. Using a lot of extremely small nondescriptive
names is bad. Using a bunch of really long ones is just as bad.

Seek the middle of the road.

--

Stephen Hansen
... Also: Ixokai
... Mail: me+list/python (AT) ixokai (DOT) io
... Blog: http://meh.ixokai.io/

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: numpy arrays to python compatible arrays
Next: Py++, boost and python type mismatch error