-
-
Notifications
You must be signed in to change notification settings - Fork 30k
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
function annotation for builtin and C function #47458
Comments
It is better if the function annotation(PEP-3107) can be supported by |
Extension modules can use PyFunction_GetAnnotations() to access and I added some documentation for these functions in r64934. |
Sorry I haven't state the issue clearly. For this issue I mean the |
PyCFunctionObject has indeed no way to store annotations. This could be The PyMethodDef structure could grow a "ml_annotations" member. A patch |
By considering the implementing, some problems emerged. First of all, as we know, all CFunctionObject and their attributes are Secondly, the annotation value can be abitrary expression, and then, Thanks! |
Anyway, for a SWIG module I think the best is to set the __annotations__ |
I think there is reason that CFunctionObjects are immutable: single If it should be immutable, then we should use something like static For SWIG, there's a way to bypass the Python side proxy, eg. for a |
There never should be multiple Python interpreters running in the same |
As I understand, at least C extension modules, which built as shared |
On Wed, Jul 23, 2008 at 8:44 PM, Haoyu Bai <report@bugs.python.org> wrote:
The operating system should provide memory protection between processes.
|
Shared libraries share code, not memory. But were you talking about sub-interpreters? |
I found the explanation of why buitl-ins are immutable: For the curious: there are two reasons why changing built-in classes is (From http://www.python.org/download/releases/2.2.3/descrintro/) Is the statement still valid for current version of Python? |
The "First" argument does not apply here, we could just say "annotations A solution would be a global (or interpreter-local if we really want to |
I don't think it's reasonable not to support multiple interpreters in a If we need to allow function annotations to be arbitrary PyObjects, I would have thought that any such PyObjects are going to be valid only Certainly it would be unpleasant if a change to one of the objects in |
What is the status of this bug? |
Awaiting a patch. |
This issue has been addressed by the PEP-436 (Argument Clinic) which supports annotation per parameter and annotation on the return type. This PEP has been implemented in Python 3.4. I suggest to close the issue, but I would prefer that Larry closes the issue instead of me, he wrote the PEP. |
Argument Clinic theoretically could support annotations for builtins, though it's never been tested. I don't know if it makes sense to close this bug yet. |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: