thirdparty: vendor zope.interface 4.4.3 I've been trying to formalize interfaces for various components of Mercurial. So far, we've been using the "abc" package. This package is "good enough" for a lot of tasks. But it quickly falls over. For example, if you declare an @abc.abstractproperty, you must implement that attribute with a @property or the class compile time checking performed by abc will complain. This often forces you to implement dumb @property wrappers to return a _ prefixed attribute of the sane name. That's ugly. I've also wanted to implement automated checking that classes conform to various interfaces and don't expose other "public" attributes. After doing a bit of research and asking around, the general consensus seems to be that zope.interface is the best package for doing interface-based programming in Python. It has built-in support for verifying classes and objects conform to interfaces. It allows an interface's properties to be defined during __init__. There's even an "adapter registry" that allow you to register interfaces and look up which classes implement them. That could potentially be useful for places where our custom registry.py modules currently facilitates central registrations, but at a type level. Imagine extensions providing alternate implementations of things like the local repository interface to allow opening repositories with custom requirements. Anyway, this commit vendors zope.interface 4.4.3. The contents of the source tarball have been copied into mercurial/thirdparty/zope/ without modifications. Test modules have been removed because they are not interesting to us. The LICENSE.txt file has been copied so it lives next to the source. The Python modules don't use relative imports. zope/__init__.py defines a namespace package. So we'll need to modify the source code before this package is usable inside Mercurial. This will be done in subsequent commits. # no-check-commit for various style failures Differential Revision: https://phab.mercurial-scm.org/D2928

context: set repo property in basectx It seems like a good practice to call the super constructor. Let's start by passing the repo along to basectx so it can assign it to a private attribute. We should perhaps pass the rev and node along as well, but that requires more work before it can be done. Differential Revision: https://phab.mercurial-scm.org/D2970

context: move reuse of context object to repo.__getitem__ (API) As an example of how weird the basectx.__new__ is: whenever you create a workingctx, basectx.__new__ gets called first. Since our __new__ has a "changeid" argument as second parameter, when create the workingctx(repo, text="blah"), the text gets bound to "changeid". Since a string isn't a basectx, our __new__ ends up not doing anything funny, but that's still very confusing code. Another case is metadataonlyctx.__new__(), which I think exists in order to prevent metadataonlyctx.__init__'s third argument (originalctx) from being interpreted as a changeid in basectx.__new__(), thereby getting reused. Let's move this to repo.__getitem__ instead, where it will be pretty obvious what the code does. After this patch, changectx(ctx) will be an error (it will fail when trying to see if it's a 20-byte string). Differential Revision: https://phab.mercurial-scm.org/D2969