Nick wrote:
Jim Gallacher wrote:
Are you sure there is anything to correct? In both cases, the object
has the same methods available for manipulating files (t.write('a'),
for example). They are not the same type of object, so they have
different dir() output, but don't they have the same functionality?
What specifically gets broken in util.FieldStorage?
No, I'm not sure. Now that I play around with it I'm not sure I
understand the problem at all. Perhaps Nick could elaborate?
[...]
Other than the fact that "isinstance(t, FileType): returns False, I
don't see the problem. Nick?
There's 2 issues. I think a documentation change in mod_python where it
states that a file object is returned to say a file-like object instead
is one. That's easy.
How about this? (Excuse the LateX)
\class{Field} instances have the following attributes:
...
\begin{memberdesc}{file}
This is a file-like object. For file uploads it points to a
\class{TemporaryFile} instance. (For more information see
TemporaryFile in the standard python
\citetitle[http://docs.python.org/lib/module-tempfile.html]{tempfile}
module).
For simple values, it is a \class{StringIO} object, so you
can read simple string values via this attribute instead of using
the \member{value} attribute as well.
\end{memberdesc}
The other is that there isn't an easy way to tell whether what you've
got in the field is a file or not, because no matter what you've got
something that "looks" like a file. Under the current documentation you
could have tried isinstance(field.file, file), but that's clearly not
the right thing to do since TemporaryFile doesn't necessarily return an
actual file object. I accept that, but there needs to be an easy way to
know what type the Field object value is -- string or file. Checking
filename or disposition is obtuse, and there may not necessarily be a
file name even if you get a file.
So that's my problem, or at least that's where the conversation has led
me. Is there an easy way to figure out what you've got other than
process of elimination?
I guess where I'm getting hung-up is in trying to understand why this is
important. Why do you need to know if it's a file object or a file-like
object? You also seem to switch the argument a little in the above.
First you're talking about file vs. file-like object, and then file vs
string. When you say string do you mean StringIO or StringField. If it's
just a case of StringField vs any of the file-like objects, why not just
use hasattr(field_thing, 'read')?
If you really must distinguish between these and want to avoid using the
process of elimination then I guess we are back to adding an attribute
such as is_file to the Field class. Your code will still have to deal
with the circumstance of FieldClass.__getitem__() returning a
StringField which will not have this attribute.
I don't know what it is about this issue, but every time I look at it I
feel like my IQ has dropped a couple of points. Since this is a limited
resource already I don't want to lose any more of it.
Regards,
Jim
