| Jim Gallacher 2005-10-28, 5:31 pm |
| Nick wrote:
> Jim Gallacher wrote:
>
>
> [...]
>
>
>
> 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
|