Re: queryset.values() / GROUP BY

Hi Shai, thanks! I need to look a bit deeper into this I guess. Just for completeness, I am looking at this code in one of my projects: ``` def get_all_colors(self, queryset): color_ids = queryset.order_by('color').values_list('color', flat=True).distinct() found_colors =

Re: queryset.values() / GROUP BY

I didn't look too deeply at the project, but after checking the readme and Shai's summary: - Sets the seclected fields as attributes on the object returned, > rather than as dict values > - Where the selected field is a FK, follows the relationship to get the > object > ...I think both of

Re: queryset.values() / GROUP BY

This looks like a cool little side project. I would keep it there, the use case is very limited. I've always seen the django ORM as a very basic > On Jul 21, 2020, at 12:46 PM, René Fleschenberg wrote: > > Hi, > > on IRC, someone hinted me at https://github.com/kako-nawao/django-group-by >

Re: queryset.values() / GROUP BY

Hi René, On Tue, 21 Jul 2020 18:46:12 +0200 René Fleschenberg wrote: > https://github.com/kako-nawao/django-group-by > It doesn't actually aggregate, so the name "group-by" seems unwarranted. What it does, as the README explains, is replace "values" by something which does two things: - Sets

queryset.values() / GROUP BY

Hi, on IRC, someone hinted me at https://github.com/kako-nawao/django-group-by today. Is there a deeper reason why this functionality is not available in Django core, or is it just that nobody got around to implementing it yet? To me, it seems like something that would be nice to have

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