Re: OO approach to decision sequence?

Jordan Rastrick wrote: > Without knowing more about your problem, I think the most obvious OO > approach would be to write a seperate (simple) class for each of > node_type_1, node_type_2, etc. While I agree that this is the cleanest and usually simplest approach, it does have its drawbacks. I'm

Package organization

Hi, I've two questions concerning organizing and naming things when writing a Python package. - Naming of classes: I'm writing a library that reads PDF files. I have a data structure that represents the large-scale structure of a PDF file (header, trailer, incremental updates etc), and I'll h

Re: Package organization

F. Petitjean wrote: > As you whish :-) Damn freedom of choice *g > if in the package ie in the __init__.py (not the best idea) from PDF > import File as PDFFile # always possible Technically, this is clear - however I don't like the idea of giving the same thing different names, especially if

Re: Python Module Exposure

Jacob Page wrote: > better-named, Just a quick remark, without even having looked at it yet: the name is not really descriptive and runs a chance of misleading people. The example I'm thinking of is using zope.interface in the same project: it's customary to name interfaces ISomething. -- Thoma

Re: Should I use "if" or "try" (as a matter of speed)?

Steve Juranich wrote: > I was wondering how true this holds for Python, where exceptions are such > an integral part of the execution model. It seems to me, that if I'm > executing a loop over a bunch of items, and I expect some condition to > hold for a majority of the cases, then a "try" block

Re: Should I use "if" or "try" (as a matter of speed)?

Steven D'Aprano wrote: > On the gripping hand, testing for errors before they happen will be slow > if errors are rare: Hm, might have something to do with why those things intended for handling errors after they happened are called exceptions ;o) > - If your code has side effects (eg changing e

Frankenstring

Hi, I think I need an iterator over a string of characters pulling them out one by one, like a usual iterator over a str does. At the same time the thing should allow seeking and telling like a file-like object: >>> f = frankenstring("0123456789") >>> for c in f: ... print c ... if c == "

Re: Fwd: Should I use "if" or "try" (as a matter of speed)?

Christopher Subich wrote: > try: > f=file('file_here') > except IOError: #File doesn't exist > error_handle > error_flag = 1 > if not error_flag: > do_setup_code > do_stuff_with(f) > > which nests on weird, arbitrary error flags, and doesn't seem like good > programming to me.

Re: Slicing every element of a list

Alex Dempsey wrote: > for line in lines: > line = line[1:-5] > line = line.split('\"\t\"') > > This went without returning any errors, but nothing was sliced or split. > Next I tried: > > for i in range(len(lines)): > lines[i] = lines[i][1:-5] > lines[i] = lines[i].split('\"\t\"'

Re: Frankenstring

jay graves wrote: > see StringIO or cStringIO in the standard library. Just as with files, iterating over them returns whole lines, which is unfortunately not what I want. -- Thomas -- http://mail.python.org/mailman/listinfo/python-list

Re: Frankenstring

Scott David Daniels wrote: > Now if you want to do it for a file, you could do: > > for c in thefile.read(): > The whole point of the exercise is that seeking on a file doesn't influence iteration over its content. In the loop you suggest, I can seek() on thefile to my heart's

Re: Frankenstring

Roland Heiber wrote: > if i did understand what you mean, what about using mmap? AIUI (and as a little experimenting seems to confirm), you can't reposition an iterator over an mmap'ed file by seeking. True, you have both iterating by characters and seeking/telling, but the two functionalities do

Re: Frankenstring

Bengt Richter wrote: > < lotzefile.py >-- Thanks. [...] > byte = self.buf[self.pos] This is the place where the thing is basically a str whose items are accessed as sequence elements. It has some iterator behaviour and file management

Re: Frankenstring

Peter Otten wrote: class frankenstring(StringIO): > ... def next(self): > ... c = self.read(1) > ... if not c: > ... raise StopIteration > ... return c Repeated read(1) on a file-like object is one of the ways of doing it with exist

Re: Frankenstring

Andreas Lobinger wrote: > >>> t2 = f.find('2')+1 This is indeed faster than going through a string char by char. It doesn't make for a nice character-based state machine, but of course it avoids making Python objects for every character and uses the C implementation of str for searching. Howeve

Re: Frankenstring

Peter Otten wrote: > Not clumsy, just slow. As you wish ;o) I didn't mean clumsy as in "clumsy looking Python code" anyway, rather as in "clumsy to use the Python machinery for operations that are straight-forward and efficient in C, in which language str and cStringIO are implemented already".

