Filename collisions in similar names rendered identical by sanitation.

[toonarmycaptain]

[Unproven as yet.]

Suspect that substantially similar names, such as 'Elána' and 'Eléna' will both be sanitised to 'El_na' - causing overwriting of associated avatar files.

Solve in convert_to_OOP:
Suggest fix to test for _path_safe_name in Class.students, and append hash of class or student if it is. Assignment exp would be good here:if (path-safe_name := make_path_safe_name(name)) in (student._path_safe_name for student in students)

_path_safe_name can be stored as an attribute along with name, rather than reinstantiated

Checking for name and _path_safe_name is probably necessary here, as names also need to be unique, and adding 'Elána' after 'Eléna' is still valid, even if making the _path_safe_name of 'Elána' 'El_na_93727266738', but adding a second for 'Eléna'' or.'Elána' is not.

Rechecking/recalculating the _path_safe_name, or reinstantiating the Student object when moving to another class would virtually eliminate the possibility of a hash collision on a hash appended name, more so if the class is used in producing that hash.

Calculation for this (both of the name itself and the collision check) can go on in the setter for _path_safe_name rather than in the initial if name in Class.students as identical names is all we care about disallowing the user, app will handle implementation details. This will also take care of changing _path_safe_name and avatar_path at the same time, if these are linked to the name setter. The avatar_path setter will take care of any file renames.

Avatar_path setter will need to examine an existing _avatar_path and rename the file if it is in the app_data already (otherwise copy to app_data).

[toonarmycaptain]

This will be negated by the usage of a global id attribute for each student, easily enabled by converting the backend from pure json text files to a SQL database.