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 issue #596 'slice is not subclassable' #1038

Merged
merged 1 commit into from
Jan 4, 2016
Merged

Fix issue #596 'slice is not subclassable' #1038

merged 1 commit into from
Jan 4, 2016

Conversation

corona10
Copy link

Fix issue #596
make slice to be not subclassable.

@corona10 corona10 changed the title fix issue #596 'slice is not subclassable' Fix issue #596 'slice is not subclassable' Dec 28, 2015
fix issue #596 'slice is not subclassable'
@undingen
Copy link
Contributor

undingen commented Jan 4, 2016

LGTM, thanks for the patch!

While this fixes it for the slice type there are a bunch of other types which still allow subclassing even they should not. I'm wondering if we should not at some point switch to a approach where types have to explicitly say what additional flags they want to have because it may be less work and more similar to the capi and cpython.

undingen added a commit that referenced this pull request Jan 4, 2016
Fix issue #596 'slice is not subclassable'
@undingen undingen merged commit 7fc3720 into pyston:master Jan 4, 2016
@corona10
Copy link
Author

corona10 commented Jan 4, 2016

@undingen Thanks i agree with your opinion. Do you know any good document or article to get the relevant information about which not to be subclassable types. When i know that lists than i can try to find another approach.

@undingen
Copy link
Contributor

undingen commented Jan 4, 2016

I don't know of a list of types which don't allow subclassing :-(.
My approach would be to remove the line inside the constructor of BoxedClass which always enables subclassing. And than add the missing flags to all our C++ types which show up inside a search for Py_TPFLAGS_BASETYPE inside cpythons Objects/* dir. CAPI types should all be fine so I suspect this are not many types which need it and this are probably mostly types where we already are modifying the tp_flags member.

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