m.(cdo|tnm).download: Replace requests with urllib #977
Conversation
| outf.write(inf.read()) | ||
| except urllib.error.HTTPError as e: | ||
| grass.warning( | ||
| _("Failed to download %s with status code %d") % (filename, e.code) |
There was a problem hiding this comment.
.format(filename=..., code=...) is preferred over C-like %s %d. The new code does not have to be outdated just because the surrounding code is.
There was a problem hiding this comment.
I thought C-like formats would be better for cross-language translations, but anyway, we already have Python formats, so not a big deal.
There was a problem hiding this comment.
We definitively use .format in new Python code. So far, we weighted the clarity of code and possible order changes in translations over translation reuse. Plus these are not really translated at this point, no? So it is only the code.
There was a problem hiding this comment.
@wenzeslaus Shouldn't we prefer f-strings (better readability and shorter) in that case when the minimum Python version we support is 3.8?
There was a problem hiding this comment.
We didn't adapt the CI yet, but for the main branch, the minimum supported version agreed upon is 3.9. So you are free
There was a problem hiding this comment.
I thought this was this GRASS repo, not the GRASS addons repo. For addons I don't know, but hope to follow the main grass repo to allow sharing similar maintenance
There was a problem hiding this comment.
The rule now is: f-strings for plain strings, but _("...").format(key=...) for translatable ones. (f-strings are overall better and recommended by linters but don't work with translations.)
There was a problem hiding this comment.
| def urlopen(url): | ||
| url = url.replace(" ", "%20") | ||
| return urllib.request.urlopen(url) |
There was a problem hiding this comment.
There is probably encode-decode function which would do this in more general way.
There was a problem hiding this comment.
Found url = urllib.parse.quote(url, safe=":/?=&"), but I liked the above simpler version. Any better suggestion?
There was a problem hiding this comment.
I was actually surprised that I couldn't find any general URL encode/decode functions that can simply take full URLs.
There was a problem hiding this comment.
Oh BTW, TNM only complained about spaces in URL. That was another reason.
There was a problem hiding this comment.
Then I don't have a better suggestion. I think a documentation would clarify the existence of the function or a separate function encode_spaces() or encode_X_for_Y() as there seems to be some specificity to this particular case.
This PR fixes #976.