I think I solved all my three questions for myself now ...
On Fri, 29 Jun, Stefan Bellon wrote:
> 1) The above code seems to work ok when using the "import" statement,
>but it does not when using the dynamic __import__ function. If
>using it that way, I get:
>
>
>> I think all you are missing is familarity with Python, but I too don't
>> like one-liners simply for their own sake.
>>
>
> I guess that's it. The first one reads more like a textbook example which
> is about where I am at. Is there any speed benefit from the one liner?
Almost definitely. But you can check yourself by using the timeit module.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
Stefan Behnel wrote:
> Note that you have to merge character sequences yourself in SAX.
> There is no guarantee into how many chunks the textual context of a single tag
^ content ^
> is broken before it is passed to the characters() S
ed lxml, maybe lxml.html (which will be in lxml 2.0), or the Atom
implementation on top of lxml.etree.
http://codespeak.net/lxml
http://codespeak.net/svn/lxml/branch/html/
https://svn.openplans.org/svn/TaggerClient/trunk/taggerclient/atom.py
Hope it helps,
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
Please provide a bit
more of the output, anything that might be helpful to understand the problem.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
esides, this is completely off-topic spam.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
require parallelism in the interpreter first? Mind the GIL...
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
find a free command-line validator that I could
> invoke with subprocess, but I haven't even had luck with that.
lxml has statically built Windows binaries available for version 1.2.1, those
for 1.3.2 should become available soon. It supports RelaxNG, XMLSchema, DTDs
and (with a little pa
ml/branch/html/doc/cssselect.txt
Have fun,
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
XML anyway. Version 1.2.1 has
binaries for Windows (and 1.3.2 will likely get them soon).
http://codespeak.net/lxml/
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
what you want to do with this document, but you might want to
consider using lxml.etree to handle it:
>>> from lxml import etree
>>> tree = etree.parse("myfile.xml")
>>> for random in tree.getiterator("random"):
... for li in random:
Any ideas?
>
> Encode before writing. Assuming you want to use utf-8:
> zip.writestr('content.xml', content.toxml().encode('utf-8'))
Unless, obviously, you were serialising to a non-utf8 encoding. But since the
"toxml()" method seems to return unicode here (whi
gt;
> Or c) the user forgot to specify the encoding= parameter in toxml().
Then I would expect it a) to serialise to a UTF-8 compatible encoding that
does not require a declaration (which excludes Python unicode) or b) to be
broken. :)
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
o get there. If they do not want to - unlikely, unless someone else
takes up the work. But it's definitely easier if the authors decide to put it
in.
Besides, why would you assume any dependency headaches? There's EasyInstall
and setuptools if you need them.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
chr(0x80))
> f.seek(0,2)
> f.close()
> """
>
> Can I use the seek() and write() methods in a similar way to remove
> the first byte? For whatever reason I can't seem to make it work
> myself. Thanks again.
Funny. I just happened to read ESR's "how to ask questions the smart way" and
your posts match quite a few of the examples. :)
No, you can't. Steven's solution is what I'd go for.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
maining file has to be copied around to fill
the sectors). But since that is a rather rare use case that most people would
prefer being handled in a safe rather than space-optimal way, I don't see the
need for such a function.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
quot; module first to
remove any annoying content. It's not released yet but available in a branch:
http://codespeak.net/svn/lxml/branch/html/
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
put the new string in. So it is actually much more efficient to use
PyDict_SetItem() directly in your case.
If you want to temporarily create a char* from a string and you know that the
char content won't be modified, use the PyString_FROM_STRING macro, which just
returns the internal pointer.
Stefa
ts own refcount increase internally when it
stores the value, so don't bother about it at all when you think about what
refcounts you have to increase or decrease.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
any further ideas on
how to make it even more versatile than it already is.
For lxml is general, see:
http://codespeak.net/lxml/
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
acto HTML
>> parser for Python:
>
> Nope. It's the defacto parser for HTML-like tag soup !-)
Very true. As long as you're dealing with something that looks pretty much
like HTML, I actually don't think you can beat lxml.html (and it's still
getting better every day).
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
yield a well-formed document.
http://codespeak.net/lxml/
http://codespeak.net/lxml/dev/parsing.html
BTW, parsing and serialising it back to a string is most likely dominated by
the time it takes to transfer the document over the network, so it will not be
much slower than reading it using urlopen() and the like.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
Hi,
Leonard J. Reder wrote:
> Stefan Behnel wrote:
>> http://codespeak.net/lxml/objectify.html
>
> Looks like this stuff might do what I want. Need to work through the
> example.
>
> Are you the author?
Yup! :)
> Why is this better then using gnossis?
lxml is f
ich leads us to
> the same question as above.
>
> Can anyone tell me what I am missing here?
This?
http://docs.python.org/ref/attribute-access.html
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
[EMAIL PROTECTED] schrieb:
> Thanks guys. But I think IronPython only works on Windows machine, but
> I am using a Sun machine.
Isn't there a mono port for Sun?
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
e pyXPCOM to accomplish this job.
I've never used it, but I doubt Gecko would yield substantially better results
than any of the three above. You're dealing with broken data here, so it just
depends on your input which one of them wins.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
In comp.lang.lisp sturlamolden <[EMAIL PROTECTED]> wrote:
> I am curious to know how it performs in comparison to CPython and an
> efficient compiled Lisp like CMUCL. Speed is a major problem with
You are not allowed to publish .NET benchmarks. :-)
--
Web (en): http://www.no-spoon.de/ -*- Web (
list from the binding /
> object written in C.
>
> Any suggestions or hints about this?
Use Pyrex. It's a Python-like language that was designed to write extension
modules in C and it's great for writing wrappers.
http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/
An exa
theme.
Not currently supported, only document internal DTD references are used. But
you can always validate the document *after* parsing, be it with DTD,
XMLSchema or RNG.
BTW, adding this would be straight forward. The implementation is there, it's
just not available at the API level (and I'm not sure enough how it should
look like...)
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
should say
input_xml = open(file_input,'r').read()
> input_xml.replace('localId','dataPackageId')
> This gives error ---> AttributeError: 'file'
> object has no attribute 'replace'
> Can someone help me .
> Thanks
>
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
ilities" you "wouldn't have with Pyrex".
We used Pyrex to write lxml, a wrapper around the huge API of libxml2 and
libxslt. It's some 11000 lines of Pyrex code by now, but the generated C code
is some 67000 lines in total. Even if it's somewhat verbose and generic in
arch engine to answer your own question? Usually
much faster for this kind of request.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
atch is needed?
>>> Thanks
>> http://groups.google.com/group/comp.lang.python/browse_frm/thread/e09...
>>
>> Read carefully.- Hide quoted text -
>>
>> - Show quoted text -
>
> The commands are given in that link are more so for a linux system .I
> am developing in windows.how should i go about to make it work
As said: read carefully.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
have a clue what this is good for. However,
someone who is fluent enough in German could guess from the names what this
does.
I do not think non-ASCII characters make this 'problem' any worse. So I must
ask people to restrict their comments to the actual problem that this PEP is
trying to solve.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
iers are always *typable* by people who have access to latin
characters on their keyboard. A rather small advantage, I'd say.
The capability of a Unicode-aware language to express non-English identifiers
in a non-ASCII encoding totally makes sense to me.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
could.
Luckily, you will never be able to touch every program in the world.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
e I think about it, the more I believe that this restriction should be
lifted. 'Any' non-ASCII identifier should be allowed where developers decide
that it makes sense.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
ode that is posted to a public OS project site. Note that I didn't say "ASCII
identifiers" but plain english identifiers. All other code should use the
language and encoding that fits its environment best.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
ish.
>
> --python -c "print ''.join([chr(154 - ord(c)) for c in
> 'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
Oh well, why did *that* code ever go public?
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
Eric Brunel wrote:
> On Sun, 13 May 2007 21:10:46 +0200, Stefan Behnel
> <[EMAIL PROTECTED]> wrote:
> [snip]
>> Now, I am not a strong supporter (most public code will use English
>> identifiers anyway)
>
> How will you guarantee that? I'm quite convince
project level rather
than forbidding it at the language level. This makes sense as it moves the
power into the hands of those people who actually use it, not those who
designed the language.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
y language in CS.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
Eric Brunel wrote:
> On Mon, 14 May 2007 11:00:29 +0200, Stefan Behnel
>> Any chance there are still kanji-enabled programmes around that were
>> not hit
>> by the bomb in this scenario? They might still be able to help you get
>> the
>> code "public&quo
on't be able to contribute much to a project that already
> uses, say, Chinese for comments and strings. Even if I manage to
> display the source code correctly here, still I won't understand much
> of it. So I'm not losing much by allowing them to use Chinese for
> identifiers too.
> And whether it was a mistake on their part not to choose an "English
> only, ascii only" policy it's their call, not ours, IMHO.
Very well written.
+1
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
hon":
>
>> IronPython will compile files whose identifiers use non-ASCII
>> characters if the file has an encoding comment such as "# -*- coding:
>> utf-8 -*-". CPython will not compile such a file in any case.
Sounds like CPython would better follow IronPython here.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
Vyacheslav Maslov wrote:
> I need multi threaded version of SimpleXMLRPCServer. Does python library
> already have implementation of this one? Or i need to implement multi
> threading by myself?
>
> Which way is the simpliest?
Twisted has XML-RPC support:
http://twistedmatrix.co
Jarek Zgoda schrieb:
> Stefan Behnel napisał(a):
>
>>> While I can read the code with Hebrew, Russian or Greek names
>>> transliterated to ASCII, I would not be able to read such code in native.
>> Then maybe it was code that was not meant to be read by you?
>
Marc 'BlackJack' Rintsch schrieb:
> In <[EMAIL PROTECTED]>, Michel Claveau
> wrote:
>
>> And Il1 O0 ?
>
> Hm, we should ban digits from identifier names. :-)
Ah, good idea - and capital letters also. After all, they are rare enough in
English to just
Paul Rubin wrote:
> Stefan Behnel <[EMAIL PROTECTED]> writes:
>> But then, where's the problem? Just stick to accepting only patches that are
>> plain ASCII *for your particular project*.
>
> There is no feature that has ever been proposed for Python, that
Paul Rubin wrote:
> Stefan Behnel <[EMAIL PROTECTED]> writes:
>> But then, where's the problem? Just stick to accepting only patches that are
>> plain ASCII *for your particular project*.
>
> There is no feature that has ever been proposed for Python, that
is. cool.
>
> Yeah, right... The problems begin...
>
> Joke aside, this just means that I won't ever be able to program math in
> ADA, because I have absolutely no idea on how to do a 'pi' character on
> my keyboard.
Ah, you'll learn. :)
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
and-replace
with english words easier in case it ever really becomes a requirement.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
> Typing them is not the only problem. They might not even *display*
> correctly if you don't happen to use a font that supports them.
Sounds like high time for an editor that supports the project team in their
work, don't you think?
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
ittedly, it's done in Java, but why should Python fail to support unicode
identifiers in the way Java does?
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
pecified in a large German document, in
perfect English terms?
And: why would you want to do that?
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
René Fleschenberg wrote:
> Stefan Behnel schrieb:
>> René Fleschenberg wrote:
>>> you have failed to do that, in my opinion. All you have presented are
>>> vague notions of rare and isolated use-cases.
>> I don't think software development at one of
René Fleschenberg wrote:
> Stefan Behnel schrieb:
>> Sounds like high time for an editor that supports the project team in their
>> work, don't you think?
>
> I think your argument about "isolated projects" is flawed. It is not at
> all unusual for code that
René Fleschenberg wrote:
> Stefan Behnel schrieb:
>>>> Admittedly, it's done in Java, but why should Python fail to support
>>>> unicode
>>>> identifiers in the way Java does?
>>> Your example does not prove much. The fact that some people us
t would be bad about allowing a project to decide about the best and
clearest way to name identifiers? And: if it's not a project you will ever get
in touch with - what do you care?
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
René Fleschenberg wrote:
> Now you are starting to troll?
Sorry, I was omitting the signs of sarcasm as I thought that would be clear
from the previous posts in this thread (which I was citing).
Feel free to re-read my post.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
a project domain
c) chosen according to project guidelines
> And even if you consider that more clear and readable
> than English-only Python code, the fact that it discourages code sharing
> remains.
So? Is that bad? Can't OpenSource and closed source happily live together?
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
life?
This kind of argument is just plain off-topic.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
René Fleschenberg wrote:
> Stefan Behnel schrieb:
>> And: if it's not a project you will ever getin touch with - what do
>> you care?
>
> I just fear that I *will* get in touch with identifiers using non-ASCII
> symbols if this PEP is implemented.
That's easy
"non-techies" talk about it.
That's about all I could extract as arguments.
To me, this sounds pretty much like something people and projects could handle
on their own once the PEP is accepted.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
e not completely
synonymous) English word instead of the transliterated German one.
So, yes, in a way, the code quality in these projects suffers from developers
not being able to freely write Unicode identifiers.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
Eric Brunel wrote:
> On Tue, 15 May 2007 15:57:32 +0200, Stefan Behnel
>> In-house developers are rather for this PEP as they see the advantage of
>> expressing concepts in the way the "non-techies" talk about it.
>
> No: I *am* an "in-house" developer.
Paul Boddie wrote:
> On 15 May, 16:39, Stefan Behnel <[EMAIL PROTECTED]> wrote:
>> It's difficult to extract this analysis from Java. Most people I know from
>> the
>> Java world do not use this feature as it is error prone. Java does not have
>> support for
n India who learn the
superball results by heart before they go to their cubicle, just to keep
north-american callers from realising they are not connected to the shop
around the corner.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
hough not necessarily) English.
Note that adherence to a specific script can easily checked programmatically
through Unicode ranges - if the need ever arises.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
René Fleschenberg wrote:
> We all know what the PEP is about (we can read).
BTW: who is this "we" if it doesn't include you?
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
s on those who
> support the PEP.
The main problem here seems to be proving the need of something to people who
do not need it themselves. So, if a simple "but I need it because a, b, c" is
not enough, what good is any further prove?
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
stdlib
and keywords on one hand and identifiers on the other hand. Ignoring arguments
does not make them any less true.
So, the problem is partly tackled by the people who face it by writing
degenerated transliterations and language mix in identifiers, but it would be
*solved* by means of the lan
display on
> my screen correctly, I am not as fscked as badly as when an identifier
> does not display (e.g. in a traceback).
Then get tools that match your working environment.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
s PEP was that it seemed to be impossible to
find either transliterated identifiers in code or native identifiers in Java
code using a web search. So it is very unlikely that you will need to upgrade
your handheld as it is very unlikely for you to stumble into such code.
Stefan
--
http://mail.p
t would be the right way around. Support
Unicode by default, but allow those who require the lowest common denominator
to enforce it.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
René Fleschenberg wrote:
> Stefan Behnel schrieb:
>>>> - Non-english speakers can not create or understand
>>>> english identifiers hence can't create good code nor
>>>> easily grok existing code.
>>> I agree that this is a problem, but ple
No. Make "ASCII-only" an interpreter option that can be turned on for the
cases where it is really required.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
efits.
>
>> I love Python because it does not dictate how to do things.
>> I do not need a ASCII-Dictator, I can judge myself when to use this
>> feature and when to avoid it, like any other feature.
>
> *That* logic can be used to justify the introduction of *any* feature.
*Your* logic can be used to justify dropping *any* feature.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
Hendrik van Rooyen wrote:
> "Beautiful is better than ugly"
Good point. Today's transliteration of German words into ASCII identifiers
definitely looks ugly. Time for this PEP to be accepted.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
[EMAIL PROTECTED] wrote:
> Stefan Behnel wrote:
>> [EMAIL PROTECTED] wrote:
>>> I even sometimes
>>> read code snippets on email lists and websites from my handheld, which
>>> is sadly still memory-limited enough that I'm really unlikely to
>>>
René Fleschenberg wrote:
> Stefan Behnel schrieb:
>>> Now, very special environments (what I called "rare and isolated"
>>> earlier) like special learning environments for children are a different
>>> matter. It should be ok if you have to use a specially
dmitrey wrote:
> howto check does module 'asdf' exist (is available for import) or no?
Walk through sys.path and find it yourself?
> (without try/cache of course)
Why is the obvious (and most common) try/import/catch solution "of course" out?
Stefan
--
http://mail.p
t;> zAppointments.appointment.begin = 1179775800
>>> zAppointments.appointment.duration = 1800
>>> print etree.tostring(zAppointments, pretty_print=True)
1179775800
1800
Pretty much what one would expect.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
objectify.ObjectifyElementClassLookup()
parser.setElementClassLookup(lookup)
# parse
parent = etree.parse("options.xml", parser)
# get to work
option1 = parent.option1
...
# or, if you prefer dictionaries:
options = vars(parent)
for key, value in options.items():
print key, ":", value
Have fun,
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
;)
Or try lxml.etree instead, it's ET compatible but has very good support for
PIs starting with 1.3beta.
http://codespeak.net/lxml/dev/
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
x27;{':
el.tag = el.tag.split('}', 1)[1]
That should do the job.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
DOM, but if you want to get real work done with XML, lxml is
what you actually want.
http://codespeak.net/lxml/dev/
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
> Character data: u'\n'
> Character data: u'EAFLTQKQKVGELKDDDFEKISELGAGNGGVVFKVSHKPSGLVMARKLIH'
> ...
> End element: sequence
> ...
>
> Is there a way to have the character data together in one string? I
> guess it should not be difficult, but I can't do it. Each time the
> parse reads a line, return a line, and I want to have it in one
> variable.
Any reason you are using expat and not cElementTree's iterparse?
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
d BSD
license (see http://www.opensource.org/licenses/bsd-license.php ).
Stefan
--
Dr.-Ing. Stefan Schwarzer
SSchwarzer.com - Softwareentwicklung für Technik und Wissenschaft
http://sschwarzer.com
--
http://mail.python.org/mailman/listinfo/python-list
a file? Using your browser? Maybe that messed it
up? Or did you edit it with an Editor that doesn't understand UTF-8?
If you want to extract the interesting stuff programmatically, you can use
lxml.etree. It's ElementTree compatible, but it can parse right from HTTP URLs
and it supports XPath for selecting stuff.
http://codespeak.net/lxml/
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
UTF-8 and/or XML when you edit it (i.e.: use an editor).
Make sure the XML file is well-formed (use e.g. xmllint) when you're save it.
Otherwise, no XML parser will accept it.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
ction for removing junk from HTML
pages.
The down-side is: there's no official release yet, you currently have to build
it from SVN branch sources. But there will soon be an official alpha release
of lxml 2.0 which will include it.
http://codespeak.net/lxml/
http://codespeak.net/svn/lx
Stefan Scholl wrote:
> After an hour searching for a potential bug in XML parsing
> (PyXML), after updating from 2.4 to 2.5, I found this one:
>
> $ python2.5
> Python 2.5 (release25-maint, Dec 9 2006, 14:35:53)
> [GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-20)] on l
es this happen - on the script side - I write the exact
> same strings, of content with supposedly, same encoding, so why the
> encoding is different?
Read the mail. It's not the encoding, it's the "" which does not get
through as a tag in the first file.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
Stefan Behnel <[EMAIL PROTECTED]> wrote:
> The XML is *not* well-formed if you pass Python unicode instead of a byte
> encoded string. Read the XML spec.
Pointers, please.
Last time I read that part of the spec was when a customer's
consulting company switched to ISO-8859-
Stefan Scholl wrote:
> Stefan Behnel <[EMAIL PROTECTED]> wrote:
>> Stefan Scholl wrote:
>>> Stefan Behnel <[EMAIL PROTECTED]> wrote:
>>>> Stefan Scholl wrote:
>>>>> Well, http://docs.python.org/lib/module-xml.sax.html is missing
Stefan Behnel <[EMAIL PROTECTED]> wrote:
> Stefan Scholl wrote:
>> Well, http://docs.python.org/lib/module-xml.sax.html is missing
>> the fact, that I can't use Unicode with parseString().
>>
>> This parseString() uses cStringIO.
>
> Well, Python un
Stefan Behnel <[EMAIL PROTECTED]> wrote:
> Stefan Scholl wrote:
>> After an hour searching for a potential bug in XML parsing
>> (PyXML), after updating from 2.4 to 2.5, I found this one:
>>
>> $ python2.5
>> Python 2.5 (release25-maint, Dec 9 2006, 14:35
Stefan Scholl wrote:
> Well, http://docs.python.org/lib/module-xml.sax.html is missing
> the fact, that I can't use Unicode with parseString().
>
> This parseString() uses cStringIO.
Well, Python unicode is not a valid *byte* encoding for XML.
lxml.etree can parse unicode, i
After an hour searching for a potential bug in XML parsing
(PyXML), after updating from 2.4 to 2.5, I found this one:
$ python2.5
Python 2.5 (release25-maint, Dec 9 2006, 14:35:53)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-20)] on linux2
Type "help", "copyright", "credits" or "license" for
801 - 900 of 2239 matches
Mail list logo
