cs at zip.com.au
Wed Dec 15 23:39:21 UTC 2010
On 15Dec2010 09:12, stan <gryt2 at q.com> wrote:
| Thanks for taking the time to critique and modify
Always happy to cast aspertions at others :-)
| On Wed, 15 Dec 2010 12:06:48 +1100
| Cameron Simpson <cs at zip.com.au> wrote:
| > On 10Dec2010 14:28, stan <gryt2 at q.com> wrote:
| > |
| > | def extract (filename1 = None, filename2 = None):
| > | if filename1 != None and filename2 != None:
| > I'd not bother with this check - it is a special purpose function that
| > will not be misused, and if is _is_ misused it will fail silently,
| > which is not good.
| If it was for just me, neither would I. But the OP is obviously
| unfamiliar with python (or perl or ruby) or he would be doing the job
| using one of them without asking. That said, I didn't put in the
| print ("You forgot to enter the filenames")
Oh, I was thinking of just leaving it out entirely and letting python
throw a nice loud exception. So no default param values at all (forces
caller to supply something) and no sanity checking - just go and use it.
| > Untested example:
| > def get8of48(fp):
| > while True:
| > chunk = fp.read(48)
| > if len(chunk) == 0:
| > break
| > yield chunk[:8]
| > if (len(chunk) != 48:
| > print >>sys.stderr, "warning: short read from %s (%d bytes)"
| > % (fp, len(chunk))
| > for chunk8 in get8of48(open("your filename here", "rb")):
| > ... do something with chunk8, the 8-byte chunk ...
| > Shorter and faster and using less memory.
| I would have changed my version to just step through the slurp in
I'm a little reluctant to slurp the whole thing into memory by habit. Given
that it is just as easy to read piecemeal I try to go with that kind of
approach when I can. Slurping into memory is quick and easy, but doesn't
scale. For a once off task of known size that needs quick implementation it's
certainly reasonable to do so, though it suductively leads one into the
accidental huge-string-resize of your example code.
I think the approach I'm advocating here is: try the low memory approach by
default unless there's a specific performance or
complexity/difficulty-of-coding downside to it.
| low = 0
| high = 8
| first8 = slurp [low:high]
| low += 48
| high += 48
Yeah, I thought of modding your code that way. But it was almost easier
to recode using the direct/dumb-as-rocks approach I used because it
saves me doing any arithmetic:-)
| You are obviously a higher class python coder than I am.
Probably just more practiced and with a longer background in resource
limited environments. (Oh, when I were a lud...)
| I treat
| python like an elegant interpreted C. You treat it like the evolving
| functional ??? it is becoming.
Python's not really becoming a functional language, though it has several of
the pleasures of those. Generators have the same feel and heft as lazy
function evaluation but have more scope to accidentally do extra execution of
the "yield" is in the wrong place, or if their inner workings are greedy (eg
the slurp everything into memory approach, which might easily do the whole
computation before yielding anything depending on your mindset at the
One of the big differences between C and python (ignoring the
interpretation and memory management etc) is generators and exceptions.
Generators let you write little pretend "run at need" threadlike stuff
that does a specific task without embedding it in or emcumbering it with
the larger outer task. In a lot of ways it is like a component in a
And exceptions give you a lot of scope for writing code as if it will
always get perfect data or arguments; because error conditions usually
throw exceptions you don't need to clutter your algorithm with sanity
checks they was you have to in C or similar languages. The difficulty
with the clutter is not just that of thinking of all the ways your code
might get mistreated by the real world, but also of devising the correct
actions when the errors are detected. Since the correct action is often
obscure or very application/task dependent, not needing to make that
decision so often is a big win.
Cameron Simpson <cs at zip.com.au> DoD#743
Your mouse has moved. Windows NT must be restarted for the change to take
effect. Reboot now? [ OK ] - John D. Hardin <jhardin at wolfenet.com>
More information about the users