5 ms·

I think the feature bloat here has passed the break-even point where no one person needs all this, and it takes so long to find what you need in the docs, and y

by cvoss 1y ago

I think the feature bloat here has passed the break-even point where no one person needs all this, and it takes so long to find what you need in the docs, and you can't be expected to memorize it, because it's so rare to need to use it, and you can't reliably reverse-search the esoteric syntax you encounter, that any given dev is going to take the path of least resistance and write their own routines for this stuff. Pad left? That's a two-line method at most. Versus trying to remember whether the syntax is x:n< or x:<n or what. It's faster to do it yourself ad-hoc. And if the next dev has a question about how it works, the implementation is right there (and easy to customize!) not buried in the docs and immutable.

al_borland 1y ago
I find that weird stuff is often used a lot in a single code base, or it’s not used at all. Solve it once, and copy/paste it every other time you need it in the future.
dvdkon 1y ago
I'd take the middle road, provide a pad_left/pad_right function or method with keyword arguments for specifying things like the padding character. With how often I need to pad some string (often but not every day), this would be my favourite solution. The standard library having no solution of its own is how you end up with JavaScript and every project reimplementing their 10% of a proper standard library, only slower and with more bugs. Though I won't probably use Python's </>/^ format modifiers in my project, I could maybe see them working out in some software that frequently outputs "monospaced" text. In a particular niche, what we think of a needless character-pinching might be seen as a crucial feature and used daily.
zahlman 1y ago
> Pad left? That's a two-line method at most. The functionality comes from the prior string.format method, which has been around since Python 2.6 (first released in 2008). https://docs.python.org/2.6/library/string.html#formatspec https://docs.python.org/2.6/library/string.html#formatspec > It's faster to do it yourself ad-hoc. I have found the syntax to be quite mentally "sticky". > the implementation is right there (and easy to customize!) not buried in the docs and immutable. There are hooks to customize it.

by cvoss 1y ago

al_borland 1y ago

I find that weird stuff is often used a lot in a single code base, or it’s not used at all. Solve it once, and copy/paste it every other time you need it in the future.

dvdkon 1y ago

I'd take the middle road, provide a pad_left/pad_right function or method with keyword arguments for specifying things like the padding character. With how often I need to pad some string (often but not every day), this would be my favourite solution. The standard library having no solution of its own is how you end up with JavaScript and every project reimplementing their 10% of a proper standard library, only slower and with more bugs. Though I won't probably use Python's </>/^ format modifiers in my project, I could maybe see them working out in some software that frequently outputs "monospaced" text. In a particular niche, what we think of a needless character-pinching might be seen as a crucial feature and used daily.

zahlman 1y ago

> Pad left? That's a two-line method at most. The functionality comes from the prior string.format method, which has been around since Python 2.6 (first released in 2008). https://docs.python.org/2.6/library/string.html#formatspec https://docs.python.org/2.6/library/string.html#formatspec > It's faster to do it yourself ad-hoc. I have found the syntax to be quite mentally "sticky". > the implementation is right there (and easy to customize!) not buried in the docs and immutable. There are hooks to customize it.