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

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

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

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: 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

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: 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

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: 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: 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: 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: 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: 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: 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

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: 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

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

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

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

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

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: 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

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: 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: 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

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: 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

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

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: > 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: 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

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

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: > 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

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: 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:

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

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: 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

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

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