FEAT: add dir as property

[Alberto-DM]

Description

This PR introduces a DirMixin and a central PyAedtBase class to simplify interactive exploration and provide a unified foundation for all project classes.

• DirMixin adds a .public_dir property for instances to quickly inspect available attributes and methods, filtering out private/internal names.
• DirMixin redefines the __dir__ method to reorder the output in order to improve IDEs autocompletion. The public attributes are shown first, followed by the private ones (starting with _).
• PyAedtBase inherits from DirMixin and serves as a central base class for all other classes, making it easy to add additional mixins or shared functionality in the future.

Example

Prior to this feature the method exploration required to type back and forth in the command line:

dir(cube)                  
cube.faces                   
dir(cube.faces[0])         
cube.faces[0].edges[0]      
dir(cube.faces[0].edges[0]) 

Now we can explore the methods and properties of an object by simply doing this:

cube.public_dir
cube.faces[0].public_dir
cube.faces[0].edges[0].public_dir

Benefits

• Faster interactive exploration and autocomplete in REPL/notebooks.
• Single point to add future mixins or shared utilities.
• Cleaner, more maintainable class hierarchy.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 83.25%. Comparing base (94052b7) to head (8188b57).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6716      +/-   ##
==========================================
+ Coverage   81.04%   83.25%   +2.20%     
==========================================
  Files         245      246       +1     
  Lines       77272    77402     +130     
==========================================
+ Hits        62623    64438    +1815     
+ Misses      14649    12964    -1685     

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ecoussoux-ansys]

After doing some research, I see no objection to your proposal, as I could not find any resource discouraging this type of implementation.

I think using the builtin dir in code for inspecting attributes and methods is fine, as also discussed here.
And introducing dir as a property through a mixin class is I believe a pythonic approach, knowing that such mixins were already considered for pyaedt in #5787 and implemented in #5755 for a specific functionality.

I do understand the usecase for that new property and the usability improvement. Same goes for the PyAedtBase class that could gather additional mixins or shared functionality in the future.
However, can we already think of such additions in the near future that would further populate that PyAedtBase class? In case that would not yet be very clear, I wonder if the benefits brought by DirMixin alone justify the pretty overarching refactoring performed here, given the base class gets passed to all (?) others throughout the project?

All in all, the changes do look good to me (nice that tests are provided as well)!
But given how pervasive they are and the lack of a truly relevant assessment on my part regarding the novelty introduced, I would strongly suggest waiting for @SMoraisAnsys's comments on this!

[SMoraisAnsys]

Thanks for opening that PR @Alberto-DM
While I do like the idea of having some mixin that could share behavior over all classes, I'm not really fan of the dir property. I might be wrong, but I feel like this property brings:

• risk of confusion for people who are familiar with dir(), this "breaks" implicit convention of the language;
• little additional value when the risk of confusion are non negligible.
  Also, I think we should focus on improving the type hints provided through the code base. This would really help a lot with autocompletion in modern IDEs. When thinking about notebook, isn't the use of already enough to get the attributes ? If it's because the list starts with private / protected attributes and methods, we could just rewrite __dir__ by sorting the elements and placing the one with _ at the end of the list.

Other though: renaming into public_attrs would avoid confusion.

Open to discussion :)

[Alberto-DM]

@SMoraisAnsys I understand your concerns. Regarding the utility of having dir as a property: I personally use dir() a lot for exploring properties and methods, and I know I’m not the only one. Renaming the property to something like public_attrs (or another name) it is a good compromise.

I also really like the idea of improving autocompletion by reordering the dir() output. Overriding __dir__ is a neat solution, and we can implement it easily now with the new PyAedtBase class.

@ecoussoux-ansys yes, implementing PyAedtBase was a lot of work, but now it is done 🙂 and I believe it adds real value to PyAEDT, and this kind of refactoring is best done before we reach version 1.0.

[Alberto-DM]

Following the suggestions from @SMoraisAnsys I renamed the dir property in public_dir.
I also defined a __dir__method to the DirMixin to sort the dir() output.