Prev: numpy arrays to python compatible arrays
Next: Py++, boost and python type mismatch error
From: Stephen Hansen (L/P) on 10 Jun 2010 10:30
On 6/10/10 7:14 AM, Victor Subervi wrote:
> Hi;
> I have a script that calls values from the form that calls it. This script
> imports another script:
>
> from New_Passenger import New_Passenger
>
> def create_edit_passengers3():
> ...
> new_passengers_curr_customers = New_Passengers_Curr_Customers(customers,
> flights)
> if new_passengers_curr_customers > 0:
> print "<input type='submit' value=' Send ' />"
>
> All this works. What puzzles me, however, is that the value of
> new_passengers_curr_customers has to be called using cgi from the imported
> script (New_Passenger). It cannot be called from the calling script. I would
> have thought it would have been the other way around. Please help me
> understand why.

I can't quite figure out what you're asking.
new_passengers_curr_customers is a variable local to
create_edit_passengers3; you have something that differs only in case
called New_Passengers_Curr_Customers which -- I assume is defined,
somewhere. Then you haev New_Passenger, and I'm not sure I see what it
has to do with anything.

But what does "cannot be called" mean? "Cannot" usually means "an error
happened" -- in which case you shouldn't really even mention it unless
you're gonna back it up with a traceback.

The former is a value, you don't call it. You access it. And it being
local, you can surely only access it within that function (unless you
pass it somewhere). The latter is -- a class? A function? No idea, as
you haven't shown us. Nor shown any errors or any tracebacks or
*anything* to indicate what is possibly going on, let alone what is
going wrong when you, I presume, attempt to "call .. something .. from
the calling script". (???)

So either way... cannot be called?

+1 for "absolutely worst framed question of the day" :)

--

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

From: Bruno Desthuilliers on 10 Jun 2010 11:35
Stephen Hansen (L/P) a �crit :
> On 6/10/10 7:14 AM, Victor Subervi wrote:
(snip)
>
> +1 for "absolutely worst framed question of the day" :)

IMHO you're wasting your time. Some guys never learn, and I guess we do
have a world-class all-times champion here.


From: Stephen Hansen on 10 Jun 2010 13:29
On 6/10/10 10:11 AM, Victor Subervi wrote:
> On Thu, Jun 10, 2010 at 10:30 AM, Stephen Hansen (L/P) <me+list/
> python(a)ixokai.io> wrote:
>>
>> But what does "cannot be called" mean? "Cannot" usually means "an error
>> happened" -- in which case you shouldn't really even mention it unless
>> you're gonna back it up with a traceback.
>>
>
> That is correct. It throws an error if I try and access the variable from
> the main script, because I try and use the value of that variable and for
> some reason I can't retrieve it.

I think you don't fully understand namespaces at the moment.

Every file is a module; think of it like a big box with a name on it.
Inside that box there are tags which have names written on them,
attached to some smaller boxes.

The variable in question, "new_passengers_curr_customers", is one such
tag. It is connected to a box, which is an object or value of some sort.

Let's assume you have approximately this code in a certain file, which
we shall name "creating.py" for example purposes:

def create_edit_passengers3():
new_passengers_curr_customers = ...

You have to picture this as a series of boxes, one within another. Once
this module is imported, and everything's loaded, your namespace looks
vaguely like this (this is a demonstration only, not a real thing):

{"creating":
{"create_edit_passengers3":
{"new_passengers_curr_customers": ...}
}
}

I drew that out as nested dictionaries just to try to illustrate what's
going on.

new_passengers_curr_customers is a name that is *local* to the function.
It exists solely inside that function. If you want to use it anywhere
"else", you have to either a) call the else, passing it, b) if the else
called this function, then simply return it, or b) in some other
*explicit* way set or store the variable in a place that is accessible
to else.

I'm not sure what your "else" is here to tell you which is best, a, b,
or c. If you want this variable to be accessible to the "main script"
(its not clear to me exactly which is 'main' in your scenario), which in
my above example is the module named 'creating', then a global variable
may work for you (I'm not going to harp on the danger of globals to you,
you're not to the skill set of object oriented stuff yet), as in:

new_passengers_curr_customers = None

def create_edit_passengers3():
global new_passengers_curr_customers

new_passengers_curr_customers = ...

What this chunk of code does is establish, in the top-level of your
module, a new variable. Inside your function, you then explicitly state,
"When I assign to new_passengers_curr_customers, I want to assign to the
existing module-level variable, and NOT create a new local with the same
name." That's what the global statement does: but note, 'global' really
means /module level/, and not /universal/ -- it won't be accessible in
another module.

If you have certain variables you need to access in more then one
module/file, what you can do is create a separate module that both
import separately, and share.

As in, a file called "state.py", which would say like:

new_passengers_curr_customers = None

Then in your creating.py:
import state

def create_edit_passengers3():
state.new_passengers_curr_customers = ...

Then anywhere you want to access that variable, you do 'state.blah'
instead of 'blah'.

Note: I'm entirely unsure if its wise to use -either- of these methods
in the context of a web application, unless this application is
single-threaded, and this state information is entirely temporary:
meaning that when you are done with it, and before a new request hits,
you are sure to clear it out so you don't get two requests corrupting
each-other.

--

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

From: Stephen Hansen on 10 Jun 2010 14:07
On 6/10/10 10:48 AM, Victor Subervi wrote:
> Now, create_edit_passengers3() is called by the form/submit button in (you
> guessed it) create_edit_passengers2.py, the latter containing a var in it
> which *should* be accessible to create_edit_passengers3.py, one would think.

Wait, wait, wait.

If a user is browsing to, say,
http://example.com/create_edit_passengers2.py; that script will be run,
and once -done-, print out a form which the user sees.

At that point, create_edit_passengers2.py is dead. Gone. Over.

Once a person then clicks Submit, and the form is sent to
http://example.com/create_edit_passengers3.py; its a whole new
environment (assuming you're using CGI, which it appears you are).

The *only* way for state or data to get from one script to another is
not importing, or shared variables, or anything like that: you *have* to
pass it into that form, and extract it from the resulting form. You can
pass the actual variables as a <input type="hidden">, and then extract
it like any of the user-fields. Or, you can write out your state to a
local file with some unique ID, and just write out into the form that
unique ID. Or use a cookie session. Etc.

You *can't* pass variables around script-to-script among separate CGI
sessions. It just totally doesn't work like that. Any success you think
you have had is false; it works by mere accident or illusion. Each CGI
script stands alone. It starts, runs, executes, then closes. No state is
preserved unless you *explicitly* preserve it.


*However*, if I put that *same_line* of code
> in New_Passengers.py (and fn of same name). it will give me the correct
> value, which I can then pass back to the calling script
> (create_edit_passengers3.py).

There is no passing going on. You're just tricking yourself into
thinking you're passing. The only way to pass variables between CGI
scripts is to explicitly write them out to the form, and read them in
from the form. You can't pass them around pythonically.

--

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

From: Stephen Hansen on 10 Jun 2010 15:01
On 6/10/10 8:35 AM, Bruno Desthuilliers wrote:
> Stephen Hansen (L/P) a écrit :
>> On 6/10/10 7:14 AM, Victor Subervi wrote:
> (snip)
>>
>> +1 for "absolutely worst framed question of the day" :)
>
> IMHO you're wasting your time. Some guys never learn, and I guess we do
> have a world-class all-times champion here.
>
>

Well, he eventually learned about bare excepts and using string
formatting in SQL. It took a long time, but he finally believed us.

He just sort of needs to give us the benefit of the doubt when we say,
"umm, its bad to do that" :)

--

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

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