derek73
Dynamic changes
While some variables are exposed to the developer, some run time changes can not be effected.
Example: I can add regex patterns at run time, but I can't force their integration into the code. I have to change the project.
I would like to discuss this idea. My initial approach would be to mark the regex patterns for use in different parts of the code. Secondary ideas would be to construct a list of the regex patterns to be used and allow the developer to change this list dynamically. I think there will need to be a method that the developer can invoke to invoke part of the initialization after making a run time change.
Have you tried calling parse_full_name() after updating the regex patterns? It might not work, it's been a while since I worked on that but I think it does update the buckets again...
https://nameparser.readthedocs.io/en/latest/customize.html#config-changes-may-need-parse-refresh
If that solves the problem, it would be nice if the parser could call that method automatically when it needs to.
I'll check this. The function that parses the nickname first assigns specific compiled regex patterns to variables and then iterates those variables. I don't think that part of the code (for in [ ]) would be affected by the invocation of parse_full_name() but I'll check.
I was thinking about a way of tagging the compiled regex patterns for how they could/should be used and then iterating/building that list, rather than iterate a list of variables. The parse_full_name() function might be a good place to build/rebuild such list(s).
I'll go over the documentation, relative to dynamic changes.
My regex chops are weak, but I could see the value of being able to add regex patterns at runtime.
The function that parses the nickname first assigns specific compiled regex patterns to variables and then iterates those variables. I don't think that part of the code (for in [ ]) would be affected by the invocation of parse_full_name() but I'll check.
Yea, that might be true actually.
I was thinking about a way of tagging the compiled regex patterns for how they could/should be used
That sounds interesting. If you have a vision for how that could work, feel free to explore it.
The parse_full_name() function might be a good place to build/rebuild such list(s).
Perhaps. Could also maybe have a function like add_regex() or whatever to the TupleManager that handled updating whatever needed to be updated when you add a regex?
Or, I think TupleManager might only be used for regex patterns, so maybe we can just override the add method of that class? I guess, maybe needs to reinstantiate itself or something? or maybe it just needs to overwrite the shared module-level CONSTANTS instance. I forget right now how all that is wired together.
The way I did it the first time was to append the compiled regex pattern directly to your internal class variable. More formal property functions might be helpful to your class interface.
The reason I asked about this is that I had nicknames with more delimiters than your code supplied. After adding the patterns at run time, the parse didn't seem to use the patterns that I had added, so I opened up the code and made changes to the regex list and which regex patterns were used in the nickname function. This let me know that there were two changes needed.