Skip to content

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

Merged
merged 1 commit into from
Apr 23, 2025

Conversation

skirpichev
Copy link
Member

@skirpichev skirpichev commented Apr 23, 2025

For compatibility with numpy:

  • 'F' - for float _Complex
  • 'D' - for double _Complex
  • 'G' - for long double _Complex (not supported by the struct module)

📚 Documentation preview 📚: https://cpython-previews--132827.org.readthedocs.build/

…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):
Copy link

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?

Comment on lines +656 to +657
double complex D;
float complex F;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe change order?

Suggested change
double complex D;
float complex F;
float complex F;
double complex D;

@dalcinl
Copy link

dalcinl commented Apr 23, 2025

@skirpichev At the expense of a larger diff, maybe you should review defining/declaring things related to float complex BEFORE things related to double complex. Right now there is a mixture of orders, and that may make things confusing or error-prone with future maintenance tasks.

@skirpichev
Copy link
Member Author

maybe you should review defining/declaring things related to float complex BEFORE things related to double complex.

I'm not sure this worth.

Right now there is a mixture of orders

And fixing that for complex types will not change this state.

Copy link
Member

@vstinner vstinner left a 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;
Copy link
Member Author

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.)

Copy link
Member

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).

Copy link
Member Author

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.

@vstinner vstinner merged commit 85f89cb into python:main Apr 23, 2025
51 checks passed
@vstinner
Copy link
Member

Merged, thank you.

@skirpichev skirpichev deleted the rename-struct-types/121249 branch April 23, 2025 14:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants