Closed xavivars closed 6 years ago
Changes Missing Coverage | Covered Lines | Changed/Added Lines | % | ||
---|---|---|---|---|---|
apertium_apy/handlers/translate.py | 5 | 9 | 55.56% | ||
apertium_apy/keys.py | 7 | 19 | 36.84% | ||
<!-- | Total: | 15 | 31 | 48.39% | --> |
Totals | |
---|---|
Change from base Build 890: | -0.2% |
Covered Lines: | 1056 |
Relevant Lines: | 2106 |
This looks pretty good. One nit is, should it be class ApiKeys
instead of class ApiKey
since it holds multiple keys rather than a single one?
I wonder if rather than introducing a new dependency on commentjson
, we could just copy over the couple relevant lines of code, specifically:
regex = r'\s*(#|\/{2}).*$'
regex_inline = r'(:?(?:\s)*([A-Za-z\d\.{}]*)|((?<=\").*\"),?)(?:\s)*(((#|(\/{2})).*)|)$'
lines = text.split('\n')
for index, line in enumerate(lines):
if re.search(regex, line):
if re.search(r'^' + regex, line, re.IGNORECASE):
lines[index] = ""
elif re.search(regex_inline, line):
lines[index] = re.sub(regex_inline, r'\1', line)
ApiKeys
instead of ApiKey
makes complete sense, I'll change that.
Regargind the other comment, I'm not super fan of copying libraries code into another program. Also, in this case, if commentsjson is not installed, the functionality still works (relying on the standard json library). But it's also true that the code needed is pretty small, so I'm OK with both approaches.
In any case, if we copy over the code, I think we should do the same thing with tests.
Also, in this case, if commentsjson is not installed, the functionality still works (relying on the standard json library).
Ah, good point. Okay, then I'm okay with keeping it.
Hmm, build seems to be failing?
I know, but I don't understand why... there are almost no changes in the latest commit
This feature will enable using apertium-apy installed with PIP and still use api-keys, as that feature will no longer depend on modifying a package's source file.