Skip to content

Add getset_descriptor #1738

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 10 commits into from
Feb 6, 2020
Merged

Add getset_descriptor #1738

merged 10 commits into from
Feb 6, 2020

Conversation

youknowone
Copy link
Member

@youknowone youknowone commented Feb 2, 2020

  • Add getset_descriptor
  • Remove PyReadOnlyProperty
  • #[pyproperty] now generates getset. PyProperty is only used for python code.

@coolreader18
Copy link
Member

How is PyGetSet different from PyProperty?

@youknowone
Copy link
Member Author

youknowone commented Feb 3, 2020

in CPython, PyGetSet corresponds to getset_descriptor while PyProperty corresponds to property. this is data specialized form of property. How about thinking like PyBulitinMethod and PyBoundMethod relationship?

Practically, it is only created with native functions with solid getter and setter signature. So it must be related to performance. For compatibility point of view, the properties of None object matters too. Because descriptors get obj argument for __get__ and checking its existance by not-equal-None, properties of None object is nessessarily broken. getset_descriptor doesn't check it but always call getter function.

@youknowone youknowone force-pushed the getset branch 2 times, most recently from cdcec67 to ced2423 Compare February 3, 2020 16:56
@coolreader18
Copy link
Member

Maybe it would be good to replace all the property APIs (new_property, PropertyBuilder, etc) with these descriptors, if not in this PR then in another one. It seems like there's not really a benefit to using properties from native code, so in basically every situation you'd prefer getset over property (just not in, like, the builtins.property() decorator)

@youknowone
Copy link
Member Author

After grep CPython code, yes, that sounds true.

@youknowone youknowone force-pushed the getset branch 5 times, most recently from 451fc24 to 4eca2b0 Compare February 3, 2020 20:06
@youknowone youknowone force-pushed the getset branch 4 times, most recently from 876d468 to 2bce242 Compare February 5, 2020 15:17
@youknowone youknowone force-pushed the getset branch 2 times, most recently from 07a6bba to 7626f13 Compare February 5, 2020 16:29
@youknowone youknowone force-pushed the getset branch 2 times, most recently from 556a919 to 5b270b4 Compare February 5, 2020 17:10
@youknowone
Copy link
Member Author

@coolreader18 It seems this is finally done! will you review it please?

@youknowone
Copy link
Member Author

I attached #1736 to here because it is trivial derived work from this PR

Copy link
Member

@coolreader18 coolreader18 left a comment

Choose a reason for hiding this comment

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

Looks good, I had one note about the getters/setters for SyntaxError but otherwise feel free to merge.

@youknowone
Copy link
Member Author

Other getters of SyntaxError are actually not a getter by args. they are attributes set by set_attr

@coolreader18 coolreader18 merged commit e7ea486 into RustPython:master Feb 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants