new collection based on easy_list

[rozyczko]

CollectionBase derived from EasyList

• Derives from EasyList rather than re-implementing MutableSequence from scratch.
• Removes all functionality now owned by EasyList (sequence operations, type protection, deduplication, serialization).
• Assumes legacy collection-specific concerns such as graph edges, interface propagation,
  and NotarizedDict have already been removed before this class is introduced.

Inheritance Hierarchy

NewBase
  └── EasyList[T]                   ← full MutableSequence, serialization, type protection
        └── CollectionBase[T]       ← adds aggregation methods only

content:

1. Parameter / Variable Aggregation

get_all_variables(self)
get_all_parameters(self)
get_parameters(self)
get_fittable_parameters(self)
get_free_parameters(self)
get_fit_parameters(self)

These mirror the methods on ModelBase, but aggregate across the list of items rather than
across the attribute names of a single object.

2. data Property

3. Legacy Serialization (_convert_to_dict)
   Support for the legacy encoder-based serialization path.
   Serializes all items in _data under the 'data' key, consistent with the old CollectionBase._convert_to_dict signature.

[github-actions]

This pull request does not contain a valid label. Please add one of the following labels: ['[scope] bug', '[scope] enhancement', '[scope] documentation', '[scope] significant', '[scope] maintenance']

[rozyczko]

Question:

• do we need named_items argument and handling?
  This would potentially allow callers to pass EasyScience objects as keyword arguments, which looks more natural.
  E.g.

cell = CollectionBase(name='Cell', length_a=length_a, length_b=length_b, length_c=length_c)

as opposed to when we need positional args

cell = CollectionBase(length_a, length_b, length_c, name='Cell')

The keyword names are discarded, and only the values are kept as items.
Currently, the key names are checked against _RESERVED_NAMED_KEYS to prevent collisions with actual constructor parameters like name or data, and None values are silently dropped.

[damskii9992]

Question:

• do we need named_items argument and handling?
  This would potentially allow callers to pass EasyScience objects as keyword arguments, which looks more natural.
  E.g.

cell = CollectionBase(name='Cell', length_a=length_a, length_b=length_b, length_c=length_c)

as opposed to when we need positional args

cell = CollectionBase(length_a, length_b, length_c, name='Cell')

The keyword names are discarded, and only the values are kept as items. Currently, the key names are checked against _RESERVED_NAMED_KEYS to prevent collisions with actual constructor parameters like name or data, and None values are silently dropped.

I don't really see the value of allowing keyword arguments? This is a list-class, i.e. it is more natural to add elements in a list-like fashion, i.e:

best_list = [model_1, model_2, model_3]
model_collection = ModelCollection(model_1, model_2, model_3)

The keyword arguments of the previous implementation was necessary to inject objects as attributes to the class, the keys were used for the attribute names, hence the reason to check for clashes. Since we don't want to allow parameter injection, we don't need this feature.

[AndrewSazonov]

My reply will overlap with Christian’s one, but I will still add it, since I already finished writing it before I saw his comment.

When I see this example

cell = CollectionBase(name='Cell', length_a=length_a, length_b=length_b, length_c=length_c)

I am a bit confused.

In my understanding, a cell object should not be a collection, because it contains different types of parameters (name, lengths, angles). I thought that CollectionBase is mainly for cases where we have a collection of the same type of objects, for example atom sites.

In that case, we would have something like:

atom_site = AtomSite(label='Si', type_symbol='Si', fract_x=0.5, fract_y=0, fract_z=1, b_iso=1, occupancy=1)

Here keyword arguments are very important, because the positional version

atom_site = AtomSite('Si', 'Si', 0.5, 0, 1, 1, 1)

is not very clear.

Then we create a collection:

atom_sites = CollectionBase()

and append items:

atom_sites.append(atom_site1)
atom_sites.append(atom_site2)

or maybe add them in bulk (e.g. list / numpy array).

If we create a collection like:

atom_sites = CollectionBase(atom_site1, atom_site2, ...)

then using keyword names for items does not make sense. So, I think the named_items argument is not needed.

[rozyczko]

There's still a legacy layer on top of the class, so the current Parameters/Descriptors can be added as members.

[damskii9992]

251 files changed and 40 000 lines of code???? 😨

[rozyczko]

Meh, merging the new core completely screwed up the branch. Need to redo the changes based on the current develop

[rozyczko]

closing for the updated version in #228