Ran
|
Jobs
1
|
Files
244
|
Run time
46s
|
Badge
Embed ▾
README BADGES
|
travis-ci
py: Implement partial PEP-498 (f-string) support This implements (most of) the PEP-498 spec for f-strings, with two exceptions: - raw f-strings (`fr` or `rf` prefixes) raise `NotImplementedError` - one special corner case does not function as specified in the PEP (more on that in a moment) This is implemented in the core as a syntax translation, brute-forcing all f-strings to run through `String.format`. For example, the statement `x='world'; print(f'hello {x}')` gets translated *at a syntax level* (injected into the lexer) to `x='world'; print('hello {}'.format(x))`. While this may lead to weird column results in tracebacks, it seemed like the fastest, most efficient, and *likely* most RAM-friendly option, despite being implemented under the hood with a completely separate `vstr_t`. Since [string concatenation of adjacent literals is implemented in the lexer](https://github.com/micropython/micropython/commit/534b7c368), two side effects emerge: - All strings with at least one f-string portion are concatenated into a single literal which *must* be run through `String.format()` wholesale, and: - Concatenation of a raw string with interpolation characters with an f-string will cause `IndexError`/`KeyError`, which is both different from CPython *and* different from the corner case mentioned in the PEP (which gave an example of the following:) ```python x = 10 y = 'hi' assert ('a' 'b' f'{x}' '{c}' f'str<{y:^4}>' 'd' 'e') == 'ab10{c}str< hi >de' ``` The above-linked commit detailed a pretty solid case for leaving string concatenation in the lexer rather than putting it in the parser, and undoing that decision would likely be disproportionately costly on resources for the sake of a probably-low-impact corner case. An alternative to become complaint with this corner case of the PEP would be to revert to string concatenation in the parser *only when an f-string is part of concatenation*, though I've done no investigation ... (continued)
102 of 102 new or added lines in 2 files covered. (100.0%)
18542 of 18925 relevant lines covered (97.98%)
362948.3 hits per line
Lines | Coverage | ∆ | File |
---|---|---|---|
6 |
98.77 |
-1.23% | py/parse.c |
ID | Job ID | Ran | Files | Coverage | |
---|---|---|---|---|---|
3 | 11089.3 (NAME="unix coverage build and tests") | 244 |
97.98 |
Travis Job 11089.3 |
Coverage | ∆ | File | Lines | Relevant | Covered | Missed | Hits/Line |
---|