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

C API dictionary views type checkers are not documented #80008

Open
salty-horse mannequin opened this issue Jan 25, 2019 · 4 comments
Open

C API dictionary views type checkers are not documented #80008

salty-horse mannequin opened this issue Jan 25, 2019 · 4 comments
Labels
docs Documentation in the Doc dir topic-C-API type-feature A feature request or enhancement

Comments

@salty-horse
Copy link
Mannequin

salty-horse mannequin commented Jan 25, 2019

BPO 35827
Nosy @salty-horse, @tiran, @serhiy-storchaka

Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2019-01-25.12:05:04.644>
labels = ['3.7', '3.8', '3.9', 'expert-C-API', 'type-feature', 'docs']
title = 'C API dictionary views type checkers are not documented'
updated_at = <Date 2019-12-10.11:21:51.844>
user = 'https://github.com/salty-horse'

bugs.python.org fields:

activity = <Date 2019-12-10.11:21:51.844>
actor = 'serhiy.storchaka'
assignee = 'docs@python'
closed = False
closed_date = None
closer = None
components = ['Documentation', 'C API']
creation = <Date 2019-01-25.12:05:04.644>
creator = 'salty-horse'
dependencies = []
files = []
hgrepos = []
issue_num = 35827
keywords = []
message_count = 2.0
messages = ['334355', '358182']
nosy_count = 4.0
nosy_names = ['salty-horse', 'christian.heimes', 'docs@python', 'serhiy.storchaka']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue35827'
versions = ['Python 3.7', 'Python 3.8', 'Python 3.9']

@salty-horse
Copy link
Mannequin Author

salty-horse mannequin commented Jan 25, 2019

dictobject.h defines several helpers to ease checking of dictionary view types. If they are meant to be part of the API, they should be documented.

PyDictKeys_Check
PyDictItems_Check
PyDictValues_Check
PyDictViewSet_Check

Should they be added to dict.rst, or a separate file?

@salty-horse salty-horse mannequin assigned docspython Jan 25, 2019
@salty-horse salty-horse mannequin added docs Documentation in the Doc dir type-feature A feature request or enhancement labels Jan 25, 2019
@serhiy-storchaka
Copy link
Member

They were added in a22e8bd. Additional types like PyDictRevIterKey_Type were added later. I am not sure that all these types should be exposed in the public C API.

@serhiy-storchaka serhiy-storchaka added 3.7 (EOL) end of life 3.8 only security fixes 3.9 only security fixes labels Dec 10, 2019
@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
@iritkatriel
Copy link
Member

They seem to be misnamed too. With these checks they should probably have been named *_CheckExact:

#define PyDictKeys_Check(op) (Py_Type(op) == &PyDictKeys_Type)
#define PyDictItems_Check(op) (Py_Type(op) == &PyDictItems_Type)
#define PyDictValues_Check(op) (Py_Type(op) == &PyDictValues_Type)

@iritkatriel iritkatriel removed 3.9 only security fixes 3.8 only security fixes 3.7 (EOL) end of life labels May 22, 2023
@encukou
Copy link
Member

encukou commented May 22, 2023

They can't be subclassed (they don't have Py_TPFLAGS_BASETYPE), so the C equality is good for both _Check and _CheckExact.

They are in a public header, so removing them would need a deprecation cycle. Better to document them, IMO. (PRs welcome.)

If we deprecate them: you can use PyType_IsSubtype for any type that doesn't have a _Check convenience macro.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs Documentation in the Doc dir topic-C-API type-feature A feature request or enhancement
Projects
None yet
Development

No branches or pull requests

4 participants