GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — [3.12] gh-113320: Reduce the number of dangerous `getattr()` calls when constructing protocol classes (#113401) by AlexWaygood · Pull Request #113722 · python/cpython

Conversation

@AlexWaygood

@AlexWaygood AlexWaygood commented Jan 5, 2024 •
edited
Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link
Copy Markdown
Member
  • Only attempt to figure out whether protocol members are "method members" or not if the class is marked as a runtime protocol. This information is irrelevant for non-runtime protocols; we can safely skip the risky introspection for them.
  • Only do the risky getattr() calls in one place (the runtime_checkable class decorator), rather than in three places (_ProtocolMeta.init, _ProtocolMeta.instancecheck and _ProtocolMeta.subclasscheck). This reduces the number of locations in typing.py where the risky introspection could go wrong.
  • For runtime protocols, if determining whether a protocol member is callable or not fails, give a better error message. I think it's reasonable for us to reject runtime protocols that have members which raise strange exceptions when you try to access them. PEP-544 clearly states that all protocol member must be callable for issubclass() calls against the protocol to be valid -- and if a member raises when we try to access it, there's no way for us to figure out whether it's a callable member or not!

(cherry-picked from commit ed6ea3e)

Closes #113320

  • Issue: Should typing be calling getattr on arbitrary classes?  #113320

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions
@AlexWaygood
[3.12] pythongh-113320: Reduce the number of dangerous getattr() ca…
1dbee4d
…lls when constructing protocol classes (python#113401)

- Only attempt to figure out whether protocol members are "method members" or not if the class is marked as a runtime protocol. This information is irrelevant for non-runtime protocols; we can safely skip the risky introspection for them.
- Only do the risky getattr() calls in one place (the runtime_checkable class decorator), rather than in three places (_ProtocolMeta.__init__, _ProtocolMeta.__instancecheck__ and _ProtocolMeta.__subclasscheck__). This reduces the number of locations in typing.py where the risky introspection could go wrong.
- For runtime protocols, if determining whether a protocol member is callable or not fails, give a better error message. I think it's reasonable for us to reject runtime protocols that have members which raise strange exceptions when you try to access them. PEP-544 clearly states that all protocol member must be callable for issubclass() calls against the protocol to be valid -- and if a member raises when we try to access it, there's no way for us to figure out whether it's a callable member or not!

(cherry-picked from commit ed6ea3e)
@AlexWaygood
AlexWaygood requested review from JelleZijlstra and gvanrossum as code owners January 5, 2024 01:17
@bedevere-app bedevere-app Bot added the awaiting core review label Jan 5, 2024
This was referenced Jan 5, 2024
gh-113320: Reduce the number of dangerous getattr() calls when constructing protocol classes #113401
Merged
Should typing be calling getattr on arbitrary classes? #113320
Closed
@AlexWaygood
AlexWaygood merged commit 8435fbf into python:3.12 Jan 5, 2024
@AlexWaygood
AlexWaygood deleted the backport-113401-312 branch January 5, 2024 01:51
@bedevere-app bedevere-app Bot removed the awaiting core review label Jan 5, 2024
@AlexWaygood
AlexWaygood restored the backport-113401-312 branch February 22, 2024 16:35
@AlexWaygood
AlexWaygood deleted the backport-113401-312 branch March 7, 2024 14:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@gvanrossum gvanrossum Awaiting requested review from gvanrossum gvanrossum is a code owner
@JelleZijlstra JelleZijlstra Awaiting requested review from JelleZijlstra JelleZijlstra is a code owner

Uh oh!

There was an error while loading. Please reload this page.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Uh oh!

There was an error while loading. Please reload this page.

1 participant

@AlexWaygood
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
You are visitor 01402503 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.