On Jan 30, 2009, at 22:19, Todd O'Bryan wrote: > On Fri, Jan 30, 2009 at 3:10 PM, Ludvig Ericson > <ludvig.eric...@gmail.com> wrote: >> >> On Jan 30, 2009, at 17:28, Todd O'Bryan wrote: >>> OK, after I did this, I was lying in bed and had the following >>> revelation. Would there be anything terribly wrong with just using >>> __getattr__ in UploadedFile to forward all attribute requests that >>> the >>> UploadedFile can't process to self._file, the file-like object that >>> would be backing it? That way, you get access to all the features of >>> the underlying file without much overhead in the UploadedFile. >>> >>> Thoughts? >> >> asyncore from Python's standard library does that. >> >> It's not a great idea at all. For many reasons, one being the >> principle of least astonishment. >> > > I'm not sure I understand this. If you try to call a file-like method > or access a file-like attribute on an UploadedFile, it would either do > the right thing or you'd get an error saying that UploadedFile doesn't > support it. Neither of those seems terribly astonishing.
And then you get an AttributeError which moans about some entirely different object, inside a foreign method. I know, you can weed it out, but I'm not alone in staring at the asyncore exceptions. The __getattr__-approach also has the side-effect of dispatching all missing attribute accesses, which could result in oddities for other reasons. Not that I can think of one, but it could be a source of subtle bugs. >> Much rather, copy the attributes. But then you start going the >> winding >> path down to "I'm merging this instance into myself", and you end up >> with messy code. >> >> Anyway, the file-like methods are a finite set. Why not try to be >> complete? (This issue has bitten me by the way, and I did >> f.readline = >> f._file.readline.) > > But they're not a closed set. Guido could decide to add something to > that set and then we'd have to argue about whether or not to implement > that file-like behavior on Django's file-like objects. With this > solution, we've already made the decision. Django's file-like objects > support whichever file-like behavior the object backing them does. I get your argument, but realistically, how much have file objects changed the past year or two? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
