>> Do you think it negatively affects performance?
Yes and no. Pragmatically, no, because in python usually performance comes from (ignoring using native code) avoiding dynamic dispatches (circa 500x speedups are common) and like in almost all languages, being aware of your allocations (varies wildly but avoiding allocs in loops for example will give remarkable speedups).
In theory though, yes absolutely this is slower - what was a query of a dict (or even better, an array in the __slots__ case) - i.e. grabbing an attribute from a class - is now going outside the process and asking the OS about stuff on the filesystem. Masssively slower.
>> Why don't you think it's a good idea?
Because you’re paying an overhead to use something in an unexpected way when the language provides a faster, idiomatic solution to this problem:
>> a pattern to encapsulate data and functions
That’s the class and object system described in one sentence
>> I don't see how __slots__ would be relevant to this?
You’ve heard of turtles all the way down? In python it’s dicts all the way down. Behind the scenes you can think of a loaded module being a dict, just the same as an object has a dict underpinning it.
Slots comes in as an optimisation on this dicts all the way down. An optimisation that’s not open to you if you (ab?)use modules like this.
But i’d finish up by saying this - i’m a random person on the internet that doesn’t know your use case. I stand by the above as decent general case advice but you might actually have a valid case to deviate AND you’re not going to unlock new discoveries in better ways to do things if you just always follow the dogma so don’t be put off by my negativity toward the idea but DO measure the outcomes you care about when experimenting to see if the modules idea is working for you.
If I understand you correctly, only the creation of greet1 and greet2 are slower, but then the usage of these objects is just as fast as using instances of classes?
I think this isn't a good idea though, i'd lookup __slots__ if leanness is an issue.