Re: [EVALUATION] - E01: The Java Failure - May Python Helps?
Alex Martelli wrote: Fredrik Lundh <[EMAIL PROTECTED]> wrote: Markus Wankus wrote: Google his name - he has been banned from Netbeans and Eclipse (and Hibernate, and others...) for good reason. Can you imagine how much of a Troll you need to be to *actually* get "banned" from the newsgroups of open source projects such as those? have Pythoneers ever "banned" anyone from a public forum? it's not like we haven't seen trolls and crackpots before, you know. I don't see how banning is technically possible in unmoderated groups. Shunning, or pelting the troll with abuse whenever he shows up, etc, etc, sure. But, banning? The PSU can do it, by modifying the time stream. This is done by simply readjusting the basic parameter of the -- http://mail.python.org/mailman/listinfo/python-list
Re: ElementTree and XPATH
Istvan Albert wrote: [EMAIL PROTECTED] wrote: it seems to be invalid syntax if I give "/a/b[0]" to the findall() method. Does anyone know the correct syntax? I think the proper mindset going in should be that elementtree does not support xpath but that there are some handy constructs that resemble the location steps of xpath. The lxml Pythonic wrapper of libxml2 which aims (among others) to build an elementtree API compatible interface will indeed extend that API and offer XPath support. Of course it's all not done yet. :) http://codespeak.net/mailman/listinfo/lxml-dev http://codespeak.net/svn/lxml/trunk/ Regards, Martijn -- http://mail.python.org/mailman/listinfo/python-list
Re: from vb6 to Python
Gerhard Häring wrote: MarcoL wrote: I am a VB6 programmer and I would like to learn a new high level language (instead of restarting from scratch with .NET), wich is opensource and cross-platform, in order to develop cross-platform business applications Good for you! And Python is a good choice. :) I think Python is the most suitable language for the scope. My question are: - Which version of python is more suitable for creating cross-platform GUI's? I've herard of PyGTK, wxPython, PyQT, tk, Anygui.. It's a matter of taste. I like wxPython best. It would probably be different if PyQT was also open-source on win32. Note that these are not really 'versions of Python'. These are different Python bindings or libraries (that you import as modules and packages in the normal way) that offer GUI facilities. For cross-platform GUIs wxPython seems to be popular, though I've never used it myself. [snip snip] - Is it possible, from Python, to work with sqlite? And with MsAccess? Yes. pysqlite (http://pysqlite.org/), and pyado, if by MsAccess you mean using the JET engine via ADO. Python can basically work with virtually any database; there are bindings for many. You can also access MsAccess through ODBC, though it's been a few years since I did that. See the database topic guide: http://www.python.org/topics/database/ And this is a list of database bindings: http://www.python.org/topics/database/modules.html Regards, Martijn -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
[EMAIL PROTECTED] wrote: A paper finding that OOP can lead to more buggy software is at http://www.leshatton.org/IEEE_Soft_98a.html [snip description of paper that compares C++ versus Pascal or C] What papers have scientific evidence for OOP? That's of course a good question. I'm sure also that comp.object has argued about this a thousand times. I'll just note that one paper is just a single data point with specific circumstances. The OO languages under investigation might have caused increased or lower failure rates for other reasons than their (lack of) object-orientedness, for instance. It is of course possible to come up with a lot of other explanations for a single data point besides a conclusion that OOP can lead to more buggy software. It for instance certainly not surprising to me that C++ can lead to more buggy software than some other languages. :) [snip] If OOP is so beneficial for large projects, why are the Linux kernel, the interpreters for Perl and Python, and most compilers I know written in C rather than C++? Because C++ is not an ideal object oriented language? Because a Linux kernel has very stringent predictability requirements for what kind of machine code is generated that C meets and is much harder to do with C++? There are other reasons to choose C, such as portability, obiquity and performance. Some of the same reasons probably apply to Perl and Python, though at a lesser degrees. I do not know a lot about Perl's implementation. I do know that Guido van Rossum has in fact considered rewriting Python in C++ in the past. And right now, there are various projects that are using object oriented languages to reimplement Python, including Python itself. Finally, it is certainly possible to program in object oriented style in C. It is more cumbersome than in a language that supports it natively, but it is certainly possible. Such OO in C patterns occur throughout the Linux kernel, which needs a pluggability architecture for its various types of drivers. It can also be seen in many aspects of Python's implementation. Another example of a C-based system that uses object oriented technologies is the GTK+ widget set. Anyway, this question is using a few data points to make an overly generic argument, and the data points themselves do not really support the argument so very well either. Regards, Martijn -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
Paul McGuire wrote: "Martijn Faassen" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Paul McGuire wrote: [snip] I would characterize the 80's as the transitional decade from structured programming (which really started to hit its stride when Djikstra published "Use of GOTO Considered Harmful") to OOP, and that OOP wasn't really "joyful" until the early-to-mid 90's. IMMEDIATE NOTICE TO ALL PYTHON SECRET UNDERGROUND MEMBERS. Classified. Any disclosure to non-PSU members prohibited. Offenders will be apprehended and removed from the time stream, permanently. Yikes! (or better, "Jikes!" or even "Yijkes!"?) - my bad. And he was on faculty at UT right here in Austin, too. It's a very common mistake I've seen so often that for a while I wondered whether his name really *was* Djikstra, but I knew he was Dutch and that it couldn't be so. That the PSU picked you for its disclosure is just a random coincidence, I'm sure.. :) Regards, Martijn -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
Peter Hansen wrote: Martijn Faassen wrote: Paul McGuire wrote: "Martijn Faassen" <[EMAIL PROTECTED]> wrote in message Yikes! (or better, "Jikes!" or even "Yijkes!"?) - my bad. And he was on faculty at UT right here in Austin, too. It's a very common mistake I've seen so often that for a while I wondered whether his name really *was* Djikstra, but I knew he was Dutch and that it couldn't be so. That the PSU picked you for its disclosure is just a random coincidence, I'm sure.. :) Well, in any case, thanks for setting the record straight, Martjin. That of course also happens to me once every while. I can take care of myself though -- Dijkstra however needs an advocate for the correct spelling of his name in this earthly realm. Imagine, for instance, what if he wants to egosurf, google for his own name and finds nothing because everybody was saying Djikstra all the time? That'd be terrible! What, they don't have google in the eternal realm? How can it be valhalla without google? Impossible. Regards, Martijn -- http://mail.python.org/mailman/listinfo/python-list
Re: NO REALLY
Jive wrote: Isn't there a comp.lang.flame or something? I've doublechecked, but I didn't see any significant flaming in this article (and I'm generally not very tolerant of it). My PSU posting was certainly not intended as a flame, in case that was misinterpreted. What'd I miss? Regards, Martijn -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
Peter Hansen wrote: Martijn Faassen wrote: Peter Hansen wrote: Well, in any case, thanks for setting the record straight, Martjin. That of course also happens to me once every while. I can take care of myself though -- Dijkstra however needs an advocate for the correct spelling of his name in this earthly realm. Then there's us Danes, with "sen" instead of "son" (as many people think it ought to be). And I can't even claim the wrong form sounds noticably different, making any defense seem petty. Obviously -sen is the only real suffix, as it's -sen in Dutch as well, as in Faas-sen. :) (Darn those Norwegians, influencing people's ideas of how a name like Hansen ought to be spelled, grumble, grumble. If they'd just invent a cell phone that used Python, as the Swedish have, they might deserve all that extra attention.) ;-) That's not the Swedes, it's the Finnish that did that. They typically don't like being mistaken for Swedes. :) Regards, Martijn -- http://mail.python.org/mailman/listinfo/python-list
Re: libxml2/xpath
Maxim Khesin wrote:
I am trying to do some xpath on
http://fluidobjects.com/doc.xhtml
but cannot get past 'point A' (that is, I am totally stuck):
import libxml2
mydoc = libxml2.parseDoc(text)
mydoc.xpathEval('/html')
[]
this returns an empty resultlist, which just seems plain wrong. Can anyone
throw a suggestion to the stupid?
Is the html element in a namespace?
Regards,
Martijn
--
http://mail.python.org/mailman/listinfo/python-list
Re: NO REALLY
Peter Hansen wrote: Brian van den Broek wrote: Peter Hansen said unto the world upon 2004-12-15 17:39: I could easily see this thread descending into a flame war in, oh, about another ten posts. That would be so freaky... Without a doubt that is the most ignorant and small-minded thought that ever has been, and ever could be, committed to words! And you, sir, must be, like, one of those Nazi type people, like that guy, uh, what was his name? er.. Godwood, Goodwin, something like that, anyway. (Hey, Jive, you happy yet?) Object oriented programming SUX! And Python too! It's slow and no scientific research exists in its favor! Also it doesn't work. Why would I need polymorphism? Lisp had all of this 50 years ago anyway. But functional programming by the way SUX TOO! So does procedural programming! And structured programming SUX, GOTO all the way! Oh, and Vi SUX, Emacs all the way. Emacs Lisp SUX though. Java is the only true object oriented language, so Python is not truly object oriented and it's slow anyway. The future will be to .NET. Oh and XML sucks! Python developers are above XML! And why doesn't Python have a web framework like Ruby on Rails? Python has way too many web frameworks, that SUX! And oh by the way, Ruby SUX! Perl is way superior to Python as it outperforms it and it's more readable. Indentation SUX! Depending on it is Barbaric, which is like Cobol, which by the way, ROCKS! The decorator syntax SUX! Why didn't they just use the ternary operator syntax for it?? Oh, and Python really went downhill since version 1.5.2! Python will not be a mature language if it doesn't add UNSIGNED INT, SIGNED LONG and FLOAT to the language as basic data types. Oh, and any language that doesn't have True Macros SUX. Guido von Rossam is ITALIAN! And he SUX! I SUX TOO BUT I WILL NEVER ADMIT TO IT EVER IN THIS WHOLE DISCUSSION, I will answer ANY argument indicating that my arguments are fallacious and my behavior unreasonable with the TRUTH, which is that you SUX. Hah! Martijn -- http://mail.python.org/mailman/listinfo/python-list
Re: from vb6 to Python
Luis M. Gonzalez wrote: MarcoL wrote: Hello, I am a VB6 programmer and I would like to learn a new high level language (instead of restarting from scratch with .NET... I'd like to add that by going with Python, you'll also be able to develop for .NET. Check this out: www.ironpython.com . Since the development of Ironpython is now being funded by Microsoft, you'll get the best of both worlds: An already excellent cross-platform, object oriented language and a fully compliant .NET language for Windows and Linux (through Mono and DotGnu). Unfortunately this is currently not near production use, and whether Microsoft is funding IronPython development is up in the air: One IronPython fan noted a disconcerting silence in IronPython development: http://usefulinc.com/edd/blog/contents/2004/12/09-jvm/read Of course it'll all resolve itself one way or another eventually, just wanted to correct the impression that IronPython is ready to go already. Regards, Martijn -- http://mail.python.org/mailman/listinfo/python-list
Re: from vb6 to Python
Luis M. Gonzalez wrote: Martijn Faassen wrote: Unfortunately this is currently not near production use, and whether Microsoft is funding IronPython development is up in the air: It's true that he Ironpython's mailing list is a little bit innactive, but this is just because there's only one person in charge of Ironpython at this moment (although Microsoft was looking to hire a new developer to help on this). A new developer is interesting news and makes it more likely the future funding status is assured. However, the innactivity is due to the fact that Jim Hugunin, its developer, has begun working for MS just a couple of months ago, and as he says, there are tons of new CLR features to learn that are applicable to dynamic languages. I realize that, and I'm sure that impacts things. That doesn't change the fact that IronPython as it stands now isn't done, and there isn't a clear idea of what will happen. Talk about "open source doesn't have a clear roadmap"; that seems to be true at least if Microsoft is doing the open source. ;) You should also give credit to Jim: he's the man who developed Jython, which is a complete inplementation of Python written in Java. He also created Numeric and co-authored Aspect, another programming language. I know who Jim is, and he deserves plenty of credit. I'm just passing along the concerns of a major IronPython fan, who doesn't know what's up himself and wants to fork the code. That's at the very least not a sign of good community management. :) So I'm sure that Ironpython will be a reality soon, and a very good one... I was pointing out that IronPython is *not* a reality right now, which is the impression that was being given to a newbie before. I wanted to counter an impression that might cause newbies to struggle with IronPython only to find out it's not ready yet. Whether IronPython will be mature soon is open for debate. Regards, Martijn -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
Paul McGuire wrote: [snip] I would characterize the 80's as the transitional decade from structured programming (which really started to hit its stride when Djikstra published "Use of GOTO Considered Harmful") to OOP, and that OOP wasn't really "joyful" until the early-to-mid 90's. IMMEDIATE NOTICE TO ALL PYTHON SECRET UNDERGROUND MEMBERS. Classified. Any disclosure to non-PSU members prohibited. Offenders will be apprehended and removed from the time stream, permanently. Words in human languages typically consist of a combination of vowels and consonants, at least up until the start of the posthumanist revolution in 3714, when the Morning Light Confederation's ships reached the ablethik-seganichek world of Kaupang again (on Hellenberg consensus time streams with catalog marker AB-7). Alphabetic scripts are a typical way to represent them. Even in the posthuman phase on Kaupang they were widely appreciated as a quaint representation. The language English, an indo-european tongue of the west-germanic persuasion (expressiveness rating 7, comprehensiveness rating 12, fits in the moderate Y group of the Lespan pan-species language classification system), is widely in use throughout a surprisingly long period on many time streams. This language does not have overly long consonant combinations. The language Dutch, though closely related to the language English has a slightly different sound to glyph mapping system. Dutch is, of course, the true language of the Python Secret Underground and the official native language of Python users. In the language Dutch, a certain vowel sound is expressed as a combination of the glyphs 'i' and 'j'. The glyph 'j' however is exclusively used for consonants in the English language, unlike in Dutch, where 'j' serves a dual role. Human brains used to the English language cannot cope with glyph representations that express consonants in too long a sequence, without any space left for vowels. A combination like 'jkstr' in the English language is inevitably considered to be a spelling error, and corrective procedures automatically attempt to correct the spelling of such a word to a more acceptable combination. This happens frequently to the name 'Dijkstra', a name that originated in the Dutch natural language. The English eye cannot accept such a ridiculous combination of consonants (j k s t *and* r?), and desperately tries to resolve the situation. As a result, the glyphs 'i' and 'j' are frequently reversed. This is extremely unfortunate, as Djikstra is well known to be a primary moniker for the leader of the Insulationist faction within the Gheban coalition. The Insulationist faction is, of course, a prominent member the alliance that produced the Alien Whitespace Eating Nanovirus. Djikstra is therefore an enemy of the Python programming language. All that we stand for. All our hopes. All our dreams will come to naught if Djikstra gets his way. The moniker Djikstra is to be avoided in public utterances. PSU members can give themselves away and draw unwanted attention from the Insulationist overlord at this critical junction. What's worse, innocents might be caught up in this cosmic web of intrigue. While most innocents can of course be safely ignored, any innocent of temporal tension rating 17 and above (revised scale) should not be exposed to undue danger, as they may be essential for our time stream manipulations. It is therefore important to avoid the utterance of Djikstra's name at all costs! ADDENDUM FOR PSU MEMBERS OF CLASSES NE-100 AND HIGHER The relation between Djikstra and Dijkstra's name is of course not a coincidence. As was already evidenced in the famous "Considered Harmful" article, the great philosopher Dijkstra was on to a monumental cosmic secret: that reality is bound by a term rewriti -- http://mail.python.org/mailman/listinfo/python-list
informal #python2.8 channel on freenode
Fellow Pythoneers, I've started an informal channel "#python2.8" on freenode. It's to discuss the potential for a Python 2.8 version -- to see whether there is interest in it, what it could contain, how it could facilitate porting to Python 3, who would work on it, etc. If you are interested in constructive discussion about a Python 2.8, please join. I realize that if there is actual code created, and if it's not under the umbrella of the PSF, it couldn't be called "Python 2.8" due to trademark reasons. But that's premature - let's have some discussions first to see whether anything can happen. Hope to see you there for some discussion! Regards, Martijn -- https://mail.python.org/mailman/listinfo/python-list
Re: the Gravity of Python 2
On 01/07/2014 01:19 AM, Chris Angelico wrote: Can we get a run-down of everything that actually must be broken in 2.7 -> 3.3, that can't be backported via __future__, so we can start cherry-picking which bits to break in 2.8? The biggest one is going to be Unicode strings, for a large number of people (the print statement and division operators can be __future__'d, lots of other stuff got backported into 2.7). I'd be prepared to bet money that that one will NOT be broken in 2.8, meaning that it achieves nothing on that score. So how much easier will the migration actually be? That's a good question. I envision support for per-module upgrades, though I'm not 100% sure that it would work. This way a large project can incrementally start porting modules to the Python 3 unicode behavior. The 'future' module (python-future.org) effectively backports the Python 3 str and bytes into Python 2.7. The question is then what happens when they interact with Python 2 str and unicode. I'm speculating about the behavior of the 'future' module here, but here's what I could imagine. First the Python 3 behavior: py3str + py3str = py3str py3bytes + py3bytes = py3bytes py3str + py3bytes = error Then the behavior of when Python 3 str/bytes are mixed with Python 2 str and unicode: py3str + py2unicode = py2unicode py3str + py2str = py2unicode py3bytes + py2str = py2str Plus the regular old Python 2 behavior. I'm quite sure I could be getting something wrong; it's only a few days since I saw 'future' and started thinking along these lines. Regards, Martijn -- https://mail.python.org/mailman/listinfo/python-list
Re: the Gravity of Python 2
Hi there, I just tried this out with the future module to see what it actually does, and I got this: On 01/07/2014 01:54 PM, Martijn Faassen wrote: First the Python 3 behavior: py3str + py3str = py3str Yup, of course. py3bytes + py3bytes = py3bytes Again of course. py3str + py3bytes = error Yup, that's an error. Then the behavior of when Python 3 str/bytes are mixed with Python 2 str and unicode: py3str + py2unicode = py2unicode This didn't work as I expected; I'd have expected py2unicode for compatibility reasons, as py3str cannot be combined with py2str (but in fact it *can*, odd). py3str + py2str = py2unicode This in fact returns py3str, which I didn't expect either. py3bytes + py2str = py2str And this gets me py3bytes. I'll get in touch with the author of the 'future' module to try to understand why his reasoning is different from mine, i.e. where I'm wrong. Regards, Martijn -- https://mail.python.org/mailman/listinfo/python-list
Re: the Gravity of Python 2
Hi, I've posted a documentation issue to the 'future' module which includes a further evolution of my thinking. As I expected, the author of the 'future' module has thought this through more than I had: https://github.com/PythonCharmers/python-future/issues/27 To get back to a hypothetical Python 2.8, it could implement this kind of behavior, and I think it would help support incremental upgrades. As long as you're using Py 3 bytes and str in your code, you'll be aware of errors and be forced to think about it. Other Python code in the system can remain unchanged, and to the magic of ducktyping will continue to work. You can then tackle things incrementally. Regards, Martijn -- https://mail.python.org/mailman/listinfo/python-list
Re: the Gravity of Python 2
Hi there, On 01/07/2014 06:00 PM, Chris Angelico wrote: I'm still not sure how Python 2.8 needs to differ from 2.7. Maybe the touted upgrade path is simply a Python 2.7 installer plus a few handy libraries/modules that will now be preinstalled? These modules look great (I can't say, as I don't have a huge Py2 codebase to judge based on), and they presumably work on the existing Pythons. Well, in the original article I argue that it may be risky for the Python community to leave the large 2.7 projects behind because they tend to be the ones that pay us in the end. I also argue that for those projects to move anywhere, they need a clear, blessed, official, as simple as possible, incremental upgrade path. That's why I argue for a Python 2.8. Pointing out the 'future' module is existence proof that further incremental steps could be taken on top of what Python 2.7 already does. I may be that these points are wrong or should be weighed differently. It's possible that: * the risk of losing existing big 2.x projects is low, they'll port anyway, the money will keep flowing into our community, they won't look at other languages, etc. * these big 2.x projects are going to all find the 'future' module themselves and use it as incremental upgrade path, so there's no need for a new blessed Python 2.x. * the approach of the 'future' module turns out to be fatally flawed and/or doesn't really help with incremental upgrades after all. But that's how I reason about it, and how I weigh things. I think the current strategy is risky. Regards, Martijn -- https://mail.python.org/mailman/listinfo/python-list
Re: the Gravity of Python 2
On 01/08/2014 01:46 PM, Chris Angelico wrote: On Wed, Jan 8, 2014 at 11:36 PM, Martijn Faassen wrote: Well, in the original article I argue that it may be risky for the Python community to leave the large 2.7 projects behind because they tend to be the ones that pay us in the end. I also argue that for those projects to move anywhere, they need a clear, blessed, official, as simple as possible, incremental upgrade path. That's why I argue for a Python 2.8. Pointing out the 'future' module is existence proof that further incremental steps could be taken on top of what Python 2.7 already does. Yep, but suppose it were simply that the future module is blessed as the official, simple, incremental upgrade path. That doesn't violate PEP 404, it allows the future module to continue to be expanded without worrying about the PSF's schedules (more stuff might be added to it in response to Python 3.5, but this is all in the hands of future's maintainer), and it should be relatively simple to produce an installer that goes and grabs it. That would be better than nothing, but would break the: "upgrade path should be totally obvious" guideline. Also the core developers are generally not in the habit of blessing external projects except by taking them into the stdlib, so that'd be a first. As Mark Rosewater is fond of saying, restrictions breed creativity. Can the porting community take the PEP 404 restriction and be creative within it? I suspect it'll go a long way. How many actively maintained applications on Python 2.7 are being ported? Do we know? If not many, is this a problem? As problems also breed creativity. Regards, Martijn -- https://mail.python.org/mailman/listinfo/python-list
Re: the Gravity of Python 2
Hey, I'm pointing out possible improvements that Python 2.8 could offer that would help incremental porting efforts of applications. I'm pointing about that helping application developers move forward incrementally may be a worthwhile consideration. Like, there's money there. You can point out that 2.6 and 2.7 were already such releases, and I will then point out that many people *have* upgraded their applications to these releases. Is there now going to be a giant leap forward to Python 3 by these projects, or is the jump still too far? Opinions differ. On 01/08/2014 02:01 PM, Steven D'Aprano wrote: Adding 2.8 doesn't help. It just gives people another excuse to delay migrating. Then, in another two or three years, they'll demand 2.9, and put it off again. Then they'll insist that 15 years wasn't long enough to migrate their code, and demand 2.10. I can play this kind of rhetorical game too, including demands and such fun. Who is demanding who does what? It's not really a surprise that people expect there to be a compatible release of a programming language. We'll have to see whether the demand for it is strong enough to tear out community apart, or whether all will be right in the end. What's not fine though is people holding the rest of us back with their negativity and FUD that Python 3 is a mistake. That's not what I believe I've been doing. Though if people do this, is the Python community really so fragile it can't deal with a little bit of pushback? What's not fine is that people who think all is well tell the people who disagree to shut up. Maybe we should introduce the concept of "check your Python 3 privilege". Regards, Martijn -- https://mail.python.org/mailman/listinfo/python-list
Re: the Gravity of Python 2
Hey, On 01/08/2014 03:30 PM, Mark Lawrence wrote: But to be serious why not stick with 2.x if there's no compelling reason to move? Whatever happened to "if it ain't broke, don't fix it"? That's fine for static applications that don't have to change. Successful applications tend to grow new features over the years. It's not fun to do so if new capabilities are growing out of reach in Python 3 land. It's possible if enough features exist in Python 3 land bosses of successful applications will fund a port, with all the risks of introducing bugs that this entails. But a smoother upgrade path would help those applications more. And as I pointed out before, these applications are where a lot of money and development resources are coming from in our community. Of course it's possible my assessment of the importance of these applications, their development resources, and the bump a Python 3 port presents for them, is off. Regards, Martijn -- https://mail.python.org/mailman/listinfo/python-list
Re: ElementTree Namespace Prefixes
Jarek Zgoda wrote: [snip] >> It's a shame the default ns behavior in Elementtree is in such a poort >> staten. I'm surprised no one's forked Elementtree solely to fix this >> issue. > > There is at least one ElementTree API implementation that retains > prefixes, lxml.ETree. Go google for it. Just to make it explicitly clear, lxml is not a fork of ElementTree fork, but a reimplementation of the API on top of libxml2. ElementTree indeed retains prefixes, and since version 0.7 released earlier this way, it's also possible to get some control over generation of prefixes during element construction. You can find it here: http://codespeak.net/lxml Regards, Martijn -- http://mail.python.org/mailman/listinfo/python-list
