Re: f-strings again.

+1 iff flake8 can validate f-srings as well as PyCharm does f-strings! I think flake8 would mean that SublimeText and Atom can highlight errors. Background - Arguments based on readability are so subjective. If I am using Pycharm, f-strings are very readable, and it will check whether a keyword

Re: f-strings again.

Hi Dave and all, On Tue, 21 Jul 2020 13:56:53 +0100 Dave Vernon wrote: > More generally: > > I understand the value of *not* doing a bulk change in a PR, but I was > wondering if it's OK to do a PR based purely on improved performance > for a specific element? (I don't have one in mind, the

Re: f-strings again.

> > I was wondering if it's OK to do a PR based purely on improved > performance for a specific element? (I don't have one in mind, the question > is purely 'in principle') Benchmarked performance improvements are always welcome. I normally use %timeit in ipython for this. On Tue, 21 Jul 2020

Re: f-strings again.

+1 to start using and suggesting f-string in new PRs I agree to avoid bulk updated only to use f-string in old code. I think we can write a priority list of string formatting styles to help new and old contributors in following the same code style in all PRs. I will suggest this order: 1)

Re: f-strings again.

Hi Shai, If you used '<{0} id="{1}"> {2} '.format(tag, id, content) in a templatetag (for example), it could easily be used iteratively which would increase the need for performance and at that point, you could argue that f'<{tag} id="{id}"> {content} ' would be a preferable choice, even though

Re: f-strings again.

On Tue, 21 Jul 2020 01:28:31 -0700 (PDT) Carlton Gibson wrote: > > Certainly 99% of cases can be handled as cleanly (or more so, because > I guess we fell `format()` is a little verbose) with %-formatting or > an f-string. > But if we say format() is not allowed, don't we then guarantee we hit

Re: f-strings again.

I've been one of those who previously were against adding them to Django. Mostly, because I wasn't used to them and didn't see their value. But more importantly, because I was worried about unintended security issues they could cause. Why the latter is still present, I've think the

Re: f-strings again.

I'm also +1, I find f-strings easier to read in most cases. You can go overboard - and I probably do - but I don't think the guard against unreadable f-strings is to ban them outright. One small negative to % formatting for me is that I sometimes get confused for a second about whether something

Re: f-strings again.

+1, I'd happily help on any PR with this (it would be my first!). Kind Regards, Dave Springbourne Tech Limited M: +44(0) 79 2107 6483 W: www.springbourne-tech.com *—This E-Mail and its contents are confidential, protected by law and legally privileged. Only access by the addressee is

Re: f-strings again.

Hi, So I'm in favour of using f-strings, but agree that there are places where they are not appropriate. I am also against bulk updates in this case as mentioned in my previous comment . I don't think we should exclude

Re: f-strings again.

I'm +1 f-string -- very conformable, easy to work with, and fits 99% of my needs. I'm -1 removing .format() -- there are some limitations to f-string, for example using them for a template-like placeholder/i18n, in these cases .format() comes very handy. Yes, I suppose %-format in these

Re: f-strings again.

I don't like f-strings (actually I was not aware what they are until I googled them now). I also don't like the %-formatting and I prefer to use {}-format (with or without a number or name) for all my formatting purposes. In general, f-strings take variables which are not given to them

Re: f-strings again.

I'm going to float this here, just to make sure it's considered... `format()` allows positional and named kwargs in format strings: "First, thou shalt count to {0}" # References first positional argument "Bring me a {}" # Implicitly references the first positional argument

Re: f-strings again.

+1 to allowing f-strings. Mariusz' position dropping .format() seems reasonable to me too. I can't think of a reason to use them over f-strings, off the top of my head. On Tue, 21 Jul 2020 at 09:00, laym...@gmail.com wrote: > Hi folks, > > I personally like to use f-strings wherever it makes

Re: f-strings again.

I strongly agree with Mariusz on I would also be in favor of keeping only %-formatting and f-strings in > Coding style docs. I don't see any reason to use also `format()` in a new > code. so +1 from my side for f-strings. Actually, in one of my side projects, %-formatting wouldn't even

Re: f-strings again.

Hi folks, I personally like to use f-strings wherever it makes sense, so +1. I agree with Mariusz. I think we should only allow %-formatting and f-strings from now on. And yes, bulk updates should not be done. Aside from making unnecessary noise, there's always a risk in doing that kind of

Re: f-strings again.

Hi y'all, I will not stand against f-strings, I think we can allow them. My main concerns is readability. f-strings are powerful and it's quite common that they are used with functions calls and complex formatting which makes code hard to understand and maintain, *"With great power comes

f-strings again.

Hi All. f-strings... There was some discussion a couple of years ago about replacing all string formatting operations with f-strings. The consensus then was "No, let's not do that": %-formatting and format() are