On Wed, Jan 30, 2019 at 11:06 AM Chris Angelico <ros...@gmail.com> wrote:
>
> Most places where you need to talk to humans, you'll end up either
> interpolating the values into a template of some sort (see: percent
> formatting, the format method, and f-strings), or plug individual
> values straight into method calls (eg when building a GUI). I'm not
> sure why or how your use-case is somehow different here.
The new python format syntax with f-strings is pretty awesome, let's
see how we can assemble a triple quoted f-string:
foo = f'''
some
{more(complex)}
{st.ri("ng")}
'''.strip()
Pretty cool right ? In a function it would look like this:
def foo():
return f'''
some
{more(complex)}
{st.ri("ng")}
''').strip()
Ok so that would also work but we're going to have to import a module
from the standard library to restore visual indentation on that code:
import textwrap
def foo():
return textwrap.dedent(f'''
some
{more(complex)}
{st.ri("ng")}
''').strip()
Let's compare this to the join notation:
def foo():
return '\n'.join('some', more(complex), st.ri('ng'))
Needless to say, I prefer the join notation for this use case. Not
only does it fit in a single line but it doesn't require to dedent the
text with an imported function, nor does it require to juggle with
quotes, but also it sorts of look like it would be more performant.
All in all, I prefer the join notation to assemble longer strings.
Note that in practice, using f-strings for the "pieces" that I want to
assemble and that works great:
def foo():
return '\n'.join('some', more(complex), f'_{other}_')
Anyway, ok good-enough looking code ! Let's see what you have to say:
TypeError: join() takes exactly one argument (2 given)
Oh, that again, kk gotfix:
def foo():
return '\n'.join(['some', more(complex), f'_{other}_'])
I should take metrics about the number of times were I make this
mistake during a day, cause it looks like it would be a lot (i switch
between os.path.join to str.join a lot).
It seems there is a lot of friction when proposing to add a
convenience join method to the list method. I won't go over the
reasons for this here, there's already a lot to read about it on
internet, that's been written during the last 20 years.
## Conclusion
I have absolutely no idea what should be done about this, the purpose
of this article was just to share a bit of one of my obsessions with
string assembling.
Maybe it strikes me assembling strings multiple times a day with a
language I've got 10 years of full-time experience and still repeating
the same mistakes because I coded an os.path.join call 3 seconds
before assembling a string with str.join, silly me ^^
Not because I don't understand the jurisprudence, not because I don't
understand the documentation, or because the documentation is wrong,
but probably just because i switch from os.path.join and str.join
which take different syntax, i think.
> It's generally best to provide simple low-level functionality, and
> then let people build it into whatever they like. For example, VLC
> Media Player and Counter-Strike: Global Offensive don't have any means
> of interacting, but with some simple Python programming in between,
> it's possible to arrange it so that the music automatically pauses
> while you're in a match. But there does NOT need to be a game feature
> "automatically pause VLC while in a match". Joining a collection of
> strings is possible. Stringifying a collection of arbitrary objects is
> possible. There doesn't need to be a single feature that does both at
> once.
Even for a program without user interface: you still want proper logs
in case your software crashes for example . So even if you're not
building a user interface, you still want to assemble human readable
strings. If it's such a common task, why not automate what's obvious
to automate ?
--
∞
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
