10 ms·

F strings have been amazing in my everyday programming. I have been programming in Python for about 8 years now. I'd say some additions to this list are Cond

by k4ch0w 7y ago

F strings have been amazing in my everyday programming. I have been programming in Python for about 8 years now. I'd say some additions to this list are Conda for managing environments and Deep Learning builds such as Cuda on Ubuntu Jupyter notebooks for quick prototyping IPython if you have never seen it before. Requests Library

nerdbaggy 7y ago
Before I knew about F strings my .formats() were just so long. F strings are nice for sure
sametmax 7y ago
Despite being so cool, it's also a very under utilized feature, as it inherits all the formatting capabilities of format(). With format(), and hence with f-string you can: # Replace datetime.stftime() >>> f"{datetime.now():%m/%d/%y}" '05/15/19' # Show numbers in another base >>> f"{878:b}" '1101101110' >>> f"{878:x}" '36e' >>> f"{878:e}" '8.780000e+02' >>> f"{878:o}" '1556' # Control the display of padding, filling, and precision of numbers >>> 1 / 3 0.3333333333333333 >>> f"{1 / 3:.2f}" '0.33' >>> f"{69:4d}" ' 69' >>> f"{69:=+8d}" '+ 69' >>> f"{69:0=8d}" '00000069' # Center text >>> f"{'foo':^10}" ' foo ' And so many other things, since you can create your custom __format__. Not affiliated, but in this regard, I quite love https://pyformat.info/ https://pyformat.info/ as a format cheat sheet.
- DonaldPShimoda 7y ago
  > I quite love https://pyformat.info/ https://pyformat.info/ as a format cheat sheet. I never knew this existed but that's awesome! Thanks for the link!
- pbreit 7y ago
  To this novice, the "Old" way looks so much better.
  - sametmax 7y ago
    What old way ? %, zfill, strftime, or some hack with len() ? Having a unified syntax with all formatting needs is a big deal.
  - qquark 7y ago
    This is maybe not directly visible in the parent comment, and particularly not on the website, that is compatible with old versions of python also, but to me there's a huge difference in usability also in the ability to use variable names in the current scope without additional verbose crap by default. This seems secondary to a lot of people, but to me that changes everything: >>> x = 1 >>> f"{x}" '1' This is much more readable than: >>> "{x}".format(x=x) '1' >>> "{}".format(x) '1' It makes the code immensely more readable than having to count parameters, especially for long strings with a lot of data in them. Counting is for computers, not programmers; I shouldn't have to count anything for such a trivial task. So, thanks to f"", no need for what I find to be an ugly additional call to .format(...), that is just visual clutter for most cases. The only reasons I could see for a call with a dedicated dict is data exfiltration from a user provided format string executed on python code they do not control, or renaming/subsetting of keywords for cleanliness. Both are special cases, and that's the effect the current implementation has, thankfully.
    - collyw 7y ago
      I disagree, especially when using named parameters. The new style is too implicit.
      - hannasanarion 7y ago
        How is it implicit? Every insertion is expressed in exactly the place where it will print. It's way more explicit than having a placeholder and a value on completely different parts of the expression.
        collyw 7y ago
        > It's way more explicit than having a placeholder and a value on completely different parts of the expression. No its not.
pfranz 7y ago
I had a co-worker who like the convention: >>> 'User {user} has logged in and did an action {action}.'.format(**locals()) 'User Jane Doe has logged in and did an action buy.' I thought it was clever at first, but noticed it was frustrating to refactor because it was hard to see the scope of variables (especially if the template string is defined elsewhere). I don't lean heavily on IDEs, but at the time it would flag many required variables as unused because it couldn't grok this. Do you find the same problems when using f strings?
- DonaldPShimoda 7y ago
  >>> 'User {user} has logged in and did an action {action}.'.format(**locals()) D: To me, this is pretty gross. This implicitly requires all the correct variables to be bound in the local scope, and there's no easy way to check that this is the case without reading all of the code leading up to this point (which is bad, in my opinion). Because what this really does is create string-level variables `user` and `action` and pass the values of similarly-named (i.e., shadowed) variables in the outer (but still local) scope in their place. This is why IDEs struggle with this: they can't simply know the contents of the dictionary returned by the function `locals()` without actually executing the code (unless they special-case calls to functions named `locals`, but this causes problems if the user ever shadows this name). F-strings directly use the bound variables in the outer (but still local) scope: >>> f'User {user} has logged in and did an action {action}.' 'User Jane Done has logged in and did an action buy.' This avoids the shadowing problem, thus making it easy to use with IDEs and (IMO) easier to grok while reading directly, although maybe most people don't think about shadowing to the same extent I do and wouldn't be as bothered by this in general. Still, the IDE support is incredibly useful.
- baq 7y ago
  there are python implementations where locals() is unavailable or available at significant cost.
- kragen 7y ago
  > Do you find the same problems when using f strings? No, you can't define f strings elsewhere, and in theory your IDE can statically analyze them just as the Python interpreter does. In practice, your IDE might suck, I don't know.
ehsankia 7y ago
They just added a brand new feature in 3.8 that let's you just append = at the end for quick debugging: >>> f'{5+5=}' '5+5=10' >>> foo = 5 >>> f'{foo=}' 'foo=5' https://docs.python.org/dev/whatsnew/3.8.html#f-strings-now-support-for-quick-and-easy-debugging https://docs.python.org/dev/whatsnew/3.8.html#f-strings-now-...
- gizmo385 7y ago
  This just feels like another example of Python slowly creeping more esoteric syntax into the language, making it harder for beginners to approach the language.
  - jplayer01 7y ago
    Beginners don't have to know or touch any of this though. They can keep using normal strings until at some point they learn about f strings and see a need for them. You don't need to stop adding features to a language just because a beginner won't be able to learn everything. They don't need to.
    - simonh 7y ago
      I think the point is, a beginner coming across some code using such esoteric features is going to be a bit lost as to what's going on. With most of Python you can see what it's doing even if you didn't know the syntax before. That's true of basic f-strings, but not so much with some of this stuff.
      - makapuf 7y ago
        Yeah languages are meant to be read even by beginners. I think a language like python shines by being small (in design) yet powerful (by capability). Having myriads of "nice for one use case" feature in the language is not the way forward. I long for the time where % format and .format are removed from the language spec. Even if they still work on the implementation for compatibility. Please remove things.
AtHeartEngineer 7y ago
Conda with pipenv = great
- stOneskull 7y ago
  it's great if using debian where it's still on 3.5. installing miniconda lets you have the newest python easy-peasy

by k4ch0w 7y ago

nerdbaggy 7y ago

Before I knew about F strings my .formats() were just so long. F strings are nice for sure

sametmax 7y ago

Despite being so cool, it's also a very under utilized feature, as it inherits all the formatting capabilities of format(). With format(), and hence with f-string you can: # Replace datetime.stftime() >>> f"{datetime.now():%m/%d/%y}" '05/15/19' # Show numbers in another base >>> f"{878:b}" '1101101110' >>> f"{878:x}" '36e' >>> f"{878:e}" '8.780000e+02' >>> f"{878:o}" '1556' # Control the display of padding, filling, and precision of numbers >>> 1 / 3 0.3333333333333333 >>> f"{1 / 3:.2f}" '0.33' >>> f"{69:4d}" ' 69' >>> f"{69:=+8d}" '+ 69' >>> f"{69:0=8d}" '00000069' # Center text >>> f"{'foo':^10}" ' foo ' And so many other things, since you can create your custom __format__. Not affiliated, but in this regard, I quite love https://pyformat.info/ https://pyformat.info/ as a format cheat sheet.

DonaldPShimoda 7y ago
> I quite love https://pyformat.info/ https://pyformat.info/ as a format cheat sheet. I never knew this existed but that's awesome! Thanks for the link!
pbreit 7y ago
To this novice, the "Old" way looks so much better.
- sametmax 7y ago
  What old way ? %, zfill, strftime, or some hack with len() ? Having a unified syntax with all formatting needs is a big deal.
- qquark 7y ago
  This is maybe not directly visible in the parent comment, and particularly not on the website, that is compatible with old versions of python also, but to me there's a huge difference in usability also in the ability to use variable names in the current scope without additional verbose crap by default. This seems secondary to a lot of people, but to me that changes everything: >>> x = 1 >>> f"{x}" '1' This is much more readable than: >>> "{x}".format(x=x) '1' >>> "{}".format(x) '1' It makes the code immensely more readable than having to count parameters, especially for long strings with a lot of data in them. Counting is for computers, not programmers; I shouldn't have to count anything for such a trivial task. So, thanks to f"", no need for what I find to be an ugly additional call to .format(...), that is just visual clutter for most cases. The only reasons I could see for a call with a dedicated dict is data exfiltration from a user provided format string executed on python code they do not control, or renaming/subsetting of keywords for cleanliness. Both are special cases, and that's the effect the current implementation has, thankfully.
  - collyw 7y ago
    I disagree, especially when using named parameters. The new style is too implicit.
    - hannasanarion 7y ago
      How is it implicit? Every insertion is expressed in exactly the place where it will print. It's way more explicit than having a placeholder and a value on completely different parts of the expression.
      - collyw 7y ago
        > It's way more explicit than having a placeholder and a value on completely different parts of the expression. No its not.

pfranz 7y ago

I had a co-worker who like the convention: >>> 'User {user} has logged in and did an action {action}.'.format(**locals()) 'User Jane Doe has logged in and did an action buy.' I thought it was clever at first, but noticed it was frustrating to refactor because it was hard to see the scope of variables (especially if the template string is defined elsewhere). I don't lean heavily on IDEs, but at the time it would flag many required variables as unused because it couldn't grok this. Do you find the same problems when using f strings?

DonaldPShimoda 7y ago
>>> 'User {user} has logged in and did an action {action}.'.format(**locals()) D: To me, this is pretty gross. This implicitly requires all the correct variables to be bound in the local scope, and there's no easy way to check that this is the case without reading all of the code leading up to this point (which is bad, in my opinion). Because what this really does is create string-level variables `user` and `action` and pass the values of similarly-named (i.e., shadowed) variables in the outer (but still local) scope in their place. This is why IDEs struggle with this: they can't simply know the contents of the dictionary returned by the function `locals()` without actually executing the code (unless they special-case calls to functions named `locals`, but this causes problems if the user ever shadows this name). F-strings directly use the bound variables in the outer (but still local) scope: >>> f'User {user} has logged in and did an action {action}.' 'User Jane Done has logged in and did an action buy.' This avoids the shadowing problem, thus making it easy to use with IDEs and (IMO) easier to grok while reading directly, although maybe most people don't think about shadowing to the same extent I do and wouldn't be as bothered by this in general. Still, the IDE support is incredibly useful.
baq 7y ago
there are python implementations where locals() is unavailable or available at significant cost.
kragen 7y ago
> Do you find the same problems when using f strings? No, you can't define f strings elsewhere, and in theory your IDE can statically analyze them just as the Python interpreter does. In practice, your IDE might suck, I don't know.

ehsankia 7y ago

They just added a brand new feature in 3.8 that let's you just append = at the end for quick debugging: >>> f'{5+5=}' '5+5=10' >>> foo = 5 >>> f'{foo=}' 'foo=5' https://docs.python.org/dev/whatsnew/3.8.html#f-strings-now-support-for-quick-and-easy-debugging https://docs.python.org/dev/whatsnew/3.8.html#f-strings-now-...

gizmo385 7y ago
This just feels like another example of Python slowly creeping more esoteric syntax into the language, making it harder for beginners to approach the language.
- jplayer01 7y ago
  Beginners don't have to know or touch any of this though. They can keep using normal strings until at some point they learn about f strings and see a need for them. You don't need to stop adding features to a language just because a beginner won't be able to learn everything. They don't need to.
  - simonh 7y ago
    I think the point is, a beginner coming across some code using such esoteric features is going to be a bit lost as to what's going on. With most of Python you can see what it's doing even if you didn't know the syntax before. That's true of basic f-strings, but not so much with some of this stuff.
    - makapuf 7y ago
      Yeah languages are meant to be read even by beginners. I think a language like python shines by being small (in design) yet powerful (by capability). Having myriads of "nice for one use case" feature in the language is not the way forward. I long for the time where % format and .format are removed from the language spec. Even if they still work on the implementation for compatibility. Please remove things.

AtHeartEngineer 7y ago

Conda with pipenv = great

stOneskull 7y ago
it's great if using debian where it's still on 3.5. installing miniconda lets you have the newest python easy-peasy