##// END OF EJS Templates
interfaces: mark a few dirstate methods abstract...
interfaces: mark a few dirstate methods abstract I'm not sure what's going on here, but when enabling pytype checking on this package, it spits out the following errors: File "/mnt/c/Users/Matt/hg/mercurial/interfaces/dirstate.py", line 136, in changing_parents: bad return type [bad-return-type] Expected: Iterator Actually returned: None Attributes of protocol Iterator are not implemented on None: __next__ File "/mnt/c/Users/Matt/hg/mercurial/interfaces/dirstate.py", line 145, in changing_files: bad return type [bad-return-type] Expected: Iterator Actually returned: None Attributes of protocol Iterator are not implemented on None: __next__ I guess technically that's true, because these methods only have a doc comment, and don't explicitly return something or unconditionally raise an error. The strange thing is that both before and after this change, the *.pyi file that is generated is unchanged, and contains: def changing_files(self, repo) -> contextlib._GeneratorContextManager: ... def changing_parents(self, repo) -> contextlib._GeneratorContextManager: ... I'm not sure if the `@abstractmethod` should be the most inner or most outer decoration. We'll roll the dice with being the innermost, because that's how `@abstractproperty` says it should be used in conjunction with `@property`. We should probably make all of the methods without an actual body abstract, like was done for some `mercurial.wireprototypes` classes in fd200f5bcaea. But let's hold off for now and do that enmass later.
Matt Harbison -
r53328:2c8c46c3 default
Show More
Name Size Modified Last Commit Author
/ mercurial / thirdparty / cbor
cbor2
.travis.yml Loading ...
LICENSE.txt Loading ...
README.rst Loading ...
__init__.py Loading ...
Build Status Code Coverage

This library provides encoding and decoding for the Concise Binary Object Representation (CBOR) (RFC 7049) serialization format.

There exists another Python CBOR implementation (cbor) which is faster on CPython due to its C extensions. On PyPy, cbor2 and cbor are almost identical in performance. The other implementation also lacks documentation and a comprehensive test suite, does not support most standard extension tags and is known to crash (segfault) when passed a cyclic structure (say, a list containing itself).