Re: Frankenstring

Thomas Lotze wrote: > And I wonder whether there shouldn't be str.findany and > str.iterfindany, which takes a sequence as an argument and returns the > next match on any element of it. On second thought, that wouldn't gain much on a loop over finding each sequence, but add m

Re: using hotshot for timing and coverage analysis

Andreas Lobinger wrote: > hotshot.Profile has flags for recording timing per line and line events. > Even if i had both set to 1 i still get only the standard data (time per > call). Could it be that pstats.Stats doesn't know about hotshot? Haven't checked... What's much more annoying about hots

Re: Python Programming Contest

Brian Quinlan wrote: > I've decided that it would be be fun to host a weekly Python programming > contest. I like the idea, and doing the first problem was fun indeed :o) > I'm always looking for feedback, so let me know what you think or if you > have any ideas for future problems. It would be

Re: Frankenstring

Peter Otten wrote: > I hope you'll let us know how much faster your > final approach turns out to be OK, here's a short report on the current state. Such code as there is can be found at , with a Python mock-up in the same directory. Thi

Re: is this pythonic?

Mage wrote: > Or is there better way? > > for (i, url) in [(i,links[i]) for i in range(len(links))]: > ... > > "links" is a list. for i, url in enumerate(links): -- Thomas -- http://mail.python.org/mailman/listinfo/python-list

Re: Using gnu readline in my own python program?

sboyle55 wrote: > Hi...I'm a newbie to python, and very confused. I'm writing a simple > program and want the user to be able to edit a line that I display using > the full gnu readline capabilitites. (For example, control+a to go to the > beginning of the line.) > > Then I want to be able to r

Re: Using gnu readline in my own python program?

sboyle55 wrote: > raw_input is an excellent suggestion, and almost exactly what I want. > > But, I want to give the user a string to edit, not have them start from > scratch inputting a string. Take a look at the fancy_input function. -- Thoma

StringIO objects sharing a buffer

