Skip to content

308 remove name - #313

Merged
rozyczko merged 22 commits into
release-3.0from
308-remove-name
Oct 8, 2026
Merged

rozyczko merged 22 commits into
release-3.0from
308-remove-name

Conversation

@rozyczko

@rozyczko rozyczko commented Sep 25, 2026 •

Copy link
Copy Markdown
Member

Refactoring of Descriptor and Parameter Naming

  • Refactored all usages of name to use display_name for Parameter instantiation

  • Updated code that accesses parameter/descriptor names to use display_name instead of name

Modernization of Descriptor Class Constructors

  • Changed constructors of DescriptorAnyType and DescriptorArray to remove the name positional argument, making all arguments after value keyword-only.

@rozyczko rozyczko added [scope] maintenance Code/tooling cleanup, no feature or bugfix (major.minor.PATCH) [priority] highest Urgent. Needs attention ASAP [area] parameters and descriptors Anything related to Parameters or Descriptors [area] base classes Changes to or creation of new base classes labels Sep 25, 2026
@codecov

codecov Bot commented Sep 25, 2026 •

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 99.09910% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 94.11%. Comparing base (22513ad) to head (55de2db).
⚠️ Report is 1 commits behind head on release-3.0.

Files with missing lines Patch % Lines
src/easyscience/variable/descriptor_number.py 93.33% 1 Missing ⚠️
Additional details and impacted files

Impacted file tree graph

@@               Coverage Diff                @@
##           release-3.0     #313       +/-   ##
================================================
+ Coverage        83.82%   94.11%   +10.29%     
================================================
  Files               69       51       -18     
  Lines             5272     4127     -1145     
================================================
- Hits              4419     3884      -535     
+ Misses             853      243      -610     
Flag Coverage Δ
unittests 94.11% <99.09%> (+10.29%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines Coverage Δ
src/easyscience/__init__.py 100.00% <100.00%> (ø)
src/easyscience/base_classes/__init__.py 100.00% <100.00%> (ø)
src/easyscience/base_classes/easy_list.py 96.89% <100.00%> (+0.64%) ⬆️
src/easyscience/base_classes/model_base.py 100.00% <100.00%> (ø)
src/easyscience/base_classes/new_base.py 100.00% <100.00%> (ø)
src/easyscience/base_classes/serializer_base.py 98.15% <100.00%> (ø)
...syscience/fitting/calculators/interface_factory.py 97.32% <100.00%> (+0.04%) ⬆️
...c/easyscience/fitting/minimizers/minimizer_base.py 97.95% <ø> (ø)
.../easyscience/fitting/minimizers/minimizer_bumps.py 99.35% <ø> (ø)
...rc/easyscience/fitting/minimizers/minimizer_dfo.py 97.74% <ø> (ø)
... and 17 more

... and 2 files with indirect coverage changes

@rozyczko
rozyczko marked this pull request as ready for review September 25, 2026 13:25

@damskii9992 damskii9992 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

So many lines changed but not actually that much relevant. Just a lot of name being replaced with display_name. In principle we could also just not have the name or display_name in tests or tutorials, but I'm also okay with this replacement.

I AM confused about the arg_spec change though . . .

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Why is this removed and why was this ever moved to legacy?
A document explaining how serialization works for dependent parameters should still be good to keep somewhere . . .
Even IF it needs to get updated, now that the name attribute is gone.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Also, it should probably be moved to the documentation :)

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

We don't want stray MD files. I thought the docs already had this info but apparently they don't. Will udpate the content of /doc

class_links = self.__interface_obj.create(model)
props = model._get_linkable_attributes()
props_names = [prop.name for prop in props]
props_names = [prop.display_name for prop in props]

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This should probably be the unique_name rather than the display_name. Even though the display_name defaults to the unique_name if it hasn't been explicitly set.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

name_conversion keys are short calculator-side names like "scale".
The old name was such a non-unique label, and display_name is its replacement.
unique_name has to be unique across the whole program, so two models couldn't both have a "scale".
The real fix would be to match on the attribute's key in the model, but we're redoing the interface anyway.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

We should probably nix this class as well. It only existed to satisfy EasyCrystallography, which has since been deprecated.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Sure. I'll make this a separate PR to not conflate this.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

self,
name: str,
value: Union[list, np.ndarray],
*,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Why the wildcard arg? We're not processing this, so having it just makes the API more confusing.

@rozyczko rozyczko Oct 4, 2026 •

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

