Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bpo-39080: Starred Expression's column offset fix when inside a CALL #17645

Merged
merged 4 commits into from Dec 18, 2019

Conversation

@lysnikolaou
Copy link
Contributor

lysnikolaou commented Dec 17, 2019

….OrxEVS.rst

Co-Authored-By: Pablo Galindo <Pablogsal@gmail.com>
@lysnikolaou lysnikolaou requested a review from pablogsal Dec 17, 2019
@pablogsal

This comment has been minimized.

Copy link
Member

pablogsal commented Dec 17, 2019

Actually, this seems that does not only affect starred expressions. For example:

>>> val = "f(a,b,c)"
>>> val[ast.parse(val).body[0].value.args[2].end_col_offset]
')'
>>> val[ast.parse(val).body[0].value.args[0].end_col_offset]
','
>>> val[ast.parse(val).body[0].value.args[1].end_col_offset]
','
>>> val[ast.parse(val).body[0].value.args[2].end_col_offset]
')'

that seems odd.

@gvanrossum

This comment has been minimized.

Copy link
Member

gvanrossum commented Dec 17, 2019

Possibly @ilevkivskyi would also be interested in hearing about this?

@pablogsal pablogsal requested a review from ilevkivskyi Dec 17, 2019
@pablogsal

This comment has been minimized.

Copy link
Member

pablogsal commented Dec 17, 2019

Nevermind, I imagine that is so you can do expression[col_offset:end_col_offset].

@lysnikolaou

This comment has been minimized.

Copy link
Contributor Author

lysnikolaou commented Dec 17, 2019

Actually, this seems that does not only affect starred expressions.

That's actually ok, because end_col_offset is always where the token ends + 1. In your examples col_offset of a is 2 and end_col_offset is 3, which is the intended behavior.

@pablogsal

This comment has been minimized.

Copy link
Member

pablogsal commented Dec 17, 2019

That's actually ok, because end_col_offset is always where the token ends + 1. In your examples col_offset of a is 2 and end_col_offset is 3, which is the intended behavior.

Yup. Also the fix is consistent with extracting the values via expression[col_offset:end_col_offset]

Copy link
Contributor

ilevkivskyi left a comment

Thanks! This totally makes sense, with the current logic end position is the end position of the * symbol itself, which is wrong.

@ilevkivskyi

This comment has been minimized.

Copy link
Contributor

ilevkivskyi commented Dec 17, 2019

This doesn't need backport to 3.7 as this is a new feature in 3.8

@lysnikolaou

This comment has been minimized.

Copy link
Contributor Author

lysnikolaou commented Dec 17, 2019

@ilevkivskyi A similar change I made in #17582 was considered a bugfix and was backported to 3.7

@pablogsal

This comment has been minimized.

Copy link
Member

pablogsal commented Dec 18, 2019

@lysnikolaou In #17582 what changed was the col_offset that is accessible by Python AST objects in 3.7, but end_col_offset and end_lineno was introduced in 3.8.

@pablogsal pablogsal merged commit 50d4f12 into python:master Dec 18, 2019
9 checks passed
9 checks passed
Docs
Details
Windows (x86)
Details
Windows (x64)
Details
macOS
Details
Ubuntu
Details
Azure Pipelines PR #20191217.40 succeeded
Details
bedevere/issue-number Issue number 39080 found
Details
bedevere/news News entry found in Misc/NEWS.d
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@miss-islington

This comment has been minimized.

Copy link

miss-islington commented Dec 18, 2019

Thanks @lysnikolaou for the PR, and @pablogsal for merging it 🌮🎉.. I'm working now to backport this PR to: 3.8.
🐍🍒🤖

@miss-islington

This comment has been minimized.

Copy link

miss-islington commented Dec 18, 2019

I'm having trouble backporting to 3.8. Reason: 'Error 110 while writing to socket. Connection timed out.'. Please retry by removing and re-adding the needs backport to 3.8 label.

@miss-islington

This comment has been minimized.

Copy link

miss-islington commented Dec 18, 2019

Thanks @lysnikolaou for the PR, and @pablogsal for merging it 🌮🎉.. I'm working now to backport this PR to: 3.8.
🐍🍒🤖

@miss-islington

This comment has been minimized.

Copy link

miss-islington commented Dec 18, 2019

Sorry @lysnikolaou and @pablogsal, I had trouble checking out the 3.8 backport branch.
Please backport using cherry_picker on command line.
cherry_picker 50d4f12958bf806a4e1a1021d70cfd5d448c5cba 3.8

pablogsal added a commit to pablogsal/cpython that referenced this pull request Dec 18, 2019
… CALL (pythonGH-17645)

Co-Authored-By: Pablo Galindo <Pablogsal@gmail.com>
(cherry picked from commit 50d4f12)

Co-authored-by: Lysandros Nikolaou <lisandrosnik@gmail.com>
@bedevere-bot

This comment has been minimized.

Copy link

bedevere-bot commented Dec 18, 2019

GH-17649 is a backport of this pull request to the 3.8 branch.

miss-islington added a commit that referenced this pull request Dec 18, 2019
… CALL (GH-17645) (GH-17649)

… 
Co-Authored-By: Pablo Galindo <Pablogsal@gmail.com>
(cherry picked from commit 50d4f12)

Co-authored-by: Lysandros Nikolaou <lisandrosnik@gmail.com>





https://bugs.python.org/issue39080
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.