Right, that's exactly what I'm having to do; I was thinking though that
mod_python should present a consistent interface, even if Python doesn't.
And, it is a bug in Python, even if it's a documentation bug (which claims
that the behavior of fdopen is to return a file object). I disagree that
documenting this fact in mod_python without changing the code doesn't amount
to saying you don't support Windows. It just means you support Windows to
the extent that Python itself does.
Nick
Indrek Järve wrote:
This behaviour has been with Python for quite a while, so claiming it's
simply a Python bug will be the same as declaring we don't support Windows.
Our company's software that runs on Windows and uses mod_python simply
patches util.py with the following change:
227c227
< if isinstance(item.file, FileType):
---
> if isinstance(item.file, FileType) or
(hasattr(item.file, 'file') and isinstance(item.file.file, FileType)):
I haven't tried this with mp32 yet (we're still running on Python 2.3
and I haven't had time to investigate how to compile mp on Windows), but
on 3.0/3.1 it appears to work just fine for our customers.
Best regards,
Indrek Järve
Inversion Software OÜ
Nick wrote:
More info:
python 2.4.2 on Linux:
>>> import tempfile
>>> t = tempfile.TemporaryFile()
>>> t
<open file '<fdopen>', mode 'w+b' at 0xb7df07b8>
>>> type(t)
<type 'file'>
>>> dir(t)
['__class__', '__delattr__', '__doc__', '__getattribute__',
'__hash__', '__init__', '__iter__', '__new__', '__reduce__',
'__reduce_ex__', '__repr__', '__setattr__', '__str__', 'close',
'closed', 'encoding', 'fileno', 'flush', 'isatty', 'mode', 'name',
'newlines', 'next', 'read', 'readinto', 'readline', 'readlines',
'seek', 'softspace', 'tell', 'truncate', 'write', 'writelines',
'xreadlines']
python 2.4.1 on windows:
>>> import tempfile
>>> t = tempfile.TemporaryFile()
>>> t
<open file '<fdopen>', mode 'w+b' at 0x0099FBA8>
>>> type(t)
<type 'instance'>
>>> dir(t)
['__doc__', '__getattr__', '__init__', '__module__', '__repr__',
'close_called', 'file', 'name']
So this is an inconsistency within Python. Should mod_python attempt
to correct it, or just claim a Python bug?
Nick
Nick wrote:
This may be a Python Windows thing, but it shows up in mod_python:
When using util.FieldStorage on multipart/form-data encoded POST data
containing a file, in Linux a field.file will yield a file object
(actually a subclass of file), but in Windows you have to get the
file object through field.file.file. This probably has something to
do with the fact that Windows' implementation of
tempfile.TemporaryFile is different from Linux, but it should be made
consistent in the mod_python interface.
Nick
Jim Gallacher wrote:
A new mod_python 3.2.3 beta tarball is now available for testing. A
Windows binary is also available.
This release is similar to 3.2.2b but fixes a couple a small issues
where a non-threaded python is used.
Here are the rules:
In order for a file to be officially announced, it has to be tested by
developers on the dev list. Anyone subscribed to this list can (and
should feel obligated to :-) ) test it, and provide feedback *to _this_
list*! (Not the [EMAIL PROTECTED] list, and preferably not me
personally).
The files are (temporarily) available here:
http://www.modpython.org/dist/
Please download it, then do the usual
$ ./configure --with-apxs=/wherever/it/is
$ make
$ (su)
# make install
Then (as non-root user!)
$ cd test
$ python test.py
And see if any tests fail. If they pass, send a +1 to the list, if they
fail, send the details (the versions of OS, Python and Apache, the test
output, and suggestions, if any).
Thank you,
Jim Gallacher
