I suppose I should probably weigh in over here. For those who don't
know, I worked on much of Django's file handling, refactoring
FileField, adding storage options and standardizing the File interface
across models, forms, storage and uploads. If there are methods
missing, I'm almost certainly the man to blame.
First, I want to point out one thing: adding readline() is different
from supporting a catch-all for any methods we might have missed. The
arguments for each are quite different, and this thread has
transitioned from one to the other, making things a bit murky. With
that in mind, I'll slpit the rest of this email into two parts,
addressing each issue.
readline()
I'm not opposed to adding readline(). It's part of the standard file
protocol, and it can be added even without the underlying file needing
to support it. After all, iterating over the file already yields one
line at a time, so we could just stop after the first line is
retrieved. That said, you can also do that yourself, currently.
for line in file:
is_valid = validate_csv_format(line)
break
It's not the prettiest, but it's a reasonable workaround in the
absence of an explicit readline(). In fact, I'd much rather using a
Python approach to readline() that does something similar, rather than
simply deferring to the _file attribute. That way, we're more able to
make sure it's there for other objects that might not implement it
directly. As long as the file is iterable, and the iterator works the
way the protocol describes, a simple Python method will work just
fine.
def readline(self):
for line in self:
return line
Other methods
First, I'll be clear. Not all the missing methods were forgotten.
readline() probably was overlooked, but that's simply because nobody
had expressed a need for it at the time, but I want to make it clear
that Malcolm was right: not all methods make sense in all situations.
We had a lot of back and forth with seek() and tell(), for instance,
because our chunking mechanism for file access assumes content will
always only be read from start to finish. This caused problems with
the zipfile module, because ZIP files don't work that way.
One of the main things we're trying to keep in mind is consistency.
Much line Django's model lookup API should support all features (or as
many as humanly possible) across all available databases, I'd like to
make sure that the provided file methods work on as many file-like
objects as possible. That's made harder by the fact that there's no
finite list of supported file objects like there is for supported
databases. In the end, it may prove to be a losing battle, but I'd
rather not give up on it quite yet, and that's exactly what deferring
to the wrapped file object feels like to me.
In general, I'd like to see any new methods receive a "yes" to each of
the following questions before being implemented in core. I'm not a
core developer, so I don't have any power to enforce this, but here
they are, all the same.
1. Have people actually expressed interest in making it available?
2. Does it make sense in the context of a web application?
3. Can it be implemented in a way that's equally supported across true
files, storage-backed files and anonymous (StringIO-type) files?
As you can see, readline() passes all of these tests. Others, like
truncate(), don't. Just for reference, consider implementing
truncate() on files backed by a storage backend. In order to work
properly for things like S3, you'd need to actually read the specified
number of bytes from the beginning of the file (over the web), then
write them back out (again, over the web) in order to achieve the
documented behavior. That's hardly what I'd call "equally supported"
alongside native filesystem files which have OS functions to do that
directly.
Anyway, those are my thoughts on the subject.
-Gul
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
