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 24.26471% with 103 lines in your changes missing coverage. Please review.
✅ Project coverage is 79.40%. Comparing base (bd10653) to head (3306c3c).

Files with missing lines	Patch %	Lines
src/easyscience/base_classes/easy_list.py	23.70%	103 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop     #193      +/-   ##
===========================================
- Coverage    81.15%   79.40%   -1.76%     
===========================================
  Files           52       53       +1     
  Lines         4267     4403     +136     
  Branches       740      780      +40     
===========================================
+ Hits          3463     3496      +33     
- Misses         624      727     +103     
  Partials       180      180              

Flag	Coverage Δ
unittests	79.40% <24.26%> (-1.76%)	⬇️

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	23.70% <23.70%> (ø)

[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.

[rozyczko]

I think this will throw TypeError in min(stop...) if stop is left as ... (ellipsis can't be compared to int)

You might need to change it to stop: int | None = None instead

[damskii9992]

Yeah, I was a little fast here with the Copilot auto-complete. I'm surprised it suggested the Ellipsis as the default though. I guess it must be used extensively in Numpy and Scipy which is where Copilot got it from :/

[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.