feat: add get and create methods and **kwarg support for create by Gobot1234 · Pull Request #4866 · ansys/pyfluent

Gobot1234 · 2026-01-27T20:52:35Z

The API surface now looks like which is fairly ORM like

AxisBoundary.get(solver, name='boundary')
AxisBoundary.all(solver)
AxisBoundary.create(solver, name='foo', other='parameters that', are='just values')

Context

Fixes #4863
And adds create and get methods as more clear methods for using name and new_instance_name to the object oriented API

Scope

This PR affects all of the object oriented API, and some of the settings API related code surrounding child creation

This is due to the following changes:

Adding all(), create() and get() methods to the settings shorthand classes
Explicitly called out anonymous creation as supported
Adding keyword arguments to the settings classes at creation (Support for kwargs that pass through to the instance properties in .create() and the object oriented types #4863)

This needs settings api changes that I haven't figured out

Copilot

Pull request overview

This PR adds get and create class methods to the object-oriented API for clearer alternatives to using name and new_instance_name parameters. The implementation refactors initialization logic into a shared mixin class and enables passing additional kwargs when creating objects.

Changes:

Refactored initialization logic into _SettingsInitializerMixin base class
Added get class method to _SingletonSetting for retrieving singleton instances
Added create class method to _CreatableNamedObjectSetting for creating new instances with optional attributes

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
src/ansys/fluent/core/solver/settings_builtin_bases.py	Adds mixin class for shared initialization logic and implements `get`/`create` class methods
src/ansys/fluent/core/solver/flobject.py	Updates `_create_child_object` and `__getitem__` to accept and pass kwargs, enabling attribute setting during object creation

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

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

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

Copilot

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 5 comments.

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

seanpearsonuk · 2026-01-28T09:40:50Z

@Gobot1234 Please can we define the scope of the current work. E.g.:

Adding create() and get() methods to the settings classes
Allowing creation there without need for a name to be specified?
Adding keyword arguments to the settings classes (at creation?)

If we know the scope, it makes it easier to understand the changes. Thanks.

Copilot

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Copilot

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

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

Copilot · 2026-01-28T11:00:50Z

+
+    @classmethod
+    def get(cls, settings_source: SettingsBase | Solver | None = None, /, *, name: str) -> Self:
+        """Get and return the singleton instance of this object in Fluent.


The docstring says 'singleton instance' but this method can be used on non-singleton classes like _CreatableNamedObjectSetting. The description should be more generic, such as 'Get and return an instance of this object in Fluent' to accurately reflect its usage across different setting types.

Suggested change

"""Get and return the singleton instance of this object in Fluent.

"""Get and return an instance of this object in Fluent.

Copilot

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated 5 comments.

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

Copilot · 2026-01-28T12:44:58Z

+        *,
+        name: str,
+    ) -> Self:
+        """Get and return the singleton instance of this object in Fluent.


The docstring describes this method as returning a 'singleton instance', but this is misleading for a named object that can have multiple instances. Consider changing to 'Get and return the named instance of this object in Fluent.'

seanpearsonuk · 2026-01-29T10:01:59Z

@Gobot1234 In the code snippets in your description, an important use case is binding the solver
context at construction time rather than passing it into each accessor method (it’s fine to
support both). For example:

AxisBoundary(solver).get(name='boundary')
# or hold onto a solver-context-specific AxisBoundary object (which can be passed around)
axis = AxisBoundary(solver)
axis.all()
axis_foo = axis.create(name='foo', other='parameters that', are='just values')
axis_anon = axis.create(other='parameters that', are='just values')

This makes the interface more substitutable and the code more flexible, since consumers can
operate on a solver-bound facade without needing to thread the solver through every call.
From the client’s point of view, the solver argument can otherwise feel like an
implementation detail.

Perhaps both formats are already supported in what you have implemented?

Gobot1234 · 2026-01-29T11:18:48Z

@Gobot1234 In the code snippets in your description, an important use case is binding the solver context at construction time rather than passing it into each accessor method (it’s fine to support both). For example:
AxisBoundary(solver).get(name='boundary')
# or hold onto a solver-context-specific AxisBoundary object (which can be passed around)
axis = AxisBoundary(solver)
axis.all()
axis_foo = axis.create(name='foo', other='parameters that', are='just values')
axis_anon = axis.create(other='parameters that', are='just values')
This makes the interface more substitutable and the code more flexible, since consumers can operate on a solver-bound facade without needing to thread the solver through every call. From the client’s point of view, the solver argument can otherwise feel like an implementation detail.

Perhaps both formats are already supported in what you have implemented?

I think I can add support for this form though it'll require more changes. I was honestly thinking the best way to operate on this thing was using the following as it's scoped nicely and closes itself when required

with pyfluent.Solver.from_install() as solver, pyfluent.using(solver):
    AxisBoundary().get(name='boundary')

seanpearsonuk · 2026-01-29T11:45:17Z

@Gobot1234 In the code snippets in your description, an important use case is binding the solver context at construction time rather than passing it into each accessor method (it’s fine to support both). For example:
AxisBoundary(solver).get(name='boundary')
# or hold onto a solver-context-specific AxisBoundary object (which can be passed around)
axis = AxisBoundary(solver)
axis.all()
axis_foo = axis.create(name='foo', other='parameters that', are='just values')
axis_anon = axis.create(other='parameters that', are='just values')
This makes the interface more substitutable and the code more flexible, since consumers can operate on a solver-bound facade without needing to thread the solver through every call. From the client’s point of view, the solver argument can otherwise feel like an implementation detail.
Perhaps both formats are already supported in what you have implemented?
I think I can add support for this form though it'll require more changes. I was honestly thinking the best way to operate on this thing was using the following as it's scoped nicely and closes itself when required
with pyfluent.Solver.from_install() as solver, pyfluent.using(solver):
    AxisBoundary().get(name='boundary')

I agree that the context manager pattern is a good one, and it’s something we already encourage for solver lifetime and scoping.

However, I think that concern is largely orthogonal to how solver context is modeled in the object API itself.

In the pattern you show:

with pyfluent.Solver.from_install() as solver, pyfluent.using(solver):
    AxisBoundary().get(name='boundary')

AxisBoundary is effectively acting as a namespace whose methods depend on ambient state. By contrast, when the solver is bound at construction time, AxisBoundary(solver) becomes a solver-scoped facade that encapsulates its context. That keeps the public methods simpler, since they no longer need to expose solver as an argument that conceptually belongs to the object rather than the call.

Context managers mitigate some ergonomics, but they don’t quite provide the same expressive power as a context-aware object. That’s the reason I prefer constructor binding as the primary model (even if method-level solver passing remains supported).

seanpearsonuk · 2026-01-29T13:35:57Z

@deprecated("Use SolidCellZone.all() instead")
class SolidCellZones(
    _SingletonSetting,
    type(settings_root_261.setup.cell_zone_conditions.solid),
):
    create = settings_root_261.setup.cell_zone_conditions.solid.create

class SolidCellZone(
    _CreatableNamedObjectSetting,
    type(settings_root_261.setup.cell_zone_conditions.solid.child_object_type),
):
    create = settings_root_261.setup.cell_zone_conditions.solid.create

@deprecated("Use BoundaryCondition.all() instead")
class BoundaryConditions(
    _SingletonSetting,
    type(settings_root_261.setup.boundary_conditions),
):
    ...

class BoundaryCondition(
    _NonCreatableNamedObjectSetting,
    type(settings_root_261.setup.boundary_conditions.child_object_type),
):
    ...

@deprecated("Use AxisBoundary.all() instead")
class AxisBoundaries(
    _SingletonSetting,
    type(settings_root_261.setup.boundary_conditions.axis),
):
    create = settings_root_261.setup.boundary_conditions.axis.create

class AxisBoundary(
    _CreatableNamedObjectSetting,
    type(settings_root_261.setup.boundary_conditions.axis.child_object_type),
):
    create = settings_root_261.setup.boundary_conditions.axis.create

after talking with Sean we agreed it best to remove the plural versions of the classes in favour of using something which I would describe as more ORM like which feels much more familiar to me at least.

API surface now looks like

AxisBoundary.get(solver, name='boundary')
AxisBoundary.all(solver)
AxisBoundary.create(solver, name='foo', other='parameters that', are='just values')

@mkundu1 I'd like to get your feedback on this point too.

…fluent into jhilton/create-and-find

Copilot

Pull request overview

Copilot reviewed 8 out of 8 changed files in this pull request and generated 4 comments.

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

Copilot · 2026-02-03T23:03:01Z

            elif k in obj.argument_names:
                newkwds[k] = v
-            else:
+            elif k not in obj.get_active_child_names():


This condition may not correctly filter out child object parameters passed to create(). If a child name exists but is not 'active', valid kwargs might still be filtered out. Consider validating this logic or adding a comment explaining when child names are 'active'.

Copilot · 2026-02-03T23:03:02Z

+    # Generate for all available versions
+    versions = sorted([v.number for v in all_versions()])


The comment mentions 'all available versions' but the actual code in if __name__ == '__main__' generates for all versions. This might cause unexpected behavior if run directly vs imported, as the main generation flow uses a single version. Consider clarifying or consolidating the version selection logic.

Gobot1234 · 2026-02-04T01:24:15Z

I'm curious as to whether it makes more sense to deprecate the singular or plurals, I think the plural methods make more sense grammatically to get() and all() for but less sense for create() but also interested to hear your opinion @mkundu1

Gobot1234 · 2026-02-13T17:05:47Z

+        Parameters
+        ----------
+        solver
+            Something with a ``settings`` attribute. If omitted the active session is assumed from the :func:`using` context manager.


Shouldn't use assumed here

Copilot

Pull request overview

Copilot reviewed 13 out of 13 changed files in this pull request and generated 7 comments.

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

+        self.name = name
+        super().__init__(
+            settings_source,
+            name=name,
+            **kwargs,
+            _db_name=(  # initialise as the parent container
+                (
+                    DATA[self.__class__._db_name][2]
+                    if name is None


-            super().__setattr__(name, value)
+    def _init_settings_instance(
+        self, parent: SettingsBase[object]
+    ) -> SettingsBase[object]:


+        root = _get_settings_root(
+            solver or _get_active_session()
+        )  # validate settings_source
+        instance = _CreatableNamedObjectSetting(
+            settings_source=root,
+            _from_create=True,
+            new_instance_name=name,
+            _db_name=DATA[cls._db_name][2],
+        )
+
+        obj = _get_settings_obj(root, instance)
+        return obj.create(name=name, **kwargs)


+from typing_extensions import Self
+
+from ansys.fluent.core.generated.solver.settings_261 import root as Settings
 from ansys.fluent.core.solver.flobject import (


            "rename",
            types.MethodType(lambda obj, name: _rename(self, name, cname), ret),
        )
+        ret.set_state(kwargs)


codacy-production · 2026-04-24T13:07:17Z

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer}
_{TIP This summary will be updated as you push new changes.}

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Co-authored-by: James Hilton-Balfe <gobot1234yt@gmail.com>

ansys-cla-bot · 2026-05-05T13:34:48Z

CLA Check Failed: Commit Author Verification Unsuccessful

One or more commits in this pull request contain missing or invalid author information. This issue may arise due to:

A change in the contributor's GitHub username
Deletion of the contributor's GitHub account
Corruption or alteration of commit author metadata
A co-authored commit where the co-author's GitHub username can't be retrieved

Please update the commit author details and push the updated commit to proceed with the CLA verification.

Copilot

Pull request overview

Copilot reviewed 13 out of 13 changed files in this pull request and generated 7 comments.

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

    with open(_PYI_FILE, "w") as f:
        for version in FluentVersion:
            f.write(


+        if settings_source is not None:
+            self.settings_source = settings_source
+        elif active_session:
+            self.settings_source = active_session
+        else:
+            raise RuntimeError("No active session and no settings_source provided.")
+


+        super().__init__(
+            settings_source,
+            name=name,
+            **kwargs,
+            _db_name=(  # initialise as the parent container
+                (
+                    DATA[self.__class__._db_name][2]
+                    if name is None
+                    else kwargs.get("_db_name")
+                ),


+    @classmethod
+    def all(cls, solver: Solver | None = None, /) -> list[Self]:
+        """Return a list of all instances of this object in Fluent."""
+        return cast(
+            list[
+                Self
+            ],  # yes this looks like an unsafe cast but this works via clearing the instance's dict
+            list(
+                cast(
+                    Any,
+                    _NonCreatableNamedObjectSetting(
+                        settings_source=solver,
+                        name="*",
+                        _db_name=DATA[cls._db_name][2],  # initialise parent container
+                    ),
+                ),
+            ),


+        root = _get_settings_root(
+            solver or _get_active_session()
+        )  # validate settings_source
+        instance = _CreatableNamedObjectSetting(
+            settings_source=root,
+            _from_create=True,
+            new_instance_name=name,
+            _db_name=DATA[cls._db_name][2],
+        )
+
+        obj = _get_settings_obj(root, instance)
+        return obj.create(name=name, **kwargs)
+


        obj = self._objects.get(name)
        if not obj:
-            obj = self._create_child_object(name)
+            obj = self._create_child_object(name, **kwargs)


@@ -0,0 +1 @@
+Add get and create methods and **kwarg support for create


seanpearsonuk · 2026-05-06T08:35:17Z

+        return "create" in getattr(cls, "_child_classes", {}) or "create" in getattr(
+            cls, "command_names", []


Please can we comment why we check both of these. Otherwise, it looks speculative.

seanpearsonuk · 2026-05-06T08:40:53Z

+        for legacy_name, v in DATA.items():
+            kind, path, recip = v
+            name = _get_public_class_name(legacy_name)
+            if isinstance(path, dict):


It's not easy to see what the significance is of path being a dict, or what should be done if it is.

Path here is a dict[FluentVersionSet, str]. It's only used by a small handful of things

{ since(FluentVersion.v251): "setup.dynamic_mesh", },

Is it expected to be a dict always? IOW is it an error if a different type is encountered there?

No it's just a dict when there's a version constraint on the path and the name changes between versions.

OK, please could you add that as a code comment.

seanpearsonuk · 2026-05-06T08:42:44Z

+        )
+        f.write("\n\n")
+        for legacy_name, v in DATA.items():
+            kind, path, recip = v


It's not easy to see what recip is.

Gobot1234 · 2026-05-06T16:46:29Z

I've had some words with both core (cpython) and ty (the typechecker) devs and I've needed to change the codegen a bit more to change the current settings generator script to output pascal cased names in the pyi file so that things don't break (currently they would if you evaluated them at runtime) and so ty is now better supported.

Add get and create methods to objects

df68d26

This needs settings api changes that I haven't figured out

Gobot1234 requested review from mkundu1 and seanpearsonuk as code owners January 27, 2026 20:52

Copilot AI review requested due to automatic review settings January 27, 2026 20:52

Gobot1234 requested review from hpohekar, mayankansys and prmukherj as code owners January 27, 2026 20:52

Copilot AI reviewed Jan 27, 2026

View reviewed changes

Comment thread src/ansys/fluent/core/solver/settings_builtin_bases.py Outdated

Comment thread src/ansys/fluent/core/solver/flobject.py

Comment thread src/ansys/fluent/core/solver/settings_builtin_bases.py Outdated

Comment thread src/ansys/fluent/core/solver/settings_builtin_bases.py Outdated

Update src/ansys/fluent/core/solver/settings_builtin_bases.py

61d4c66

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Copilot AI review requested due to automatic review settings January 28, 2026 02:24

Copilot AI reviewed Jan 28, 2026

View reviewed changes

Comment thread src/ansys/fluent/core/solver/settings_builtin_bases.py Outdated

Gobot1234 added 2 commits January 28, 2026 02:41

add a test case

f274df3

check get on non creatable objects

4e5c6be

Copilot AI review requested due to automatic review settings January 28, 2026 02:51

Copilot AI reviewed Jan 28, 2026

View reviewed changes

Gobot1234 changed the title ~~Add get and create methods to objects~~ feat: get and create methods and **kwarg support for create Jan 28, 2026

github-actions Bot added the new feature label Jan 28, 2026

chore: adding changelog file 4866.added.md [dependabot-skip]

269c59e

Gobot1234 changed the title ~~feat: get and create methods and **kwarg support for create~~ feat: add get and create methods and **kwarg support for create Jan 28, 2026

chore: adding changelog file 4866.added.md [dependabot-skip]

c40e9ed

Copilot AI review requested due to automatic review settings January 28, 2026 10:12

Copilot AI reviewed Jan 28, 2026

View reviewed changes

Update src/ansys/fluent/core/solver/flobject.py

91882b2

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Copilot AI review requested due to automatic review settings January 28, 2026 10:59

Copilot AI reviewed Jan 28, 2026

View reviewed changes

Gobot1234 added 2 commits January 28, 2026 11:28

fix tests + warning and fmt

9430310

generate the types for this

c38d797

Copilot AI review requested due to automatic review settings January 28, 2026 12:43

Copilot AI reviewed Jan 28, 2026

View reviewed changes

Gobot1234 added 3 commits February 3, 2026 16:42

Merge branch 'main' into jhilton/create-and-find

c3c5aee

add more tests and fix the data

20ce7f9

Merge branch 'jhilton/create-and-find' of https://github.com/ansys/py…

ae11446

…fluent into jhilton/create-and-find

Copilot AI review requested due to automatic review settings February 3, 2026 23:02

Copilot AI reviewed Feb 3, 2026

View reviewed changes

Gobot1234 mentioned this pull request Feb 11, 2026

Unclear how to use ReadCase #4773

Open

2 tasks

touch of work still doesnt work

fedf799

Gobot1234 commented Feb 13, 2026

View reviewed changes

add all as an alias for allowed_values

fb48b06

Copilot AI review requested due to automatic review settings March 16, 2026 16:04

Copilot started reviewing on behalf of Gobot1234 March 16, 2026 16:04 View session

Copilot AI reviewed Mar 16, 2026

View reviewed changes

Merge branch 'main' into jhilton/create-and-find

a81582c

Gobot1234 commented May 5, 2026

View reviewed changes

Comment thread src/ansys/fluent/core/solver/settings_builtin_data.py Outdated

Gobot1234 commented May 5, 2026

View reviewed changes

Comment thread src/ansys/fluent/core/solver/settings_builtin_data.py Outdated

Comment thread src/ansys/fluent/core/solver/settings_builtin_data.py Outdated

Apply suggestions from code review

dae1864

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Co-authored-by: James Hilton-Balfe <gobot1234yt@gmail.com>

Copilot AI review requested due to automatic review settings May 5, 2026 13:34

Copilot started reviewing on behalf of Gobot1234 May 5, 2026 13:35 View session

Copilot AI reviewed May 5, 2026

View reviewed changes

seanpearsonuk reviewed May 6, 2026

View reviewed changes

	"""Get and return the singleton instance of this object in Fluent.
	"""Get and return an instance of this object in Fluent.

		# Generate for all available versions
		versions = sorted([v.number for v in all_versions()])

		@@ -0,0 +1 @@
		Add get and create methods and **kwarg support for create

		return "create" in getattr(cls, "_child_classes", {}) or "create" in getattr(
		cls, "command_names", []

Conversation

Gobot1234 commented Jan 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Context

Scope

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

seanpearsonuk commented Jan 28, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Jan 28, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI Jan 28, 2026

Choose a reason for hiding this comment

Uh oh!

seanpearsonuk commented Jan 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Gobot1234 commented Jan 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

seanpearsonuk commented Jan 29, 2026

Uh oh!

seanpearsonuk commented Jan 29, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Uh oh!

Copilot AI Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

Gobot1234 commented Feb 4, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Gobot1234 commented Jan 27, 2026 •

edited

Loading

seanpearsonuk commented Jan 29, 2026 •

edited

Loading

Gobot1234 commented Jan 29, 2026 •

edited

Loading

codacy-production Bot commented Apr 24, 2026 •

edited

Loading