Change get_scope parameter type from FunctionType to object

[samwaseda]

I would like to use it for class objects as well, in which case FunctionType is not broad enough.

[github-actions]

👈 Launch a binder notebook on branch pyiron/flowrep/samwaseda-patch-1

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.97%. Comparing base (507e9b2) to head (3c260aa).
⚠️ Report is 20 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #186   +/-   ##
=======================================
  Coverage   97.96%   97.97%           
=======================================
  Files          34       34           
  Lines        2259     2268    +9     
=======================================
+ Hits         2213     2222    +9     
  Misses         46       46           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Copilot]

Pull request overview

This PR broadens flowrep.models.parsers.object_scope.get_scope’s type annotation so it can be used with class objects (not only FunctionType), enabling scope extraction for additional callable-like objects during parsing.

Changes:

• Remove FunctionType import and widen get_scope’s parameter type hint to object.
• Keep scope construction logic based on the module globals plus builtins.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

@samwaseda I've opened a new pull request, #187, to work on those changes. Once the pull request is ready, I'll request review from you.

[liamhuber]

Yeah! Good extension. I don't see any conceptual concern broadening the type here. As long as it works for some broader testing, I'm totally happy.

Codecov is complaining in one spot that should be easy to cover -- so easy that I'm confused why your current tests aren't covering it.

The other thing I'd like to see is some "rubber meets the road" tests of actual other callables. A builtin callable like int, a class, and a class method all come to mind, but a decent LLM might think of an edge case I'm missing.

[liamhuber]

Codecov is showing that this line is not covered. I'd like to get it fully covered, but I'm a little confused because it looks to me like test_none_module_fallback_via_dunder_module should be hitting this?

[samwaseda]

@copilot Write a unit test to cover the line module = sys.modules.get(module_name)

[Copilot]

@samwaseda I've opened a new pull request, #188, to work on those changes. Once the pull request is ready, I'll request review from you.

[samwaseda]

@copilot Address @liamhuber's above comment: "The other thing I'd like to see is some "rubber meets the road" tests of actual other callables. A builtin callable like int, a class, and a class method all come to mind, but a decent LLM might think of an edge case I'm missing."

[Copilot]

@samwaseda I've opened a new pull request, #189, to work on those changes. Once the pull request is ready, I'll request review from you.