-
-
Notifications
You must be signed in to change notification settings - Fork 31.8k
gh-121249: adjust formatting codes for complex types in struct/ctypes modules #132827
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
Conversation
…ctypes modules F - for float _Complex D - for double _Complex G - for long double _Complex (not supported by the struct module)
@@ -209,13 +209,13 @@ class c_longdouble(_SimpleCData): | |||
|
|||
try: | |||
class c_double_complex(_SimpleCData): | |||
_type_ = "C" | |||
_type_ = "D" | |||
_check_size(c_double_complex) | |||
class c_float_complex(_SimpleCData): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe you should define c_float_complex
first, just like c_float
is defined before c_double
above?
double complex D; | ||
float complex F; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe change order?
double complex D; | |
float complex F; | |
float complex F; | |
double complex D; |
@skirpichev At the expense of a larger diff, maybe you should review defining/declaring things related to |
I'm not sure this worth.
And fixing that for complex types will not change this state. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@@ -648,14 +648,14 @@ union result { | |||
int i; | |||
long l; | |||
long long q; | |||
long double D; | |||
long double g; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@vstinner, this is something I worry about here.
IIUIC, this is a private interface and we can rename it's members. It seems this is not used across the codebase, but I appreciate a second look. (No tests seems to be affected, though maybe it's just lack of test coverage.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems this is not used across the codebase,
I confirm, the long double
member is simply not used. I would suggest to remove it (but in a separated PR).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would suggest to remove it
I'm not sure. It seems, naming of union members aren't used - only size is important.
As long as we keep one-letter codes, I think it's good to have corresponding members in this struct.
Same holds for struct tagPyCArgObject
- I forgot to update that. I'll make a patch. BTW do we need different (wrt union result
) unnamed union here? I doubt.
Merged, thank you. |
For compatibility with numpy:
'F'
- forfloat _Complex
'D'
- fordouble _Complex
'G'
- forlong double _Complex
(not supported by the struct module)📚 Documentation preview 📚: https://cpython-previews--132827.org.readthedocs.build/