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

Fix #240 #263

Merged
merged 1 commit into from
Nov 11, 2018
Merged

Fix #240 #263

merged 1 commit into from
Nov 11, 2018

Conversation

kngwyu
Copy link
Member

@kngwyu kngwyu commented Nov 9, 2018

According to python doc, Py_TPFLAGS_HEAPTYPE is set when the type object itself is allocated on the (python?) heap.
But currently it's set for all subclasses, though we always have pyclass' type object as a static variable.
This causes segfault in #240.
I'm sure current approach is wrong, but I'm not sure how we should distinct a type is a heaptype or not(Maybe we should extend current API to have is_heap flag?).
Anyway, I feel there's many points to be fixed around our current approach for type object and tp_flags.
cc: @pganssle, @konstin

def test_tz_class_introspection():
tzi = rdt.TzClass()

assert tzi.__class__ == rdt.TzClass
assert repr(tzi) == "TzClass()"
assert repr(tzi).startswith('<rustapi_module.datetime.TzClass object at')
Copy link
Member

Choose a reason for hiding this comment

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

Can we not define a custom repr for this to make this test pass?

Or is the problem not hit if you define a custom repr?

Copy link
Member Author

Choose a reason for hiding this comment

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

Or is the problem not hit if you define a custom repr

I haven't tested it but I think so, since this segfault happens when creating class name string.

Copy link
Member

Choose a reason for hiding this comment

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

Ah, good point, though I think the repr could be effectively:

def __repr__(self):
    return "%s()" % self.__class__.__name__

Your version seems fine, though.

Copy link
Member

Choose a reason for hiding this comment

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

I'm going to take it as it because I want that change for 0.5.0, but feel free to change this into something different later

@konstin
Copy link
Member

konstin commented Nov 11, 2018

Thank you for tracking this down. This is a really import fix!

@konstin konstin merged commit 4c0ddbe into PyO3:master Nov 11, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants