Yesterday I let IronPython battle it out with TileCache, which was written for CPython and CGI. IronPython was stumbling — not seeming like a drop-in replacement for CPython yet — but I didn’t quite call the fight. I wanted to port TileCache’s CGI library calls to ASP.NET calls and see what I came up with.
After trivially porting TileCache’s CGI code, I discovered a new issue. IronPython’s lacks support for ”os.access.”. TileCache requires “os.access”. I’m not sure where this method normally lives. Its not defined in the “os” module of the Standard Library, but it works from CPython. AFAIK, its magic.
With a bit more research, and I stumbled upon FePy. “The FePy project aims to provide enhancements and add-ons for IronPython, an implementation of Python programming language.” They’ve already addressed my “hashlib” problem, providing a custom .NET module for it and for “socket.” They’ve also identified and patched 3 issues in IronPython, and 6 issues in the Python Standard Library when used with IronPython.
FePy’s patches should fix my issue. They’ve added “os.access” directly into the IronPython DLL. However, FePy lists their patched IronPython DLL version as 1.1, while ASP.NET Futures seems to use a Version 2.0. The thought ”with a little more effort, I can make this work” was beginning to feel familiar. I’ll wait till FePy moves to 2.0.
Winners: the FePy developers, notably Seo Sanghyeon, for relentlessly discovering and fixing IronPython bugs before MS can
Losers: IronPython, for stumbling twice on a mere 44k of code (+400k of relevant, standard libraries)
June 19, 2007 at 11:39 am |
‘os.access’ is documented here:
http://docs.python.org/lib/os-file-dir.html
Interesting exploration by the way.
Fuzzyman
June 19, 2007 at 12:17 pm |
I would assume that the ‘os.access’ method is brought in by “from posix import *” on CPython, which seems to have the access method — the reason for using os.access is that it should work on all platforms. The top of os.py in CPython has imports for ‘nt’, ‘mac’, ‘ce’, ‘riscos’, and ‘posix’ — I’m guessing that the IronPython equivalent is missing those?
There must be some method of determining whether a file exists: if you wanted to, you could create a subclass of DiskCache (IronPythonDiskCache) and replace the __init__, __set__ and __delete__ methods. (If os.makedir is also missing, you might need to replace the attemptLock function too.)
Also, I’m not sure which 44k of code you’re talking about, but the TileCache Python files (minus examples, docs, etc.) are only 1200:
disciplina:~/tilecache-1.8.1/TileCache crschmidt$ ls
Cache.py Client.py Layer.py Service.py __init__.py
disciplina:~/tilecache-1.8.1/TileCache crschmidt$ wc -l *
154 Cache.py
115 Client.py
418 Layer.py
526 Service.py
5 __init__.py
1218 total
So it’s even worse than you suspected
Out of curiosity, where is _hashlib getting imported from? Is it something we can drop out of TileCache in the main branch? I’d like to TC and make it work on IronPython out of the box if possible, rather than having a forked project — if there’s ways we can test for IronPython and change some of our behavior, I’d love to see them.
June 19, 2007 at 8:01 pm |
Christopher,
Urllib2 uses both hashlib and sockets. Neither work right in IronPython, and I can’t seem to get them working with FePy either. I replaced “os.access” calls with its partial equivalent “os.path.exists” (which pulls from ntpath.py on windows). That worked enough to validate that sockets was an issue. Even pointing at FePy’s libs, I can’t reference “socket._fileobject.” I can see the code, and FePy talks about fixing this, but I’m clueless as to what I’m doing wrong.
Basically, I’m not sure IronPython support in TileCache is worth worrying about yet. In 6 months, all these issues should be resolved, and things “just work”.
June 19, 2007 at 8:03 pm |
Oh, and 44k meant 44kB, not 44,000 lines or 44 kilos of code. 44 kilos is a *lot of code*!