== '__main__':
import astandardmodule
astandardmodule.appendRelativeIncludePath('..', '..')
import mymodule
Which, as you can see, is much shorter. ;)
--
Greg McIntyre
--
http://mail.python.org/mailman/listinfo/python-list
Diez B. Roggisch wrote:
> I tried to find out if subway and
> rails can do the same - that is, generate the sql. For subway the lack
> of documentation prevented that, and I didn't find it in rails , too.
In Rails you can do that with the command:
$ rake db_structure_dump
However I think it's n
Robert Kern wrote:
> > Robert> Please quote the message you are replying to. We have no
> > Robert> idea what "the 2nd option" is.
> >
> > I think he means the second option you presented
> >
> > If you must read one character at a time,
> >
> > def reader(fileobj, blocksize=1):
> >
John Machin wrote:
> Sigh indeed. If you need to read it a character at a time to parse it,
> the design is f***ed.
There is always the potential to do 2k buffered reads and once in
memory pick the contents apart character-wise.
I assume something similar would happen for tokenising XML and HTML
> On the other hand, if you've already
planned another pass over the code, that might be the time to look
into this.
Exactly. And when I do that pass I will definitely try buffering the
data 10 or 100 meg at a time before entring the 1 char-at-a-time loop,
or using mmap to similar ends.
--
http:
That is both clever and useful! I never would have thought of doing
that.
This seems to me like a general way to "workaround" the Python
statement/expression separation woes I've been having, in cases where I
really really want it.
Now, where can I copy this out to so I will be able to find it wh
John Machin wrote:
> > Is some way to make this code more compact and simple? It's a bit
> > spaghetti.
>
> Not at all, IMHO. This is a simple forward-branching exit from a loop in
> explicable circumstances (EOF). It is a common-enough idiom that doesn't
> detract from readability & understandabil
I've always accepted the None vs. 0 as a cavaet of the added
convenience but I think it's ultimately worth it.
Sorry, I didn't want to start a
"nothing values evaluate to false" argument.
I'll go read python-dev archives a bit and see if there's anything
useful for me to know.
Thanks
--
http:/
Donn Cave wrote:
> Actually I'd make it a little less compact -- put the "break"
> on its own line -- but in any case this is fine. It's a natural
> and ordinary way to express this in Python.
>
> ...
> | But I get a syntax error.
> |
> | while c = f.read(1):
> |^
> | SyntaxError:
The 2nd option has real potential for me. Although the total amount of
code is greater, it factors out some complexity away from the actual
job, so that code is not obscured by unnecessary compexity. IMHO that's
great practice.
I like it! Thank you! The assurance that the code was clear was good
t
Okay, the 1st option seems more complicated and the 2nd option, while
simpler to my eye makes me worry about file descriptors, resource
management and memory running out.
My files are large, hence 1 character at a time, not f.read().
This is code from another employee and I'm just in the stages o
I have a Python snippet:
f = open("blah.txt", "r")
while True:
c = f.read(1)
if c == '': break # EOF
# ... work on c
Is some way to make this code more compact and simple? It's a bit
spaghetti.
This is what I would ideally like:
f = open("blah.txt", "r")
while c = f.re
I like this solution. For some reason it made me want to write a Ruby
version of it. Possibly something about the title and the fact that
Ruby enthusiasts are always going on about "the Ruby way".
VOWELS = 'aeiouy'.split('')
def reinterpolate(word)
letters = word.split('').sort_by{rand}
v
13 matches
Mail list logo
