Lewis Ball added the comment:
Okay that makes sense. Removing things from _synchre would slow down the
matching slightly, although the matching still seems plenty fast enough when
done inside an if clause at the moment, so I'm not sure how noticeable the
removal of `else` would be. One
Lewis Ball added the comment:
Okay, on further examination `find_good_parse_start` first looks for a line
ending with ':\n', and then looks to match _synchre on that line. If it can't
find any line ending in ':\n' then it will just look for the first occurrence
of something in _synchre
Lewis Ball added the comment:
So it looks like `pyparse.Parser.find_good_parse_start` is responsible for
truncating the code to only look for the matching bracket in the current
statement, which uses _synchre.
Testing it out, it sometimes will go to the most recent match of _synchre
Lewis Ball added the comment:
A minimal example of the same issue seems to be:
```
(1 if x
else 0)
```
In this case the parentheses matching also fails. It only ever seems to fail
when `else` is the first word on a newline inside brackets, and adding the line
break elsewhere in the above
Lewis Ball added the comment:
Okay no worries, glad it is all sorted now :)
--
___
Python tracker
<https://bugs.python.org/issue41387>
___
___
Python-bugs-list m
Lewis Ball added the comment:
So I have just tried it out and the example seems to work fine for me as it is
(tested using 3.8.2).
Note that escaping the " in this case makes no difference to the string:
```
>>> """""" == &
Lewis Ball added the comment:
I don't have triage permissions so I don't think I can request a review.
Although @aeros has requested one.
--
___
Python tracker
<https://bugs.python.org/issue40
Change by Lewis Ball :
--
keywords: +patch
pull_requests: +19287
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/19971
___
Python tracker
<https://bugs.python.org/issu
New submission from Lewis Ball :
Currently the docs for `difflib.SequenceMatcher.quick_ratio()` just says
'Return an upper bound on ratio() relatively quickly', which doesn't give much
of an idea about how that upper bound is calculated. `real_quick_ratio` has
similarly brief documentation
Lewis Ball added the comment:
I've updated the travis.yml now to fix this issue and global statements are now
showing as covered in the coverage report. This means an extra 4k lines show
as covered which weren't previously showing. See the report for the PR here
(https://codecov.io/gh
Change by Lewis Ball :
--
keywords: +patch
pull_requests: +19168
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/19851
___
Python tracker
<https://bugs.python.org/issu
New submission from Lewis Ball :
The current reported code coverage stats on codecov.io miss some global
statements of modules imported before coveragepy begins. This is documented in
the dev guide, and the suggested fix is here:
https://devguide.python.org/coverage/#coverage-results
Lewis Ball added the comment:
Thanks Tim. Cheers for your support with this :)
--
___
Python tracker
<https://bugs.python.org/issue40394>
___
___
Python-bug
Lewis Ball added the comment:
Oh okay, well I was just saying I have added a test which is unrelated to the
feature I have added, but it does test a different part of the same function.
Anyway, I have raised a PR for this now (19742) and can separate it out if
needed
Change by Lewis Ball :
--
keywords: +patch
pull_requests: +19064
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/19742
___
Python tracker
<https://bugs.python.org/issu
Lewis Ball added the comment:
Adding a test for this and noticed I can add one more test case to get the
method to full coverage. Can I add that to this PR or should I raise a separate
one?
--
___
Python tracker
<https://bugs.python.
Lewis Ball added the comment:
Okay, that makes sense. I will raise a PR
--
___
Python tracker
<https://bugs.python.org/issue40394>
___
___
Python-bugs-list m
New submission from Lewis Ball :
The usage of difflib.SequenceMatcher.find_longest_match could be simplified for
the most common use case (finding the longest match between the entirety of the
two strings) by taking default args.
At the moment you have to do:
>>> from diffl
18 matches
Mail list logo
