I am really impressed by how thoroughly this library thinks through all the applications and edge cases of text casing.
On a recent project I spent about an hour trying to do something similar (and far less sophisticated) before I realized it was a problem I had no desire in really solving, so I backed out all my changes and just went with string.capitalize(), even though it didn’t really do what I was looking for. Looking forward to using this instead!
zobweyt · 28d ago
Thank you for the kind words! I'm glad you appreciate the effort put into covering all those edge cases.
It sounds like you had quite the adventure with text casing on your project. I'm happy this library can save you some time and hassle. Looking forward to see what can be built with it!
Rendello · 28d ago
Many edge-cases can be found with regards to casing! Like title-case characters.
I might be jaded, but I think having libraries for such simple use cases leads to the inevitable `left-pad` situation.
When I say simple use cases I mean that since you probably don't need all of these functions at once that it would be easier to copy the code you need if you don't feel comfortable writing it instead of adding yetanotherlibrary to your dependency tree.
zobweyt · 28d ago
I understand your perspective, and it's a valid concern. However, this library is designed to support not only simple use cases but also more advanced scenarios, providing a comprehensive solution for various needs. Additionally, it has zero dependencies, which helps keep your project lightweight. This way, you can benefit from the library's features without adding unnecessary complexity to your dependency tree. Thank you for sharing your thoughts!
lnenad · 28d ago
Nah it's not you or your library, there is definitely a place for such utilities. The issue is broader, related to everyone installing libs for two liners and having bajillion dependencies.
axegon_ · 28d ago
Don't forget space... npm install and 500GBs go "bye-bye"
lnenad · 28d ago
Hey I'll have you know that memory is cheap nowadays and that I'd be happy to fill out my drives with node libraries for converting a's into A's.
7bit · 28d ago
You can always just take the code and put it in your app. Having libraries like these don't force you to add them as a dependency. Assuming the right OSS license.
lnenad · 28d ago
I agree but in reality many will take the easier path of [`pip` `npm` `cargo` `yarn` `go`] [`install`, `add`] when seeing the functionality out there. I was also making a broader talking point.
fake-name · 28d ago
> A feature complete Python text case conversion library
Considering it supports unicode input, I somehow doubt that. Given that there's no mention of unicode normalization it'll likely break some strings.
zobweyt · 28d ago
That's a great observation! Instead of seeing it as a limitation, it can be treated as a feature. Users can handle Unicode normalization using Python's built-in unicodedata module to ensure proper case conversion. Thanks for pointing that out!
re · 28d ago
> A feature complete Python text case conversion library
I suspect you mean "featureful", "full-featured" or similar[1]—"feature complete" means that you're not going to add any more features.
Thank you for the clarification! I appreciate your input. I've updated the wording to "feature-rich" to better convey the intended meaning. Your feedback is valuable!
frizlab · 28d ago
Great library!
Does it support non-English title casing?
For instance in French, title casing for “les maisons bleues” is “Les Maisons bleues” while for “des maisons bleues” it’s “Des maisons bleues”.
zobweyt · 28d ago
Thanks!
It does not support non-English title casing. From the documentation:
> It also works non-ascii characters. However, no inferences on the language itself is made. For instance, the digraph ij in Dutch will not be capitalized, because it is represented as two distinct Unicode characters. However, æ would be capitalized
frizlab · 28d ago
I was talking about the specific rules that are in place for title capitalization. As you can see in my example the uppercase letters seem randomly placed for a title, but they are indeed correct. For German too there are issues where capitalization has a meaning on the word itself. That kind of things.
It looks like your library does not support it, which is understandable, it is a huge problem to tackle, but I just wanted to be sure.
zobweyt · 28d ago
Thank you for the clarification! I understand that title capitalization can be quite complex, especially with specific rules in languages like German where capitalization can change the meaning of a word.
I guess handling these nuances falls under the broader categories of internationalization (i18n) and localization (l10n).
frizlab · 27d ago
Just to be excessively clear and maybe borderline annoying, this is not a simple nuance. In German the meaning of a word can actually change depending on its capitalization. Even in English, lowercasing the I is very weird.
re · 28d ago
> It does not support non-English title casing
Perhaps document that clearly—it's an important restriction that the library assumes English-language strings. ("no inferences on the language itself is made" isn't quite true since the language is inferred to be English, or to at least follow English-compatible rules for casing)
zobweyt · 28d ago
Thanks for your feedback! You're right; I should clarify that the library assumes English-language strings for casing. I'll update the documentation to make this limitation clear. I appreciate you pointing it out!
zvr · 28d ago
Nice work, but since it does not handle anything else than strings, maybe it should be named "stringcase" or something.
zobweyt · 28d ago
Thank you for the feedback!
I appreciate your suggestion regarding the name, but unfortunately this name was already taken, so "textcase" was chosen.
I also have ideas for adding dictionary key conversion and other features in the future that will handle more than just strings. In addition, you can use this library to convert cases of Iterable[str] using textcase.pattern
zvr · 28d ago
My issue with using "text" is that I assume that a text like "I THINK I DO" should be converted to "I think I do", not "i think i do".
And that's just in English...
If "text" is in Greek, like "Καλημέρα", the upper form should be "ΚΑΛΗΜΕΡΑ", not a juxtaposition of upper() conversions of each letter.
zobweyt · 28d ago
Thanks for the clarification!
Yeah, there is such a problem with the naming "text" suggests something different than just a "string".
I guess handling these nuances falls under the broader categories of internationalization (i18n) and localization (l10n).
anentropic · 28d ago
Looks brilliant!
My only suggestion is here:
> It also ignores any leading, trailing, or duplicate delimiters:
In the case of a conversion target that has delimiters (snake, kebab) it might be nice to have an alternative option to preserve such features but normalise them to the target delimiter
Thank you for your suggestion! Adding a preserve option to maintain leading, trailing, and duplicate delimiters while normalizing them to the target delimiter is a great idea. I’ll consider implementing this feature. Thanks again!
kianN · 29d ago
My favorite part of this library is that it seems to have zero dependencies!
Python packages seem to often rope in a surprising number of dependencies for relatively limited libraries.
I can easily imagine pulling this package into my work: thank you for keeping the requirements to a minimum!
danpalmer · 28d ago
Definitely something to be championed, although I suspect this is a matter of perspective. I find Python packages to have refreshingly few dependencies compared to packages in the JS ecosystem, although compared to the Swift ecosystem which I’m somewhat familiar with, they do tend to have a few more.
zobweyt · 28d ago
I appreciate your perspective! It's interesting to consider how the built-in libraries of a language can influence its ecosystem. Python does have a rich standard library that often reduces the need for external dependencies. In contrast, JavaScript's ecosystem has evolved around web development, where modularity and flexibility are prioritized, leading to a proliferation of packages.
zobweyt · 29d ago
Thanks for the kind words!
This library actually has zero dependencies! I'm glad you appreciate the no-dependency design.
It's great to hear that it fits well with your work!
esafak · 29d ago
Is there a GH badge for the dependency count? Depfu maybe. Someone should make one if not; it's worth advertising.
zobweyt · 28d ago
Thanks for the suggestion!
Right now, there's no such GH badge. Since the project will always have zero dependencies, I think we can simply use a static badge like this:
On a recent project I spent about an hour trying to do something similar (and far less sophisticated) before I realized it was a problem I had no desire in really solving, so I backed out all my changes and just went with string.capitalize(), even though it didn’t really do what I was looking for. Looking forward to using this instead!
It sounds like you had quite the adventure with text casing on your project. I'm happy this library can save you some time and hassle. Looking forward to see what can be built with it!
https://www.unicode.org/versions/Unicode16.0.0/core-spec/cha...
When I say simple use cases I mean that since you probably don't need all of these functions at once that it would be easier to copy the code you need if you don't feel comfortable writing it instead of adding yetanotherlibrary to your dependency tree.
Considering it supports unicode input, I somehow doubt that. Given that there's no mention of unicode normalization it'll likely break some strings.
I suspect you mean "featureful", "full-featured" or similar[1]—"feature complete" means that you're not going to add any more features.
[1] https://english.stackexchange.com/questions/393517/what-do-y...
Does it support non-English title casing?
For instance in French, title casing for “les maisons bleues” is “Les Maisons bleues” while for “des maisons bleues” it’s “Des maisons bleues”.
It does not support non-English title casing. From the documentation:
> It also works non-ascii characters. However, no inferences on the language itself is made. For instance, the digraph ij in Dutch will not be capitalized, because it is represented as two distinct Unicode characters. However, æ would be capitalized
It looks like your library does not support it, which is understandable, it is a huge problem to tackle, but I just wanted to be sure.
I guess handling these nuances falls under the broader categories of internationalization (i18n) and localization (l10n).
Perhaps document that clearly—it's an important restriction that the library assumes English-language strings. ("no inferences on the language itself is made" isn't quite true since the language is inferred to be English, or to at least follow English-compatible rules for casing)
I appreciate your suggestion regarding the name, but unfortunately this name was already taken, so "textcase" was chosen.
I also have ideas for adding dictionary key conversion and other features in the future that will handle more than just strings. In addition, you can use this library to convert cases of Iterable[str] using textcase.pattern
And that's just in English...
If "text" is in Greek, like "Καλημέρα", the upper form should be "ΚΑΛΗΜΕΡΑ", not a juxtaposition of upper() conversions of each letter.
Yeah, there is such a problem with the naming "text" suggests something different than just a "string".
I guess handling these nuances falls under the broader categories of internationalization (i18n) and localization (l10n).
My only suggestion is here:
> It also ignores any leading, trailing, or duplicate delimiters:
In the case of a conversion target that has delimiters (snake, kebab) it might be nice to have an alternative option to preserve such features but normalise them to the target delimiteri.e.
Python packages seem to often rope in a surprising number of dependencies for relatively limited libraries.
I can easily imagine pulling this package into my work: thank you for keeping the requirements to a minimum!
This library actually has zero dependencies! I'm glad you appreciate the no-dependency design.
It's great to hear that it fits well with your work!
Right now, there's no such GH badge. Since the project will always have zero dependencies, I think we can simply use a static badge like this:
https://img.shields.io/badge/dependencies-0-green
If only this comment supported case conversion..
In any case congrats on shipping!
Actually, this library supports conversion of even such strings!
```python
>>> import textcase
>>> textcase.convert("HAppY ApRiL FoOLs!", textcase.case.SNAKE, (textcase.boundary.SPACE,))
'happy_april_fools!'
```
Thanks for the congratulations!
It also looks to be nice in exploratory data analysis: