On Feb 4, 3:12 am, Marty Alchin <gulop...@gmail.com> wrote: > 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
Hi, I'm taking the chance to remind about 2 relevant tickets: - #9344 [1]: The tell() proxy is missing in the specific implementation of TemporaryFile for Windows. That causes PIL to crash. - #9404 [2]: Some proxies are missing in InMemoryUploadedFile. In [3] Karen explained that one reason why those tickets had not been checked-in yet was the absence of tests. But in fact, the existing proxies are currently not explicitly tested in Django's test suite, and I think some of them are not tested at all. I'm unsure how to go about testing these. Do you have suggestions? Regards, Julien [1] http://code.djangoproject.com/ticket/9344 [2] http://code.djangoproject.com/ticket/9404 [3] http://groups.google.com/group/django-developers/browse_thread/thread/7085109ceace2e37 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
