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]{tempfil
e}
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

[ Post a follow-up to this message ]