If you just want one object that matches your filters during debugging, without
overhead, why don’t you use .last() instead?
> On 14 Apr 2019, at 7:14 am, Tom Forbes wrote:
>
> I don’t think we should add a method like this for a few reasons. Firstly
> without an order by in SQL the order of
On Sun, Apr 14, 2019 at 1:34 AM Carlton Gibson wrote:
>
> We spend a lot of time spotting small formatting errors and then asking for
> those to be fixed and then waiting for an update. This wastes reviewer time
> and slows down the feedback cycle. Many pull requests drag out because of it.
We spend a lot of time spotting small formatting errors and then asking for
those to be fixed and then waiting for an update. This wastes reviewer time
and slows down the feedback cycle. Many pull requests drag out because of
it.
For this reason I would be 100% behind adopting black, and applying
I don’t think we should add a method like this for a few reasons. Firstly
without an order by in SQL the order of rows is undefined, in practice myql
orders rows but Postgres returns a different order per transaction. This will
be confusing to users who don’t understand this and come to
On Saturday, April 13, 2019 at 10:58:24 PM UTC+2, alTus wrote:
>
> I've posted the source code if `first`. You can see there that if qs is
> not ordered then ordering by pk is added.
> It's the main point of this issue btw.
>
Oh I didn't realize that first enforces ordering. Yet another function
I've posted the source code if `first`. You can see there that if qs is not
ordered then ordering by pk is added.
It's the main point of this issue btw.
суббота, 13 апреля 2019 г., 22:53:52 UTC+3 пользователь Florian Apolloner
написал:
>
> qs.order_by().first() should do what you want and is
On Saturday, April 13, 2019 at 8:23:13 PM UTC+2, Adam Johnson wrote:
>
> I’d like to see gradual roll out (one module at a time? One rule at a
> time?) to spread the work of reformatting all the in-flight patches.
>
My thoughts initially. But then I realized that it would be easier for
tooling
On Sat, Apr 13, 2019 at 1:18 PM Florian Apolloner
wrote:
> Maybe, but I think the benefits outweigh the costs -- and I also do not
> think that it is unnecessary. Our goal has always been to make contributing
> easier, well nowadays black is in the position to do just that.
>
I feel like Black
Hi,
On Saturday, April 13, 2019 at 9:41:38 PM UTC+2, Berker Peksağ wrote:
>
> I came here to say exactly this. Django's codebase is already pretty
> consistent with its own style and I think having a usable "git blame"
> is much more important than starting to use a new code formatter.
I am
qs.order_by().first() should do what you want and is not worth adding .one()
Cheers,
Florian
On Saturday, April 13, 2019 at 5:48:29 PM UTC+2, alTus wrote:
>
> Hello.
>
> Please consider if that proposal can be useful not only for me :)
>
> `QuerySet.first` is quite useful shortcut but its
On Sat, Apr 13, 2019 at 9:19 PM Tobias McNulty wrote:
> Overall, the main downside I see is the large, fairly useless changeset this
> would create and the impact it would have, such as reduced utility of `git
> blame` for some portion of the code for the foreseeable future and
> interruption
No, because qs[0] will raise exception if nothing found (and still it will
have ordering).
суббота, 13 апреля 2019 г., 21:24:30 UTC+3 пользователь Adam Johnson
написал:
>
> Doesn’t it work to do qs[0] ?
>
> On Sat, 13 Apr 2019 at 17:48, alTus >
> wrote:
>
>> Hello.
>>
>> Please consider if
Doesn’t it work to do qs[0] ?
On Sat, 13 Apr 2019 at 17:48, alTus wrote:
> Hello.
>
> Please consider if that proposal can be useful not only for me :)
>
> `QuerySet.first` is quite useful shortcut but its drawback is that it
> involves ordering so some DB queries become expensive.
> But quite
On Sat, Apr 13, 2019 at 11:35 AM Herman S wrote:
> I've set up how this _could_ look depending on some configurables in Black:
>
> * Default config: https://github.com/hermansc/django/pull/1
> * Line length kept at 119: https://github.com/hermansc/django/pull/3
> * Line length kept at 119, no
+1
I’d like to see gradual roll out (one module at a time? One rule at a
time?) to spread the work of reformatting all the in-flight patches.
On Sat, 13 Apr 2019 at 18:45, Jon Dufresne wrote:
> Big +1
>
> I've used black in quite a few projects now and found it has greatly
> reduced the mental
On Sat, Apr 13, 2019 at 12:07 PM Florian Apolloner
wrote:
> As expressed at Djangocon Europe, I am hugely in favor for adopting black.
>
A quick glance suggests this would result in ~20k lines changed (~27% of
non-whitespace, non-comment code lines) in django/ and ~58k lines changed
(~41%) in
Big +1
I've used black in quite a few projects now and found it has greatly
reduced the mental energy involved in code formatting while aligning all
contributors expectations.
I'm in favor of adding no configuration. That is, use black's default line
length and string delimiters. IMO, the less
/Markus
On Sat, Apr 13, 2019, at 6:08 PM, Florian Apolloner wrote:
> As expressed at Djangocon Europe, I am hugely in favor for adopting black.
>
> If we choose to do this there are a few things to consider:
>
> * Line-length, we probably want to stay at 119 I guess
> * String
As expressed at Djangocon Europe, I am hugely in favor for adopting black.
If we choose to do this there are a few things to consider:
* Line-length, we probably want to stay at 119 I guess
* String normalization, I'd be in favor of following black defaults here,
but I am open to be convinced
I'm in favour. Not needing to think much about code style when writing code
or when reviewing is very nice.
Ian
On Sat, 13 Apr 2019 at 13:52, Herman S wrote:
> Hi.
>
> I propose that Django starts using 'black' [0] to auto-format all Python
> code.
> For those unfamiliar with 'black' I
Hello.
Please consider if that proposal can be useful not only for me :)
`QuerySet.first` is quite useful shortcut but its drawback is that it
involves ordering so some DB queries become expensive.
But quite often (and very often while debugging) there's a need just to get
one object that
Hi.
I propose that Django starts using 'black' [0] to auto-format all Python code.
For those unfamiliar with 'black' I recommend reading the the projects README.
The short version: it aims to reduce bike-shedding and non value-adding
discussions; saving time reviewing code; and making the barrier
On Sat, 13 Apr 2019 08:22:11 -0400
"Markus Holtermann" wrote:
>
> As discussed at the DCEU sprints I think I'd like to be able to omit
> the display form of an item and have it auto generated from an item's
> name, i.e. turning "FOO_BAR" into "Foo Bar" (`key.replace("_", "
> ").title()`)
>
I really like this implementation, it seems really clean and simple.
I would suggest that it might be worth seeing it’s simple to make the
display text optional, I think in the general case capitalising the key
name would be acceptable. Users can always override it if required or if
they need
Thanks for the proposal, Shai. I quite like it.
As discussed at the DCEU sprints I think I'd like to be able to omit the
display form of an item and have it auto generated from an item's name, i.e.
turning "FOO_BAR" into "Foo Bar" (`key.replace("_", " ").title()`)
Further, we could also
On Saturday, April 13, 2019 at 1:07:39 PM UTC+2, Florian Apolloner wrote:
>
> You could have reused https://github.com/aaugustin/django-sesame for the
> signing stuff :)
>
Ok django-sesame goes into a different direction but might still be worth
to look at it.
--
You received this message
Hi,
On Friday, April 12, 2019 at 8:06:21 PM UTC+2, Johannes Hoppe wrote:
>
> I went with the hardest possible way, NO password, NO username. Just one
> time passwords send via email or SMS. Similar to Django’s password reset
> function.
>
I do not think that is the hardest possible way and as
Back to this issue for the DjangoCon EU sprints...
James' objection about the inclusion testing needed for validation
seems moot, because validation can be done by conversion to the enum
type (as noted by Tom).
Raphael's warning about the woes of translation are already handled by
the suggested
28 matches
Mail list logo
