##// END OF EJS Templates
scmutil: explicitly subclass the `Status` protocol...
scmutil: explicitly subclass the `Status` protocol We shouldn't have to explicitly subclass, but PyCharm has a nifty feature that puts a jump point in the gutter to navigate back and forth between the base class and subclasses (and override functions and base class functions) when there's an explicit subclassing. Additionally, PyCharm will immediately flag signature mismatches without a 40m pytype run. It was also hoped that with explicit subclassing, we would get interface checking for free. Unfortunately when I tried adding methods and fields to the Protocol class to test this theory, pytype happily accepted an assignment of the concrete class without the new field and methods, to a variable annotated with the Protocol class with them. It appears that this is what happens when explicit subclassing is used, since dropping that caused pytype to complain. By making the methods abstract here like the `mercurial.wireprototypes` classes in fd200f5bcaea, pytype will complain in that case outlined that a subclass with abstract methods (not replaced by the subclass itself) cannot be instantiated. That doesn't help with the fields. Making an `abstractproperty` likely isn't appropriate in general, because that effectively becomes a read-only property. This seems like a pretty gaping hole, but I think the benefits of explicit subclassing are worth the risk. (Though I guess it shouldn't be surprising, because a class can be both a Protocol and an implementation, so subclassing something with an empty body method doesn't really signal that it is a requirement for the subclass to implement.)

File last commit:

r52830:936f85b2 default
r53348:f5d134e5 default
Show More
base85.py
90 lines | 2.1 KiB | text/x-python | PythonLexer
# base85.py: pure python base85 codec
#
# Copyright (C) 2009 Brendan Cully <brendan@kublai.com>
#
# This software may be used and distributed according to the terms of the
# GNU General Public License version 2 or any later version.
from __future__ import annotations
import struct
from .. import pycompat
_b85chars = pycompat.bytestr(
b"0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdef"
b"ghijklmnopqrstuvwxyz!#$%&()*+-;<=>?@^_`{|}~"
)
_b85chars2 = [(a + b) for a in _b85chars for b in _b85chars]
_b85dec = {}
def _mkb85dec():
for i, c in enumerate(_b85chars):
_b85dec[c] = i
def b85encode(text: bytes, pad: bool = False) -> bytes:
"""encode text in base85 format"""
l = len(text)
r = l % 4
if r:
text += b'\0' * (4 - r)
longs = len(text) >> 2
words = struct.unpack(b'>%dL' % longs, text)
out = b''.join(
_b85chars[(word // 52200625) % 85]
+ _b85chars2[(word // 7225) % 7225]
+ _b85chars2[word % 7225]
for word in words
)
if pad:
return out
# Trim padding
olen = l % 4
if olen:
olen += 1
olen += l // 4 * 5
return out[:olen]
def b85decode(text: bytes) -> bytes:
"""decode base85-encoded text"""
if not _b85dec:
_mkb85dec()
l = len(text)
out = []
acc = 0
for i in range(0, len(text), 5):
chunk = text[i : i + 5]
chunk = pycompat.bytestr(chunk)
acc = 0
for j, c in enumerate(chunk):
try:
acc = acc * 85 + _b85dec[c]
except KeyError:
raise ValueError(
'bad base85 character at position %d' % (i + j)
)
if acc > 4294967295:
raise ValueError('Base85 overflow in hunk starting at byte %d' % i)
out.append(acc)
# Pad final chunk if necessary
cl = l % 5
if cl:
acc *= 85 ** (5 - cl)
if cl > 1:
acc += 0xFFFFFF >> (cl - 2) * 8
out[-1] = acc
out = struct.pack(b'>%dL' % (len(out)), *out)
if cl:
out = out[: -(5 - cl)]
return out