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

Object identity, Interfaces and Attributes #2019

Open
wants to merge 15 commits into
base: master
Choose a base branch
from

Conversation

rmadsen-ks
Copy link
Contributor

@rmadsen-ks rmadsen-ks commented Nov 18, 2022

This PR contains multiple improvements:

  • All classes inheriting from a .net class has their own .net type. This means they can be returned and given as arguments without loosing their original identity (and properties).
  • Interfaces can be implemented. Also classes only inheriting interfaces are supported.
  • Attributes can be used in multiple different flavors.
    • Class attributes using e.g @attribute(Browsable(False)), or clr_attributes = [Browsable(False), ...]
    • Method attributes for methods exported to .NET.
          @attribute(DisplayName("X"))
          @method()
          def X(self):
                pass
      
    • Property attributes using property(Double,0.0).add_attribute(DisplayName("X")

Close #1776, #1774, #1768

Check all those that are applicable and complete.

  • Make sure to include one or more tests for your change
  • If an enhancement PR, please create docs and at best an example
  • Ensure you have signed the .NET Foundation CLA
  • Add yourself to AUTHORS
  • Updated the CHANGELOG

Added a unit test which consists ofa python class inheriting from a C# class which has a virtual generic method. In this version, this causes a InvalidProgramException to be thrown during class creation.
Previously an exception was thrown during class creation if the python class inherited from a class with a virtual generic method.

This has been fixed by ignoring generic methods when creating overloads in the generated class. Note, this means that generic virtual methods cannot be overridden in python code.
- Changed the behavior so that a .NET is always created when the base type is also a .NET type.
- Added shortened Attribute aliases which just generates tuples.
- More general CLR base class support - creating a class instance from C# is now more similar to creating one from python.
- Added attribute decorator to clr.py.
- Added testing for the various possibilities
- Fixed search bug in AssocAttribute
- Added testing
Added support for specifying attributes on property-methods (eg. get/set attributes).
Added a few cleanups and comments.
Comment on lines +152 to +156
if (!clsDict.HasKey("__namespace__"))
{
clsDict["__namespace__"] =
(clsDict["__module__"].ToString()).ToPython();
}
Copy link
Member

Choose a reason for hiding this comment

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

Can't introduce breaking changes

Comment on lines +20 to +21
Python.Runtime.Runtime.PythonDLL =
"C:\\Python37.2\\python37.dll";
Copy link
Member

Choose a reason for hiding this comment

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

clean up the history

Comment on lines +17 to +21
/// <summary>
/// Creates a new instance of PythonTypeAttribute.
/// </summary>
/// <param name="pyTypeModule"></param>
/// <param name="pyTypeName"></param>
Copy link
Member

Choose a reason for hiding this comment

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

This XML doc does not have any useful information.

@lostmsu
Copy link
Member

lostmsu commented Nov 29, 2022

Please, split smaller fixes into individual PRs (e.g. #1776). I'd rather have #1774 also have its own PR as the code does not seem to be interdependent.

@rmadsen-ks
Copy link
Contributor Author

@lostmsu, ok, I understand. I just want to make sure you agree with the intentions here before I spend a lot of work trying to separate things out. What about the support for Attributes and interfaces? Are you ok with adding something like that?

Anyway, it sounds like you want #1774 implemented in a specific way? Maybe it is easier that it is not me who develops that then?

I'll try to take #1776 and create a separate PR for it.

@rmadsen-ks
Copy link
Contributor Author

First two parts: #2028, #2026

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.

Generic virtual method in baseclass causes InvalidProgramException
2 participants