ArticlesShort version
What you’ve been searching for:
PyXML 0.8.4 for Python 2.6, Windows Installer (1,006 KB)
PyXML 0.8.4 for Python 2.7, Windows Installer (1,012 KB)
Rambling Version
So you are a Windows user and you want to install Python/XML (A.K.A. PyXML), but there is no version on Sourceforge since November 2004, when Python 2.4 was all the rage. It isn’t being maintained any more.
So you turn to your Python friends, and they say “Oh don’t use that. There are much better XML libraries now.” And you say “But the library I want to use uses ZSI which uses PyXML, and ZSI isn’t being maintained either.”
And your Python friends say “ZSI? Are you using SOAP? 2001 just called and they want their over-hyped protocol stack back.” And you say “Yeah, but I need to access a server that only provides SOAP, and someone has written a wrapper layer to it which, surprise, surprise, is no longer being maintained. Besides, the whole ‘the past called’ gag is a bit dated too, isn’t it?”
So they say “Ah, just install it with easy_install” and you look at them funny, because you are a Windows programmer, and they are Linux programmers, and that’s not the way you do things around here.
Either you decide to give it a go, or you decide to download the source directly and run ‘setup.py build’, and either way it complains about ‘vcvarsall.bat’ being missing, which is its way of saying “How am I supposed to compile this C code? Don’t you have Microsoft Visual Studio installed?” to which you say “No, I am a Python programmer now! The eighties called, and asked for their C compiler back, and I gave it to them.” but it isn’t listening to you, and neither are your Linux friends, because they don’t want to associate with someone who doesn’t have a C compiler built in to the operating system.
Then you hear a rumour about a free Visual Studio command-line compiler, and a free C compiler called gcc or MINGW or something. Sounds too hard, so you yell in frustration “All I want is a nice Windows installer with pre-built binaries? Hasn’t anyone on the internet built one for me?” and your Linux friends who were pretending they couldn’t hear you finally turn around and say “Wait, you are going to run a binary you just found somewhere on the net? Are you crazy? It could have all sorts of nasty code in there.” and you just look at them funny because that’s just the way you do things around here.
If this is you, I have a solution! I have built the PyXML distribution, ready to just install, linked at the top and bottom of this post. If you don’t trust me (and frankly, you shouldn’t), I have provided instructions on how to do it yourself.
Building It Yourself
(Much credit to psems’s instructions in this post.)
First, download PyXML 0.8.4 source. Extract it (with your favourite archive tool; I use 7zip) and extracted into a temp directory.
Now, follow these instructions heavily cribbed from this post:
1. Visit the MINGW sourceforge page:
2. Download & Run: Automated MinGW Installer (make sure you check the base, g++ and Make)
3. <Snipped>
4. Create (or edit): C:\Python26\Lib\distutils\distutils.cfg and add the following 2 lines:
[build]
compiler=mingw32
Okay, now go the command line, and get yourself into the temp directory.
Add MINGW to your path temporarily by typing PATH=%PATH%;c:\mingw\bin\
If Python 2.6.x isn’t already your path, do a similar command like: PATH=%PATH%;c:\Python26, or just type c:\python26\python in front of every command below.
(Or similarly for Python 2.7.x)
If you just want to install it, type:
setup.py build
setup.py install
This time there should be lots of output but no errors.
If you want to do what I did, and create a distributable installer type:
setup.py bdist_wininst
setup.py bdist
The first one contains an exe, which is what you wanted. The second one creates a zip, which some people prefer. You will find them in the dist subdirectory.
Once you have the exe, you know how to install it – good ol’ double-click! How embarrassing for the Linux people that they have to type “easy_install”, which means it is already far too hard for us Windows folks!
Check it worked by typing starting python and typing import xml.dom.ext.reader; it shouldn’t give an error.
The Results
PyXML 0.8.4 for Python 2.6, Windows Installer (1,006 KB)
PyXML 0.8.4 for Python 2.6, ZIP archive (1,310 KB)
PyXML 0.8.4 for Python 2.7, Windows Installer (1,012 KB)
PyXML 0.8.4 for Python 2.7, ZIP archive (1,316 KB)
Licence
It should be obvious, but I am not claiming any ownership of this code. Nor am I offering any warranties. It should be used subject to the copyright notices and licences included, which give credit to the people who actually contributed to the project.
All of the original code is available from Sourceforge.
Comment by configurator on October 31, 2009
I don’t understand something. A compiled executable can contain whatever code the untrustworthy developer wants, but so can the actual code. Do those Linux friends read and understand every line of code they download?
I’ve always been perplexed by this. The only times I download software from untrusted sources are code samples, in which case I download the source and read it anyway. Otherwise, I’d go for the binary anytime (and hope for the best)
Comment by Julian on October 31, 2009
It is a fair question and a complex area filled with lots of assumptions.
a) That bad code is easy to see if you are looking for it. I’ve seen code that designed to look innocuous at first perusal, but actually does bad things.
b) That the bad code isn’t hidden in layers you can’t see (Ken Thompson-style)
b) That sufficient eyeballs are available actually looking at the open source code. For popular Python packages, that seems fairly likely. If you are installing something esoteric that might not be true.
I think it is fair to say that downloading a binary from the site that also offers the original source is safer than downloading the binary from an untrusted third-party.
(As much as I would like the trust of random people who discover this site by search, I think the world would be a safer place if they treated random blogs with suspicion.)
Comment by John Y. on October 31, 2009
I am very amused by your narrative, and appreciative of your efforts. Surprisingly appreciative for someone who doesn’t actually use XML for anything, and thus most likely doesn’t (yet) have any use for PyXML.
I’m appreciative mainly because I’m also a Windows Python user who has deep misgivings about Cygwin but will use MinGW in a pinch. I don’t think you should put any pressure on yourself to “get over” your issues with Cygwin, because of what it aims to do, which is to turn your Windows machine into a quasi-Unix work-alike development environment.
From my point of view, the goal of MinGW is not terribly similar to that of Cygwin, though this is confused a bit because there are two flavors of MinGW: with and without MSYS. (Well, in classic Unix tradition, MinGW and MSYS are technically independent, but there is practically no point to MSYS without MinGW, and those who like MSYS will naturally assume that anyone who uses MinGW should want to use it with MSYS. Thus, when those people say “MinGW” they mean “MinGW with MSYS”.)
The more minimal flavor is of course MinGW without MSYS, and this is what I am reasonably comfortable with. In this setup, MinGW seems to be trying to just be a command-line compiler. Your Windows is still Windows, your command prompt is still essentially DOS. It’s closer to ’80s-style compilers for DOS.
MSYS corrupts this, and is (as I perceive it) part of the way towards Cygwin. So I believe you should continue to be wary of Cygwin, and perhaps be even more wary of MSYS (because it is sometimes insidiously portrayed as an essential part of MinGW). But as long as you keep your system MSYS-free, I think you shouldn’t have much trouble with MinGW.
Comment by Aristotle Pagaltzis on November 1, 2009
The idea that source code is safer than binaries is because truly innocuous source code is (very relatively!) easy to verify as such. In contrast, innocuous binaries are not easily so verified.
When the code isn’t easy to verify as innocuous, of course, then the complexity of examining source code is no different at the limit from the complexity of examining a binary – after all a binary too is just source code, it merely happens to be written in machine language. And any high-level language listing can be made just as difficult to comprehend as a large machine language listing.
The idea behind the assumption of the safety of source is that anyone who downloads it could inspect it. Not everyone will, obviously, but presumably a few people are going to – from which everyone else then benefits. Of course, whether this assumption turns out to be justified varies wildly from project to project.
So basically what happens when you offer up source code for download is that a number of factors come together to make it easier to increase the trust in it if it’s actually good code. However, contrary to what most people assume, having the source code does little to expose malevolent code as such.
Comment by Richard Atkins on November 1, 2009
Which of the various Python Windows runtimes is this binary going to work for? I know that the ActivePython 2.6.3.7 distribution I just installed is linked against MSVCR90.DLL, which as far as I know is not what a mingw built binary would link with without some coercion. If your mingw built DLL is linked to MSVCRT.DLL from Visual C++ 6 (the default) and you’re using it with ActivePython, then you’re going to have a bad time whenever the garbage collector wants to free some memory your DLL malloc’d. It’s incompatibilities like these in Subversion, Python and Apache that make using tools like Trac such a joy. C runtime DLL hell continues its evil work…
Comment by Julian on November 1, 2009
Richard,
Short version: I have no idea. You’ll have to look for yourself.
Longer version: I’ve never looked at the Python/C interface, but I would have thought the garbage collector would call the object’s __del__ method which would be responsible for calling the C code and telling it to clean up after itself. I wouldn’t have thought the garbage collector directly cleans up memory used by the DLL. I haven’t thought this through very far.
Comment by Chang on December 9, 2009
What do we do for a 64-bit version of PyXML in python 2.6?
Comment by hk on May 13, 2010
Oh oh oh you have just saved me. Three hours of PAIN solved with your simple installer. Thank you!!
Comment by Henry Keys on May 15, 2010
Py XML is a good program
I need him for help blender and crystal space to work together
Comment by Alex Benke on January 1, 2011
Julian, thank you so much for this, saved me a few hours for sure!
Comment by Julian on April 26, 2011
Updated with binaries for Python 2.7.x.
Comment by Nupta on June 23, 2011
Oh,Thx a lot,If I havn’t visited here,maybe I have gived it up
Comment by gustavo on July 17, 2011
tks a lot
i love you
Comment by nauj27 on August 10, 2011
Thank you very much. You saved my day.
Comment by Muhammad Bashir Al-Noimi on January 24, 2012
Thanks but I still get same error message when I tried to use it from SF.net which is:
error: compiling 'C:\Python26\lib\site-packages\_xmlplus\xpath\ParsedAbbreviatedRelativeLocationPath.py' failedSyntaxError: invalid syntax (ParsedAbbreviatedRelativeLocationPath.py, line31)
I think the problem related to “as” keyword.
Do you’ve any solution?
Comment by Julian on January 24, 2012
Sounds like you are stumbling over this bug in PyXML.
(Yes, “as” became a reserved word in Python 2.6.)
You may need to apply the patch described there.
Comment by tastypear on June 1, 2012
fcking awesome dude
Comment by Tran Khai Hoang on March 30, 2013
Have you tried build this on win 64, I did but no succeess
Comment by Julian on March 30, 2013
Sorry, Tran Khai Hoang, I can’t say that I have. I have never compiled any C for 64-bit Windows.
Comment by Codebold on July 7, 2014
Thanks for your efforts! Exactly what I was looking for…
Comment by Arne on July 5, 2016
Installation using the installer is aborted on Windows 10 64bit without a meaningless errormessage, basically “Its not running, screw it, will not install, regards, Windows”.
What now? Just slam the zip content into phyton27, even the topmost subfolder in the zip was python26. Is this working?
Comment by Arne on July 5, 2016
all Web Mentions are dead links.
Comment by Julian on July 5, 2016
Arne,
I’m afraid these are 32-bit installations.
I’m not surprised it doesn’t work on 64-bit installations, but a meaningful error message would have been nice.
You’ll need to rebuild them as 64-bit. I have no experience with that.
My supplier finally moved over to use REST, at about the same time my project that was mothballed, so I don’t have any use for PyXML any more.
Comment by Julian on July 5, 2016
I removed the broken Web Mentions, but it is the nature of the web that these things are going to be everywhere.