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

IronPython handles descriptor replacement differently than CPython #843

Open
mickp opened this issue Jan 22, 2025 · 2 comments
Open

IronPython handles descriptor replacement differently than CPython #843

mickp opened this issue Jan 22, 2025 · 2 comments

Comments

@mickp
Copy link
Contributor

mickp commented Jan 22, 2025

If a type is patched with a descriptor, referencing the name on the type (rather than an instance) hits the descriptor's getter/setter, where it does not in CPython.

class SomeDescriptor(object):
    def __get__(self, obj, obj_type=None):
        print('__get__', self, obj, obj_type)
        return self

    def __set__(self, obj, value):
        print('__set__', self, obj, value)
        return self


class Thing(object):
    @property
    def value(self):
        return 123


original_property = Thing.value
Thing.value = SomeDescriptor()
Thing.value = original_property
print(Thing().value)

CPython gives:

123

while IronPython gives

('__set__', <SomeDescriptor object at 0x000000000000006C>, None, <property object at 0x000000000000006D>)
('__get__', <SomeDescriptor object at 0x000000000000006C>, <Thing object at 0x000000000000006E>, <class '__main__.Thing'>)
<SomeDescriptor object at 0x000000000000006C>

Version info:
IronPython 2.7.12 (2.7.12.1000)
[.NETFramework,Version=v4.5 on .NET Framework 4.8.9232.0 (64-bit)]

Python 2.7.18 (v2.7.18:8d21aa21f2, Apr 20 2020, 13:25:05) [MSC v.1500 64 bit (AMD64)] on win32

@slozier
Copy link
Contributor

slozier commented Jan 22, 2025

For reference, this is fixed in ipy3. Maybe by IronLanguages/ironpython3#1272?

@mickp
Copy link
Contributor Author

mickp commented Jan 24, 2025

Thanks. I'm working around it python-side for now. However, this prompted me to take another look at getting the project updated to use IronPython 3, but I hit some fundamental issues I don't understand. I started a new discussion over in the 3 repo: IronLanguages/ironpython3#1881

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

No branches or pull requests

2 participants