Hi, I want to implement a tokenizer for some syntax. So I thought I'd subclass StringIO and make my new class return tokens on next(). However, if I want to read tokens from two places in the string in turns, I'd either need to do some housekeeping of file pointers outside the tokenizer class (wh

Copying data between file-like objects

Hi, another question: What's the most efficient way of copying data between two file-like objects? f1.write(f2.read()) doesn't seem to me as efficient as it might be, as a string containing all the contents of f2 will be created and thrown away. In the case of two StringIO objects, this means the

Re: Copying data between file-like objects

Fredrik Lundh wrote: > if f2 isn't too large, reading lots of data in one operation is often the most > efficient way (trust me, the memory system is a lot faster than your disk) Sure. > if you don't know how large f2 can be, use shutil.copyfileobj: > > >>> help(shutil.copyfileobj) > He

Re: Copying data between file-like objects

Fredrik Lundh wrote: > copyfileobj copies from the current location, and write leaves the file > pointer at the end of the file. a s.seek(0) before the copy fixes that. Damn, this cannot be read from the documentation, and combined with the fact that there's no length parameter for a portion to

Re: accessor/mutator functions

Dan Sommers wrote: > I think I'd add a change_temperature_to method that accepts the target > temperature and some sort of timing information, depending on how the rest > of the program and/or thread is structured. But then you put application logic into a library function. Doing this consistentl

Semantics of propagated exceptions

Hi, I wonder how to solve the following problem the most pythonic way: Suppose you have a function f which, as part of its protocol, raises some standard exception E under certain, well-defined circumstances. Suppose further that f calls other functions which may also raise E. How to best disting

Re: Semantics of propagated exceptions

Sorry for not answering such a long time. It's because my question originated from a discussion within our company which moved out of focus shortly after I posted, and over waiting for some response from them before replying here, I forgot about it. Steve Holden wrote: >> - f might catch E excep

Re: Python Graphing Utilities.

Kenneth Miller wrote: > I am new to Python and i was wondering what graphing utlities would be > available to me. I have already tried BLT and after weeks of unsuccesful > installs i'd like to find something else. Anything someone would > recommend? You might also want to check out PyX:

Controlling a generator the pythonic way

Hi, I'm trying to figure out what is the most pythonic way to interact with a generator. The task I'm trying to accomplish is writing a PDF tokenizer, and I want to implement it as a Python generator. Suppose all the ugly details of toknizing PDF can be handled (such as embedded streams of arbitr

Re: Controlling a generator the pythonic way

Peter Hansen wrote: > Thomas Lotze wrote: >> I can see two possibilities to do this: either the current file position >> has to be read from somewhere (say, a mutable object passed to the >> generator) after each yield, [...] > > The third approach, which is cert

Re: Controlling a generator the pythonic way

Mike Meyer wrote: > Yes, such a switch gets the desired behavior as a side effect. Then again, > a generator that returns tokens has a desired behavior (advancing to the > next token) as a side effect(*). That's certainly true. > If you think about these things as the > state of the object, rath

Re: Controlling a generator the pythonic way

Peter Hansen wrote: > Fair enough, but who cares what the generator code thinks? It's what the > programmer has to deal with that matters, and an object is going to have a > cleaner interface than a generator-plus-mutable-object. That's right, and among the choices discussed, the object is the o

Re: Controlling a generator the pythonic way

Thomas Lotze wrote: > Does anybody here have a third way of dealing with this? Sleeping a night sometimes is an insightful exercise *g* I realized that there is a reason why fiddling with the pointer from outside the generator defeats much of the purpose of using one. The implementation usin

Re: Controlling a generator the pythonic way

Thomas Lotze wrote: > A related problem is skipping whitespace. Sometimes you don't care about > whitespace tokens, sometimes you do. Using generators, you can either set > a state variable, say on the object the generator is an attribute of, > before each call that requires a d

Re: why python on debian without the module profile?

kyo guan wrote: > ImportError: No module named profile They moved it to non-free because the module's license isn't DFSG compliant. -- Thomas -- http://mail.python.org/mailman/listinfo/python-list

Re: Controlling a generator the pythonic way

Thomas Lotze wrote: > I'm trying to figure out what is the most pythonic way to interact with a > generator. JFTR, so you don't think I'd suddenly lost interest: I won't be able to respond for a couple of days because I've just incurred a nice little hospital se

Minimally intrusive XML editing using Python

I wonder what Python XML library is best for writing a program that makes small modifications to an XML file in a minimally intrusive way. By that I mean that information the program doesn't recognize is kept, as are comments and whitespace, the order of attributes and even whitespace around attrib

Re: Minimally intrusive XML editing using Python

Stefan Behnel wrote: > Take a look at canonical XML (C14N). In short, that's the only way to get a > predictable XML serialisation that can be used for textual diffs. It's > supported by lxml. Thank you for the pointer. IIUC, c14n is about changing an XML document so that its textual representati

Re: Minimally intrusive XML editing using Python

Chris Rebert wrote: > Have you considered using an XML-specific diff tool such as: I'm afraid I'll have to fall back to using such a thing if I don't find a solution to what I actually want to do. I do realize that XML isn't primarily about its textual representation, so I guess I shouldn't be s

Re: Minimally intrusive XML editing using Python

Please consider this a reply to any unanswered messages I received in response to my original post. Dave Angel wrote: > What's your real problem, or use case? Are you just concerned with > diffing, or are others likely to read the xml, and want it formatted the > way it already is? I'd like t