Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Bytecode positions seem way too broad #93691

Closed
Assignees
iritkatriel
Labels
3.11only security fixes3.12only security fixesinterpreter-core(Objects, Python, Grammar, and Parser dirs)type-bugAn unexpected behavior, bug, or error
@brandtbucher

Description

@brandtbucher

(Note thatdis currently has abug in displaying accurate location info in the presence ofCACHEs. The correct information can be observed by working withco_positions directly or using the code from that PR.)

While developingspecialist, I realized that there are lots of common code patterns that produce bytecode with unexpectedly large source ranges. In addition to being unhelpful for both friendly tracebacks (the original motivation) and things like bytecode introspection, I suspect these huge ranges may also be bloating the size of our internal position tables as well.

Consider the following function:

defanalyze(path):#  1upper=lower=total=0#  2withopen(path)asfile:#  3forlineinfile:#  4forcharacterinline:#  5ifcharacter.isupper():#  6upper+=1#  7elifcharacter.islower():#  8lower+=1#  9total+=1# 10returnlower/total,upper/total# 11importdisfrompprintimportpprintasppdefpos(p):return (p.lineno,p.end_lineno,p.col_offset,p.end_col_offset)pp([(pos(x.positions),x.opname,x.argval)forxindis.get_instructions(analyze)])

Things that should probably span one line at most:

  • The firstGET_ITER/FOR_ITER pair span all of lines 4 through 10.
  • The secondGET_ITER/FOR_ITER pair spans all of lines 5 through 10.
  • The firstPOP_JUMP_FORWARD_IF_FALSE spans all of lines 6 through 9.
  • The secondPOP_JUMP_FORWARD_IF_FALSE spans all of lines 8 through 9.
  • Ten instructions forwith cleanup each span all of lines 3 through 10.

Things that should probably be artificial:

  • AJUMP_FORWARD spans all of line 7.
  • The firstJUMP_BACKWARD spans all of line 10.
  • The secondJUMP_BACKWARD spans all of lines 5 through 10.

Things I don't get:

  • ANOP spans all of lines 4 through 10.

As a result, over half of the generated bytecode for this function claims to span line 9, for instance. Also not shown here: the instructions for building functions and classes have similarly huge spans.

I think this can be tightened up in the compiler by:

  • Being more aggressive in callingSET_LOC on child nodes.
  • Being more aggressive in callingUNSET_LOC before unconditional jumps.

Linked PRs

Metadata

Metadata

Assignees

Labels

3.11only security fixes3.12only security fixesinterpreter-core(Objects, Python, Grammar, and Parser dirs)type-bugAn unexpected behavior, bug, or error

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions


    [8]ページ先頭

    ©2009-2025 Movatter.jp