Re: Deformed Form
Stephen Hansen (L/P)
> 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
Bruno Desthuilliers
> On 6/10/10 7:14 AM, Victor Subervi wrote:
>
> +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.
Stephen Hansen
> On Thu, Jun 10, 2010 at 10:30 AM, Stephen Hansen (L/P) <me+list/
> pyt...@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.
>>
>
> 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
> 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
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" :)
Bruno Desthuilliers
> 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.
No ??? Incredible. Perhaps I'm being a bit too pessimistic then.
Emile van Sebille
> Now you guys can make fun of me all you want, but until you actually READ
> and UNDERSTAND what I'm writing, I'm afraid I think your criticisms are
> ridiculous and make you look like fools.
I think the point is exactly as you state -- until you actually READ and
UNDERSTAND what you're writing, I'm afraid your questions are ridiculous
and make you look like a fool.
Emile
Stephen Hansen
> You know, if this were the first time I'd worked with "passing variables
> around" through cgi, I'd think you may be right. But answer me this:
if what
> you assume is correct,
I do not assume. I know.
With CGI, each web request is independent. This is simple fact.
The web server launches Python, Python runs a script, Python returns a
string containing the result, *Python closes*. The web host sends that
string to the client.
The Python application *ends*. Its memory is cleared. It is gone. This
is how CGI works (and why CGI is almost never used anymore, as it is
quite slow as a result-- most people use something like FastCGI or WSGI
either with a long-running daemon Python process or embedding Python
into Apache itself).
When the next request comes in, it all starts up again: each request has
only the information provided to it, either in cookies, the environment
variables (there's quite a few interesting ones), and the request
parameters.
This is *how it works*.
This is not some vague guess of mine. This is *years* of experience of
*actually* doing *exactly* what you're doing (while at the time actually
making an attempt to understand the actual processes going on instead of
just moving things around in files and observing the results to guess
what's going on under the covers).
Sure, if you have some file that two separate scripts import, and in
said file you generate some value-- as long as that value will be the
same at all times, it'll appear that the two scripts are sharing some
state. They are not, however. The two scripts can not communicate.
> Now you guys can make fun of me all you want, but until you actually READ
> and UNDERSTAND what I'm writing, I'm afraid I think your criticisms are
> ridiculous and make you look like fools.
And this comment ends my attempt at assisting you, for multiple reasons
(from the utter absurdity of you insisting we understand you when you
take insultingly little care to actually express your problems clearly,
to your arrogant and repeated refusal to take advice that is given, to
your abject rudeness here, and so on).
Stephen Hansen
On 6/11/10 10:40 AM, Victor Subervi wrote:
>>> Now you guys can make fun of me all you want, but until you actually
READ
>>> and UNDERSTAND what I'm writing, I'm afraid I think your criticisms are
>>> ridiculous and make you look like fools.
> On Fri, Jun 11, 2010 at 12:24 PM, Stephen Hansen
> <me+list/pyt...@ixokai.io>wrote:
>>
>> And this comment ends my attempt at assisting you, for multiple reasons
>> (from the utter absurdity of you insisting we understand you when you
>> take insultingly little care to actually express your problems clearly,
>> to your arrogant and repeated refusal to take advice that is given, to
>> your abject rudeness here, and so on).
>>
>
> That comment was not addressed to you as you didn't bother to quote the
> other part just after it, where I stated I appreciate your help and
> understand how difficult it is to not misunderstand each other. Sorry you
> misunderstood. I am not being arrogant or rude.
"I think your criticisms are ridiculous and make you look like fools" is
what I object to. I didn't quote the rest, because it doesn't matter --
once you say something like that, you become an jerk. Once you're an
jerk, you don't get to backtrack and say, 'oh, except you'. I don't
really accept the appreciation from someone being an jerk. If you're an
jerk at all, you can't really expect any sort of help at all :P
That said, I'll answer once more:
>> Sure, if you have some file that two separate scripts import, and in
>> said file you generate some value-- as long as that value will be the
>> same at all times, it'll appear that the two scripts are sharing some
>> state. They are not, however. The two scripts can not communicate.
>>
>
> I'm glad you have lots of experience and I respect that. However, I did not
> say that "two separate scripts import said file." To repeat:
>
> 1) variable value generated is
> create_edit_passengers2.py<http://example.com/create_edit_passengers2.py>
> 2) create_edit_passengers2.py<http://example.com/create_edit_passengers2.py>calls
> create_edit_passengers3.py
> <http://example.com/create_edit_passengers2.py>via a <form...> and
> passes the value of the var thereunto.
> 3) theoretically! Yet for some reason I can't call it in
> create_edit_passengers3.py
> <http://example.com/create_edit_passengers2.py>but *can* call it in a
> script that is imported by
> create_edit_passengers3.py <http://example.com/create_edit_passengers2.py>
>
> I think I'm being clear here, am I not? With all your knowledge and
> understanding, I still fail to understand how it is you don't understand and
> cannot answer my question.
You're not even *approaching* being clear.
"Variable value generated is" means WHAT?
What does "generated" mean?
If you have a line,
x = MyFunction()
At the top level of some script, then everytime that script is called,
MyFunction is called, and it assigns its value to x. If MyFunction is
deterministic and doesn't rely on any sort of state, it'll be the same
value every time.
[For the rest of the analysis, I refuse to continue typing these
absurdly long names. create_edit_passengers2.py is bar1.py,
create_edit_passengers3.py is bar2.py]
Okay, at 1, you say.. you have Value generated. When you go
http://foo/bar1.py, then it will load, "generate" your value, dump the
resulting output, and then close.
And its done. That value ceases to exist.
Okay, so. Step 2. The output that bar1 returned contained a form. This
form, I assume (but you did not state), contains embedded in it the
value of "var". Yes? No? Either way
Now we're at step 2. In step 2, you have some form, and its calling back
to http://foo/bar2.py via a <form>, passing the value of "var" in it. I
can't quite make out what all is going on here, so its all a guess, as
you have this slightly crazy bar2.py<http://foo/bar1.py> thing going on
that I can't figure out. But, I'll just handwave that, and guess.
So, bar2 receives our "var".
Then you say:
> 3) theoretically! Yet for some reason I can't call it in
> create_edit_passengers3.py
> <http://example.com/create_edit_passengers2.py>but *can* call it in a
> script that is imported by
> create_edit_passengers3.py <http://example.com/create_edit_passengers2.py>
I can't even vaguely guess at what you're trying to express there, which
is why I didn't address this originally -- its utterly meaningless
gibberish to me.
"Yet for some reason I can't call it in bar2.py<http://foo/bar1.py>"
"but *can* call it in a script that is imported by
bar2.py<http://foo/bar1.py"
First of all, what is "it", and what are you "calling" -- using names
like 'calling' is so very damaging to clarity when you're talking about
CGI scripts interacting. As they don't call each-other. They return
output. That output may contain a link (or form, or whatever) to another
CGI script, or the same, or a different. That's not /calling/.
Either way: when last step 2 left us, bar2.py had received the "var" via
a <form>, and we aren't sure what happened then.
It returned some output. What output? Or.. its doing something. Or, its
the thing that's trying to do something. But can't. Because its..
"calling". What? How? What's that even mean?
Dave Angel
> On Fri, Jun 11, 2010 at 12:24 PM, Stephen Hansen
> <me+list/pyt...@ixokai.io>wrote:
>
>
>> said file you generate some value-- as long as that value will be the
>> same at all times, it'll appear that the two scripts are sharing some
>> state. They are not, however. The two scripts can not communicate.
>>
>>
>
> I'm glad you have lots of experience and I respect that. However, I did not
> say that "two separate scripts import said file." To repeat:
>
> 1) variable value generated is
> create_edit_passengers2.py<http://example.com/create_edit_passengers2.py>
> 2) create_edit_passengers2.py<http://example.com/create_edit_passengers2.py>calls
> create_edit_passengers3.py
> <http://example.com/create_edit_passengers2.py>via a <form...> and
> passes the value of the var thereunto.
> 3) theoretically! Yet for some reason I can't call it in
> create_edit_passengers3.py
> <http://example.com/create_edit_passengers2.py>but *can* call it in a
> script that is imported by
> create_edit_passengers3.py <http://example.com/create_edit_passengers2.py>
>
> I think I'm being clear here, am I not? With all your knowledge and
> understanding, I still fail to understand how it is you don't understand and
> cannot answer my question.
>
You could try actually stating something approaching what your code is
doing.
"variable value generated is create_edit_passengers2.py" So you're generating that source code, and storing it in some variable called "value"?
"calls create_edit_passengers3.py" You say you're calling
create_edit_passengers3.py
but that's not a function, it's a source file. You can't call a source
file.
And "passes the value of the var therunto" is mighty roundabout.
Assuming you meant "import" in the last part, how are you passing the
value? Import doesn't take any parameters.
"script that is imported by". Nitpick: a script cannot be imported.
Once it is, it's a module.
"for some reason I can't call it in create_edit_passengers3.py" No idea
what "it" refers to, is it some mythical script that you're still trying
to call?
Your problem could be circular imports. If one module imports another,
which directly or indirectly imports the first, you can get into various
trouble. If somebody imports the *script* you're definitely hosed,
since there will then be two instances of that one, the script, and the
module.
Maybe it's all clear if one looks at those files, but from here the
links seem broken. So I'm just going by your message, which is
confusing. I suggest you construct a simple example to show the
problem, one small enough to include here in its entirety. Then
describe it in proper Python terminology.
DaveA
Stephen Hansen
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.
MRAB
> 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
> 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.
Dave Angel
> 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
Stephen Hansen
> 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
> 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/
Stephen Hansen
>> 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.
>>
>
I don't think you are *on purpose*, I've been there, we all have. We did
something in some other file, or some other part of the file that
doesn't seem relevant, and it has an interaction we didn't predict, and
it isn't immediately obvious. Now we're on over here, somewhere entirely
else, and things are behaving oddly.
The only suggestion I have is: try dumping all the .pyc's.
Its extremely rare, but once in awhile, I've seen odd behavior due to
Python not thinking a certain one is updated or not. Shouldn't ever
happen (an updated .py should invalidate the .pyc and cause the .pyc to
be regen'd), but it has to me like twice. (Ever)
> Yeah, well with copy and paste, the middle of the road might not be that far
> from "absurdly long variables". :) What's lost with long vars? Nothing but
> typing time, really. Short vars that aren't descriptive are problematic for
> far greater reasons.
Yes, but its not either/or, at all. There is "long names", and then
there is "short names": then there is a much wider gulf between, names
that are neither "long" nor "short".
I'm not sure what you're talking about with regards to copy and paste.
But, what's lost with "absurdly long names"? The clarity of the
resulting code. Names that are in the middle; long enough to be
descriptive and clear, but not needlessly verbose, lead to clarity of
the structure, certainly. Short names that are obscure abbreviations
hurt the clarity of the structure, absolutely.
However, once names get too verbose and long, you get into a situation
where their use in any sort of expression suddenly makes it so you get
obscenely long lines or need to start splitting that expression into
multiple lines.
Not that multiple lines *has* to be bad: but when something can be said
succinctly and clearly on one, Baby Jeebus is happy. And when something
can be said on a line that's not over oh, 80-100 (depending a lot on how
Old School you are :)) characters wide, yet still clear and entirely
comprehensible, Baby Jeebus is very happy. Even in the era of really
wide monitors: the virtue of the narrower code is side-by-side
comparison and evaluation (and less 'omg, my terminal is only 80
characters wide!' anymore).
Dave Angel
> <snip>
>
> DaveA suggested I not use the same name for my fn. as I do for my var;
> however, there is a difference in capitalization, and I'm trying to
> standardize this way. It makes it easy to recognize the difference (caps)
> and easy to recognize which vars go with which fns.
>
>
>
That's not what I said. I said:
"""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. """
Since you didn't name your modules (what you persist in calling
scripts), I can only guess their names from the import statements:
e.g.:
from New_Passengers_Curr_Customers import New_Passengers_Curr_Customers
I don't see any case difference there.
DaveA
Stephen Hansen
> On Sat, 12 Jun 2010 14:42:27 -0400, Victor Subervi
> <victor...@gmail.com> declaimed the following in
> gmane.comp.python.general:
>
>>
>> Interestingly,
>> ls -al
>> reveals *no* *.pyc files.
>>
> Which would seem to indicate that you have no user modules that are
> imported into other modules when run. And that there is no sharing of
> data between the modules you have.
Not really; pyc file generation is "optional". Its a performance
enhancement, but if it doesn't work, there's no problem.
No pyc files indicates to me that the web process doesn't have *write*
access to this directory, which is actually entirely fine and dandy. I'd
just pre-compile them all first, because otherwise Python has to read
the original source, parse and build up bytecode for each file every
request.
I'd "python -m compileall -f ." whenever you edit a file and before testing.
Ethan Furman
> On 6/12/10 12:50 PM, Dennis Lee Bieber wrote:
>
>>On Sat, 12 Jun 2010 14:42:27 -0400, Victor Subervi
>><victor...@gmail.com> declaimed the following in
>>gmane.comp.python.general:
>>
>>
>>>Interestingly,
>>>ls -al
>>>reveals *no* *.pyc files.
>>>
>>
>> Which would seem to indicate that you have no user modules that are
>>imported into other modules when run. And that there is no sharing of
>>data between the modules you have.
>
>
> Not really; pyc file generation is "optional". Its a performance
> enhancement, but if it doesn't work, there's no problem.
>
> No pyc files indicates to me that the web process doesn't have *write*
> access to this directory, which is actually entirely fine and dandy. I'd
> just pre-compile them all first, because otherwise Python has to read
> the original source, parse and build up bytecode for each file every
> request.
>
> I'd "python -m compileall -f ." whenever you edit a file and before testing.
I thought python (well, cpython, at least) didn't use .pyc files for the
main script?
~Ethan~
Stephen Hansen
> I thought python (well, cpython, at least) didn't use .pyc files for the
> main script?
You're right, it doesn't. I forgot about that interaction with CGI*.
--
Stephen Hansen
... Also: Ixokai
... Mail: me+list/python (AT) ixokai (DOT) io
... Blog: http://meh.ixokai.io/
* Its been er, a decade, since I actually wrote a CGI script. Even my
throw-away little web scripts on my personal website aren't CGI. For
some reason, I do my throw-away junk in PHP, and only use Python for
full-scale web apps. (Hi, Pylons). Read into this what you will. :)
Dave Angel
> <snip>
>
> DavidA corrects me:
>
>
>> Since you didn't name your modules (what you persist in calling scripts),
>> I can only guess their names from the import statements:
>> e.g.:
>>
> >from New_Passengers_Curr_Customers import New_Passengers_Curr_Customers
>
>> I don't see any case difference there.
>>
>
> file (in this case) New_Passengers_Curr_Customers.py has only one method, to
> wit, New_Passengers_Curr_Customers(). Not a good idea? Please clarify and if
> not, why.
> Thanks all,
> beno
>
>
There are three levels which contributed to it being a bad idea.
1) Only one object defined in a module is usually a waste. If it really
stands alone, then fine. I'm not going to judge, just pointing it out.
About the only time I find myself doing that is when there are plugins,
so each wants to be its own file, and you choose at run time which to
import.
2) Having two objects of completely different types, both of global
scope, and giving them the same name, not even distinguished by
capitalization, can be very confusing. It comes up frequently on this
list, as a barrier to understanding.
3) Referring to "calling" a "script", when you actually meant calling a
function by the same name as the module was the trigger that made me
speak up.
Fix any one of them, and I'd probably have kept quiet.
DaveA