* isn't a wildcard. It makes all the remaining arguments keyword-only. It's deliberate - with name gone, an old call like Parameter('a', 1.0) now properly fails instead of setting 'a' as the value.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Ahh, my bad. I'm not a fan of it though. Forcing keyword-only arguments is annoyingly restrictive. And doing Parameter("a", 1.0) should fail anyways since we check the type of inputs and value cannot be a str.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Hmm, I think I might be in favour of the forcing keyword only arguments anyways, but I would put it after unit, so that you can still create a Parameter or DescriptorNumber fast and easily as:

a = Parameter(2.0, 'cm')

Comment on lines +96 to +102
sign = signature(self.__class__.__init__)
return {
param.name
for param in sign.parameters.values()
if param.kind in (param.POSITIONAL_OR_KEYWORD, param.KEYWORD_ONLY)
and param.name != 'self'
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Why is this neccesary?
Is the regular arg_spec from the NewBase not good enough? Does it not get all the fields?
If so, we should fix it in NewBase . . . .

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

as explained below.

@rozyczko

rozyczko commented Oct 4, 2026

Copy link
Copy Markdown
Member Author

I AM confused about the arg_spec change though . . .

This is needed because NewBase._arg_spec only collects POSITIONAL_OR_KEYWORD, so keyword-only arguments disappear from to_dict.
Making everything after value keyword-only therefore makes those arguments invisible to it.

NewBase._arg_spec      -> ['value']
DescriptorBase._arg_spec -> ['callback','description','display_name','fixed','max','min',
                             'unique_name','unit','url','value','variance']

Without the override, to_dict() would drop unit, variance, min, max, etc. The override adds KEYWORD_ONLY to the filter, so it is necessary.

I guess placing it in NewBase makes even more sense.
EasyList._arg_spec returns a set() now. I just tested it and it seems EasyList(..., display_name='My list').to_dict() loses the display name in the current impl but obviously retains it when in NewBase.

@rozyczko
rozyczko requested a review from damskii9992 October 4, 2026 08:05
@damskii9992

Copy link
Copy Markdown
Contributor

I AM confused about the arg_spec change though . . .

This is needed because NewBase._arg_spec only collects POSITIONAL_OR_KEYWORD, so keyword-only arguments disappear from to_dict. Making everything after value keyword-only therefore makes those arguments invisible to it.

NewBase._arg_spec      -> ['value']
DescriptorBase._arg_spec -> ['callback','description','display_name','fixed','max','min',
                             'unique_name','unit','url','value','variance']

Without the override, to_dict() would drop unit, variance, min, max, etc. The override adds KEYWORD_ONLY to the filter, so it is necessary.

I guess placing it in NewBase makes even more sense. EasyList._arg_spec returns a set() now. I just tested it and it seems EasyList(..., display_name='My list').to_dict() loses the display name in the current impl but obviously retains it when in NewBase.

Actually, we should just simply update the get_arg_spec method in the SerializerBase class to use signature to also get KEYWORD_ONLY arguments. That would probably be the best approach.

@rozyczko

rozyczko commented Oct 5, 2026

Copy link
Copy Markdown
Member Author

I AM confused about the arg_spec change though . . .

This is needed because NewBase._arg_spec only collects POSITIONAL_OR_KEYWORD, so keyword-only arguments disappear from to_dict. Making everything after value keyword-only therefore makes those arguments invisible to it.

NewBase._arg_spec      -> ['value']
DescriptorBase._arg_spec -> ['callback','description','display_name','fixed','max','min',
                             'unique_name','unit','url','value','variance']

Without the override, to_dict() would drop unit, variance, min, max, etc. The override adds KEYWORD_ONLY to the filter, so it is necessary.
I guess placing it in NewBase makes even more sense. EasyList._arg_spec returns a set() now. I just tested it and it seems EasyList(..., display_name='My list').to_dict() loses the display name in the current impl but obviously retains it when in NewBase.

Actually, we should just simply update the get_arg_spec method in the SerializerBase class to use signature to also get KEYWORD_ONLY arguments. That would probably be the best approach.

Hmmm I guess this is slightly better than the existing impl. Fixing the generic path and deleting the NewBase override is cleaner.

@rozyczko rozyczko mentioned this pull request Oct 8, 2026
@rozyczko
rozyczko merged commit e620f0a into release-3.0 Oct 8, 2026
26 of 28 checks passed
@rozyczko
rozyczko deleted the 308-remove-name branch October 8, 2026 16:38
@rozyczko rozyczko mentioned this pull request Oct 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

[area] base classes Changes to or creation of new base classes [area] parameters and descriptors Anything related to Parameters or Descriptors [priority] highest Urgent. Needs attention ASAP [scope] maintenance Code/tooling cleanup, no feature or bugfix (major.minor.PATCH)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants