Summary:
This check is useful and detects real errors (ex. fbconduit). Unfortunately
`arc lint` will run it with both py2 and py3 so a lot of py2 builtins will
still be warned.
I didn't find a clean way to disable py3 check. So this diff tries to fix them.
For `xrange`, the change was done by a script:
```
import sys
import redbaron
headertypes = {'comment', 'endl', 'from_import', 'import', 'string',
'assignment', 'atomtrailers'}
xrangefix = '''try:
xrange(0)
except NameError:
xrange = range
'''
def isxrange(x):
try:
return x[0].value == 'xrange'
except Exception:
return False
def main(argv):
for i, path in enumerate(argv):
print('(%d/%d) scanning %s' % (i + 1, len(argv), path))
content = open(path).read()
try:
red = redbaron.RedBaron(content)
except Exception:
print(' warning: failed to parse')
continue
hasxrange = red.find('atomtrailersnode', value=isxrange)
hasxrangefix = 'xrange = range' in content
if hasxrangefix or not hasxrange:
print(' no need to change')
continue
# find a place to insert the compatibility statement
changed = False
for node in red:
if node.type in headertypes:
continue
# node.insert_before is an easier API, but it has bugs changing
# other "finally" and "except" positions. So do the insert
# manually.
# # node.insert_before(xrangefix)
line = node.absolute_bounding_box.top_left.line - 1
lines = content.splitlines(1)
content = ''.join(lines[:line]) + xrangefix + ''.join(lines[line:])
changed = True
break
if changed:
# "content" is faster than "red.dumps()"
open(path, 'w').write(content)
print(' updated')
if __name__ == "__main__":
sys.exit(main(sys.argv[1:]))
```
For other py2 builtins that do not have a py3 equivalent, some `# noqa`
were added as a workaround for now.
Reviewed By: DurhamG
Differential Revision: D6934535
fbshipit-source-id: 546b62830af144bc8b46788d2e0fd00496838939
IIUC, letting the StopIteration through would not cause any bugs, but
not doing it makes the test-py3-commands.t pass.
I have also diligently gone through all uses of next() in our code
base. They either:
* are not called from a generator
* pass a default value to next()
* catch StopException
* work on infinite iterators
* request a fixed number of items that matches the generated number
* are about batching in wireproto which I didn't quite follow
I'd appreciate if Augie or someone else could take a look at the
wireproto batching and convince themselves that the next(batchable)
calls there will not raise a StopIteration.
This renames the spanset class to _spanset, and moves its __init__ to new
spanset() function. spanset() is now a factory function.
This allows us to construct a spanset without keeping a repo instance.
.next attribute does not exist on Python 3. As this function seems to really
care about the overhead of the Python interpreter, I follow the way of micro
optimization.
This is a follow-up of "smartset: use native set operations as fast paths".
It's more correct to just preserve the "istopo" information for "&" and "-"
operations, like what filteredset does.
For set operations like "&" and "-", where we know both basesets have their
sets ready, and the first set is sorted, use the native Python set
operations as a fast path.
Note: "+" is not optimized as that will break the ordering.
This leads to noticeable improvements on performance:
revset | before | after | delta
----------------------------------------------------------------
draft() & draft() & draft() & draft() | 776 | 477 | -39%
draft() + draft() + draft() + draft() | 2849 | 2864 |
draft() - draft() + draft() - draft() | 943 | 240 | -75%
draft() - draft() - draft() - draft() | 557 | 197 | -64%
(time measured in microseconds)
If the caller only wants to construct a baseset via a set, and then do
"__contains__" tests. It's unnecessary to initialize the list.
Testing on my unfiltered hg-committed repo where len(draft()) is 2600, this
patch shows about 6% improvement on set intensive queries:
Before:
$ for i in `seq 5`; hg perfrevset 'draft() & draft() & draft() & draft()'
! wall 0.001196 comb 0.000000 user 0.000000 sys 0.000000 (best of 2011)
! wall 0.001191 comb 0.000000 user 0.000000 sys 0.000000 (best of 2099)
! wall 0.001186 comb 0.010000 user 0.010000 sys 0.000000 (best of 1953)
! wall 0.001182 comb 0.000000 user 0.000000 sys 0.000000 (best of 2135)
! wall 0.001193 comb 0.000000 user 0.000000 sys 0.000000 (best of 2177)
After:
$ for i in `seq 5`; hg perfrevset 'draft() & draft() & draft() & draft()'
! wall 0.001128 comb 0.000000 user 0.000000 sys 0.000000 (best of 2247)
! wall 0.001119 comb 0.000000 user 0.000000 sys 0.000000 (best of 2317)
! wall 0.001115 comb 0.000000 user 0.000000 sys 0.000000 (best of 2244)
! wall 0.001131 comb 0.000000 user 0.000000 sys 0.000000 (best of 2093)
! wall 0.001124 comb 0.000000 user 0.000000 sys 0.000000 (best of 2134)
It could have bigger impact on larger sets in theory.
These classes are pretty large and independent from revset computation.
2961 mercurial/revset.py
973 mercurial/smartset.py
3934 total
revset.prettyformatset() is renamed to smartset.prettyformat(). Smartset
classes are aliased since they are quite common in revset.py.