[issue10392] GZipFile crash when fileobj.mode is None

Brad Greenlee added the comment: Understood. I just felt that fileobj.mode == None should be handled the same way that GzipFile(...,mode=None) is handled. I've submitted a patch to Django: http://code.djangoproject.com/ticket/14681 -- ___ Python tr

[issue10392] GZipFile crash when fileobj.mode is None

R. David Murray added the comment: Yes. However, if None were a valid value for mode, then the would would instead do something like: SENTINEL = object() class GZipFile... def __init__(self, filename=None, mode=SENTINEL, ... and then where None currently appears in the logic of the met

[issue10392] GZipFile crash when fileobj.mode is None

Brad Greenlee added the comment: Yes, but if I actually passed mode=None in, the behavior would be the same, no? -- ___ Python tracker ___ __

[issue10392] GZipFile crash when fileobj.mode is None

R. David Murray added the comment: No, the __init__ argument default value is the standard way of indicating "this argument was not specified". It is not in any way a value for 'mode'. -- status: open -> closed ___ Python tracker

[issue10392] GZipFile crash when fileobj.mode is None

Brad Greenlee added the comment: GzipFile.__init__ considers mode == None to be the equivalent of undefined, and sets it to the default of 'rb'. I see fileobj.mode == None as the same thing. That said, it is probably a bug in Django as well; I'll look into that. I still think that GzipFile sh

[issue10392] GZipFile crash when fileobj.mode is None

R. David Murray added the comment: Why do you consider this a bug in GZipFile rather than a bug in Django? GZipFile is already careful to consider mode only when it is defined as an attribute. It seems to me that if it is defined, it should be meaningful. -- nosy: +pitrou, r.david.m

[issue10392] GZipFile crash when fileobj.mode is None

New submission from Brad Greenlee : If GZipFile.__init_ is passed a fileobj that has a mode attribute set to None, it will crash with a "'NoneType' object is unsubscriptable" error when it tries to read the first character of the mode. I ran across this when trying to pass GZipFile an uploaded