Author jaraco
Recipients KayEss, Rhamphoryncus, benjamin.peterson, blakeross, georg.brandl, gregory.p.smith, gvanrossum, jaraco, jcea, jonash, rhettinger, terry.reedy
Date 2014-05-28.05:44:58
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1401255903.12.0.879111694504.issue1683368@psf.upfronthosting.co.za>
In-reply-to
Content
I recently ran into this error again. I was writing this class to provide backward-compatible context manager support for zipfile.ZipFile on Python 2.6 and 3.1:

class ContextualZipFile(zipfile.ZipFile):
    """
    Supplement ZipFile class to support context manager for Python 2.6
    """

    def __enter__(self):
        return self

    def __exit__(self, type, value, traceback):
        self.close()

    def __new__(cls, *args, **kwargs):
        """
        Construct a ZipFile or ContextualZipFile as appropriate
        """
        if hasattr(zipfile.ZipFile, '__exit__'):
            return zipfile.ZipFile(*args, **kwargs)
        return super(ContextualZipFile, cls).__new__(cls, *args, **kwargs)


At the point where super is called, the author is unaware of the details of the function signature for zipfile.ZipFile.__new__, so simply passes the same arguments as were received by the derived class. However, this behavior raises a DeprecationWarning on Python 2.6 and 3.1 (and would raise an error on Python 3.2 if the code allowed it).

What's surprising is that the one cannot simply override a constructor or initializer without knowing in advance which of those methods are implemented (and with what signature) on the parent class.

It seems like the construction (calling of __new__) is special-cased for classes that don't implement __new__.

What is the proper implementation of ContextualZipFile.__new__? Should it use super but omit the args and kwargs? Should it call object.__new__ directly? Should it check for the existence of __new__ on the parent class (or compare it to object.__new__)?
History
Date User Action Args
2014-05-28 15:02:20gvanrossumunlinkissue1683368 messages
2014-05-28 05:45:04jaracosetrecipients: + jaraco, gvanrossum, georg.brandl, rhettinger, terry.reedy, gregory.p.smith, jcea, Rhamphoryncus, blakeross, benjamin.peterson, KayEss, jonash
2014-05-28 05:45:03jaracosetmessageid: <1401255903.12.0.879111694504.issue1683368@psf.upfronthosting.co.za>
2014-05-28 05:45:02jaracolinkissue1683368 messages
2014-05-28 05:44:58jaracocreate