Prev: numpy arrays to python compatible arrays
Next: Py++, boost and python type mismatch error
From: Stephen Hansen on 12 Jun 2010 13:58
On 6/12/10 9:01 AM, Victor Subervi wrote:
>> 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'm not hiding aces up my sleeve to make you all lose sleep.Honestly.

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

--

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

From: Dave Angel on 13 Jun 2010 07:17
Victor Subervi wrote:
> <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
From: Stephen Hansen on 13 Jun 2010 10:48
On 6/12/10 12:50 PM, Dennis Lee Bieber wrote:
> On Sat, 12 Jun 2010 14:42:27 -0400, Victor Subervi
> <victorsubervi(a)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.

--

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

From: Ethan Furman on 13 Jun 2010 18:19
Stephen Hansen wrote:
> On 6/12/10 12:50 PM, Dennis Lee Bieber wrote:
>
>>On Sat, 12 Jun 2010 14:42:27 -0400, Victor Subervi
>><victorsubervi(a)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~
From: Stephen Hansen on 13 Jun 2010 18:27
On 6/13/10 3:19 PM, Ethan Furman wrote:
> 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. :)

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