bpo-33190: elucidated types.new_class docstring#6317
Conversation
Calls to `type` such as `type("C", (Generic[MyTypeVar],), {})` will raise an error directing the person to use `types.new_class` instead. Upon first glance both functions have similar signatures, and this seems to imply they should be used the same. However the 3rd argument for each is completely different. I've tried to clear this up in the docstring.
|
Hello, and thanks for your contribution! I'm a bot set up to make sure that the project can legally accept your contribution by verifying you have signed the PSF contributor agreement (CLA). Unfortunately our records indicate you have not signed the CLA. For legal reasons we need you to sign this before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue. Thanks again to your contribution and we look forward to looking at it! |
|
...except I have signed the CLA. Maybe it hasn't been reviewed yet...? |
|
The CLA can take at least one business day to process. Sometimes more. |
ilevkivskyi
left a comment
There was a problem hiding this comment.
Our rules is that any PRs not specific to a perticular version should be made against master branch, and then backported to the relevant release branches.
So this one should be closed, and instead please open a PR against master branch.
| exec_body -- a callback used to populate the freshly created class namespace | ||
|
|
||
| Note: the class-creation functionality of `new_class` is similar to `type`. However, | ||
| calls to `type` cannot be directly substituted by calls to `new_class`. For example: |
There was a problem hiding this comment.
Although, you were hit but this particular problem, I don't think it deserves a dedicated note. Just describing clearly every argument is enough. Plus maybe an example of usage like this:
For example, the class definition::
class C(A, B, foo=bar):
x = 42
can be translated to the following call to `new_class`::
C = new_class('C', (A, B), {'foo': bar}, lambda ns: ns.update(x=42))
| Arguments: | ||
| name -- the new class name | ||
| bases -- sequence of parent classes (default ()) | ||
| kwds -- mapping of keyword arguments to be supplied to parents' `__init_subclass__` |
There was a problem hiding this comment.
It is not only passed to __init_subclass__, it will be passed also to __prepare__ of the computed metaclass, to the metaclass call itself, and in future to any other place required by the class creation machinery. This sentence should be reformulated to something simpler but correct, like mapping of keyword arguments in an equivalent class statement (see example below).
| """Create a class object dynamically using the appropriate metaclass. | ||
|
|
||
| Arguments: | ||
| name -- the new class name |
There was a problem hiding this comment.
Please indent the argument list.
There was a problem hiding this comment.
I tried to do it just like in PEP 257 which doesn't have indentation. But I'll indent next time.
|
I will close and reopen against the master branch. I don't agree about the need for the dedicated note specifically because the error message produced by However I'll try to tighten it up a bit in the replacement PR. Do I also need to add a news item like the bot says for a change to a docstring? Or will you just apply the skip news tag? |
No. |
|
However reading it again, probably the example usage serves the same purpose. Thanks! |
Calls to
typesuch astype("C", (Generic[MyTypeVar],), {})will raise an error directing the person to usetypes.new_classinstead. Upon first glance both functions have similar signatures, and this seems to imply they should be used the same. However the 3rd argument for each is completely different.I've tried to clear this up in the docstring.
https://bugs.python.org/issue33190