Closed oalmelid closed 2 years ago
Yikes that's annoying. At a glance I think you're probably right. In macro cases we can only really split based on 'lower followed by upper' or a delimiter. I don't think it makes sense to do an 'upper followed by upper' boundary.
Looking at this further its in direct contradiction to the case in #1. In #1 the word being macro cased, FooXBar
, is somewhat convoluted but ultimately describes 3 distinct tokens Foo
, X
and Bar
.
In your case its an acronym, IP
and I don't think its really possible to identify that. The only thing I can think of is adding an option to specify using delimiters only in which case IP
would remain intact.
macrocase("IP Address", delims_only=True) # IP_ADDRESS
@oalmelid how does that sound?
That sounds good to me, thanks!
FWIW I also think it makes a lot of sense, since in a lot of casings (camel, pascal, etc.) capital letters are just another delimiter. Having an option to treat them as such brings them in line with the other delims and allows the user to provide further information about the input.
This should be addressed in v1.1.0.
Hi, and thanks for this lovely little utility library!
The fix for #1 appears to have some unintended consequences for string inputs that aren't camel or pascal-cased, i.e.
"IP Address"
becomesI_P_Address
. I'm wondering if it would make sense to only infer boundaries based on capital letters if e.g. the input does not contain spaces? I do understand that this is an edge-case, however.