Add initial EasyList class

[damskii9992]

Here is my initial thoughts on how the generic EasyList could look like. I haven't added tests yet, but please have a look.

[codecov]

Codecov Report

❌ Patch coverage is 92.10526% with 12 lines in your changes missing coverage. Please review.
✅ Project coverage is 81.68%. Comparing base (c737d47) to head (eb1cd25).

Files with missing lines	Patch %	Lines
src/easyscience/base_classes/easy_list.py	92.00%	6 Missing and 6 partials ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop     #193      +/-   ##
===========================================
+ Coverage    81.27%   81.68%   +0.40%     
===========================================
  Files           52       53       +1     
  Lines         4309     4460     +151     
  Branches       748      792      +44     
===========================================
+ Hits          3502     3643     +141     
- Misses         627      631       +4     
- Partials       180      186       +6     

Flag	Coverage Δ
unittests	81.68% <92.10%> (+0.40%)	⬆️

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

Files with missing lines	Coverage Δ
src/easyscience/base_classes/__init__.py	100.00% <100.00%> (ø)
src/easyscience/base_classes/easy_list.py	92.00% <92.00%> (ø)

... and 1 file with indirect coverage changes

[rozyczko]

• I understand that the lack of graph integration is a feature? We let the list components do the edge/vertex tracking?

• Good type safety but not sure we should allow duplicates. My ModelCollection just skips duplicates which might be even worse.

• Where is the data property? Do we need it?

• Where is the aggregate get_all_variables? Just run over all children and return that aggregate.

[henrikjacobsenfys]

I can find no problems with the code, but it's also using some methods that are new to me, so I'm not an expert.

As discussed elsewhere, I'll want this exact class, but using something like name instead of unique_name.

From what I understand, we could make that somewhat straightforward by introducing something like

def _get_key(self, item: ProtectedType_) -> str:
    return item.unique_name

and replace calls to item.unique_name with self._get_key(item).
That way I can inherit from this class and override _get_key (and write my own validation to ensure the name is unique within the specific list).

This seems to me to be cleaner than maintaining a copy of EasyList in EasyDynamics.

I approve the name BTW.

[damskii9992]

For documentation:

• I understand that the lack of graph integration is a feature? We let the list components do the edge/vertex tracking?

Yes, this is another step towards simplifying our global_object and removing our use of the graph to eventually remove it completely. The end-goal is for the global_object to only have a weakref dictionary of key-value pairs of unique_names. I.e. get rid of all the other complicated and unused functionality.
If you have a good use-case for keeping the graph functionality, please write it down so we can asses our actual needs and what we can do about it.

• Good type safety but not sure we should allow duplicates. My ModelCollection just skips duplicates which might be even worse.

Do you mean duplicates of the same object in the list? I guess we can safeguard against that by adding a check in the setitem and append methods. But that will slow down setting and appending, but I guess we will never use EasyList for huge lists, so maybe the slow down is okay? Is there any use-case where we might want duplicates of an item in a list?

• Where is the data property? Do we need it?

The 'data' property is an internal only property. It is also used for serialization. I did consider making it public, but then it would be weird that you have 2 ways of setting the lists data, i.e.:

EasyList(1,2,3)

EasyList(data=[1,2,3])

EasyList(1,2,3, data=[4,5,6])

And what would we do in the last case when both are provided? I felt it was simpler/cleaner to simply make data an internal and serialization only attribute.

• Where is the aggregate get_all_variables? Just run over all children and return that aggregate.
  That would be for a child-class, lets call it ModelCollection which inherits from this and where the protected_types has to inherit from ModelBase rather than NewBase like in this one. Since all elements would be instances of ModelBase, we would then know that they all have their own get_all_variables methods.

[seventil]

LGTM, upvote for the (optional) uniqueness checks.

but using something like name instead of unique_name.
we really should write down all the functional requirements for names

[rozyczko]

remember to fix ruff format...

[rozyczko]

Some serious issues found. Please consider addressing them.

[rozyczko]

Looks good now.