Skip to content

Conversation

@DanielNoord
Copy link
Collaborator

Type of Changes

Type
βœ“ πŸ› Bug fix
βœ“ πŸ”¨ Refactoring

Description

Follow up to #2219.

I didn't get round to reviewing, but had some last nits. This brings the nodes a little bit more in line with the other nodes (I also don't like it, but let's stay consistent).
More importantly, it also fixes an issue with the typing. list[TypeVar, ParamSpec, ...] is incorrect as per:
image
https://docs.python.org/3/library/typing.html#annotating-tuples

@DanielNoord DanielNoord added Bug πŸͺ³ Maintenance Discussion or action around maintaining astroid or the dev workflow labels Jun 27, 2023
@DanielNoord DanielNoord added this to the 3.0.0a6 milestone Jun 27, 2023
@codecov
Copy link

codecov bot commented Jun 27, 2023

Codecov Report

Merging #2227 (58b42be) into main (fef38f2) will increase coverage by 0.00%.
The diff coverage is 100.00%.

Additional details and impacted files

Impacted file tree graph

@@ Coverage Diff @@ ## main #2227 +/- ## ======================================= Coverage 92.92% 92.93% ======================================= Files 95 95 Lines 10918 10920 +2 ======================================= + Hits 10146 10148 +2  Misses 772 772 
Flag Coverage Ξ”
linux 92.73% <100.00%> (+<0.01%) ⬆️
pypy 91.07% <100.00%> (+<0.01%) ⬆️
windows 92.50% <100.00%> (+<0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Ξ”
astroid/nodes/node_classes.py 95.56% <100.00%> (+<0.01%) ⬆️
@jacobtylerwalls
Copy link
Member

Taking a look

Comment on lines -3378 to +3383
name: AssignName | None,
type_params: list[TypeVar, ParamSpec, TypeVarTuple],
name: AssignName,
type_params: list[TypeVar | ParamSpec | TypeVarTuple],
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ouch, thank you, I was just working too quickly.

Comment on lines +3358 to +3360
name: AssignName
type_params: list[TypeVar | ParamSpec | TypeVarTuple]
value: NodeNG
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not totally sure why we're adopting this pattern instead of using the constructor.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like it as well, but I do think we should at least try and keep one style so that we can then refactor it to a desired style all at once?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No worries. Sometimes it seems like we prefer not to mass-replace, but not a big deal, let's keep moving. πŸ‘

<ParamSpec l.1 at 0x7f23b2e4e198>
"""

_astroid_fields = ("name",)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I missed these because I went back and forth on whether this should be a str or an AssignName until I saw the references for the similar issue with MatchStar and friends pointing to python/cpython#88160.

Copy link
Member

@jacobtylerwalls jacobtylerwalls left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's ship it :-)

@DanielNoord DanielNoord merged commit d4f4452 into pylint-dev:main Jun 27, 2023
@DanielNoord DanielNoord deleted the post-312 branch June 27, 2023 20:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Bug πŸͺ³ Maintenance Discussion or action around maintaining astroid or the dev workflow Unreleased

3 participants