Re: Add to QuerySet method `one` that acts as `first` but without ordering

[Joshua Lawes]

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 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 implicitly rely 
> on first() being stable.
> 
> Secondly if you are filtering on an indexed column the overhead will be next 
> to none. Is this not the case?
> 
> And lastly, changing this would be major backwards incompatible change.
> 
> Tom
> 
>> On 13 Apr 2019, at 21:58, 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.
>> 
>> суббота, 13 апреля 2019 г., 22:53:52 UTC+3 пользователь Florian Apolloner 
>> написал:
>>> 
>>> 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 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 satisfy some filters.
 
 Current `first` implementation to compare with:
 
 def first(self):
 """Return the first object of a query or None if no match is 
 found."""
 for obj in (self if self.ordered else self.order_by('pk'))[:1]:
 return obj
 
 Proposal (as an example of implementation):
 
 def one(self):
 """Return one random object of a query or None if no match is 
 found."""
 for obj in self.order_by()[:1]:
 return obj
 
 That would be short, simple and wouldn't require any imports in client 
 code.
 
 Thank you.
 
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/fc6e71e5-a9b5-4cb5-9283-de1130ff0b2e%40googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/B83882F9-E932-4258-93D7-100A3D4A933D%40tomforb.es.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/DCA537BC-A189-4D59-9C65-10C4C3732B27%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Berker Peksağ]

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.

But you can now do final edits (cosmetic changes, tweak reST markup
and documentation) via GitHub UI, right? I always do it to not bother
contributors with these changes, especially if they are new to the
project.

--Berker

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAF4280J%2B6J1BJAto1MHd8mo5X%2Bm4AohSqS2HQr3yNXh1WOUcRQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Carlton Gibson]

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 that in
a single commit.

My only reservation is about the history. I don’t know the tools Florian
mentioned but I wonder if there is a clever git blame usage that would
allow bringing over a single commit change of this sort?

Even if we can’t solve that I’d still be +1 for the added ease to
contributors and the speed benefits to review efforts.

C.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJwKpyQxxCKfniqmt5qQXG0Nz1oeB4rzhWpT4e_fWTPMDsf-zA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add to QuerySet method `one` that acts as `first` but without ordering

[Tom Forbes]

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 implicitly rely on 
first() being stable.

Secondly if you are filtering on an indexed column the overhead will be next to 
none. Is this not the case?

And lastly, changing this would be major backwards incompatible change.

Tom

> On 13 Apr 2019, at 21:58, 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.
> 
> суббота, 13 апреля 2019 г., 22:53:52 UTC+3 пользователь Florian Apolloner 
> написал:
>> 
>> 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 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 satisfy some filters.
>>> 
>>> Current `first` implementation to compare with:
>>> 
>>> def first(self):
>>> """Return the first object of a query or None if no match is 
>>> found."""
>>> for obj in (self if self.ordered else self.order_by('pk'))[:1]:
>>> return obj
>>> 
>>> Proposal (as an example of implementation):
>>> 
>>> def one(self):
>>> """Return one random object of a query or None if no match is 
>>> found."""
>>> for obj in self.order_by()[:1]:
>>> return obj
>>> 
>>> That would be short, simple and wouldn't require any imports in client code.
>>> 
>>> Thank you.
>>> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/fc6e71e5-a9b5-4cb5-9283-de1130ff0b2e%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/B83882F9-E932-4258-93D7-100A3D4A933D%40tomforb.es.
For more options, visit https://groups.google.com/d/optout.

Re: Add to QuerySet method `one` that acts as `first` but without ordering

[Florian Apolloner]

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 is 
not a good idea though I fear. I'd check what the reason for enforcing 
ordering in `.first` are and maybe we can just drop that. qs[0] wouldn't 
enforce ordering either (or does it), so why would first do that…

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/dbe81ba1-ec80-4e78-b63d-a67bfdfae538%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add to QuerySet method `one` that acts as `first` but without ordering

[alTus]

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 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 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 satisfy some filters.
>>
>> Current `first` implementation to compare with:
>>
>> def first(self):
>> """Return the first object of a query or None if no match is 
>> found."""
>> for obj in (self if self.ordered else self.order_by('pk'))[:1]:
>> return obj
>>
>> Proposal (as an example of implementation):
>>
>> def one(self):
>> """Return one random object of a query or None if no match is 
>> found."""
>> for obj in self.order_by()[:1]:
>> return obj
>>
>> That would be short, simple and wouldn't require any imports in client 
>> code.
>>
>> Thank you.
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fc6e71e5-a9b5-4cb5-9283-de1130ff0b2e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Florian Apolloner]

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 if there were just one commit to exclude (also easier for 
developers to remember that one) and commits that get merged while we are 
converting module by module would be very careful over which files to run 
black…  

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5bd7f89e-f2d0-4a30-b014-3b933541dc8e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[James Bennett]

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 is useful for projects that don't already have and
enforce a style guide. But we already have and enforce a style guide, and
some parts of it are things Black can't auto-enforce. So I'm not sure I see
what benefit we'd get out of Black, and the downside is a lot of churn.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg9UNSujA3qCCp4JcvtA5uZRduGOOEKCHp4OCNjCbbH2Zg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Florian Apolloner]

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 not sure I agree with this argument. We already have had big code 
changes which make git blame useless (if you are looking for a commit from 
like 8 years ago or so). All we are doing to do is adding one commit more 
to that list (and the tooling to work around one such a commit is good, ie 
git-hyper-blame, git gui blame etc etc). 
 

> with a codebase as big as Django, trying to adapt a different style 
> guide would only cause unnecessary code churn.
>

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.

The following style is much more readable (and it also makes future 
> diffs less noisy since we can add new formats without having reformat 
> code and comments) than black-formatted code: 
>

Yes, the formats (same for settings files) are imo certainly files we could 
exclude from black. That said those files are highly specific and hardly 
representative for python code.

Cheers,
Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7eb37396-04a0-41a7-960f-cbcbd4ac0001%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add to QuerySet method `one` that acts as `first` but without ordering

[Florian Apolloner]

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 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 satisfy some filters.
>
> Current `first` implementation to compare with:
>
> def first(self):
> """Return the first object of a query or None if no match is 
> found."""
> for obj in (self if self.ordered else self.order_by('pk'))[:1]:
> return obj
>
> Proposal (as an example of implementation):
>
> def one(self):
> """Return one random object of a query or None if no match is 
> found."""
> for obj in self.order_by()[:1]:
> return obj
>
> That would be short, simple and wouldn't require any imports in client 
> code.
>
> Thank you.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2c6f464f-796f-4689-8d19-3ec936e84f60%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Berker Peksağ]

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 to all in-progress PRs. Problems that can be worked around, 
> sure, but it would be an interruption to ongoing work nonetheless.

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. IMO,
with a codebase as big as Django, trying to adapt a different style
guide would only cause unnecessary code churn.

The following style is much more readable (and it also makes future
diffs less noisy since we can add new formats without having reformat
code and comments) than black-formatted code:

TIME_INPUT_FORMATS = [
'%H:%M:%S', # '14:30:59'
'%H:%M:%S.%f', # '14:30:59.000200'
'%H:%M', # '14:30'
]

Reformatted by black:

TIME_INPUT_FORMATS = ['%H:%M:%S', '%H:%M:%S.%f', '%H:%M'] # '14:30:59'
# '14:30:59.000200' # '14:30'

(Taken from 
https://github.com/hermansc/django/pull/2/files#diff-ba8335f5987fcd81d41c28cd1879a9bfL370)

(Also, thank you for creating PRs with different black configurations, Herman.)

--Berker

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAF4280%2BB9k0Nymm4Oq%3DxnGe0gnZCzx2cDs3-esEBxDp2W9P-bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add to QuerySet method `one` that acts as `first` but without ordering

[alTus]

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 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 satisfy some filters.
>>
>> Current `first` implementation to compare with:
>>
>> def first(self):
>> """Return the first object of a query or None if no match is 
>> found."""
>> for obj in (self if self.ordered else self.order_by('pk'))[:1]:
>> return obj
>>
>> Proposal (as an example of implementation):
>>
>> def one(self):
>> """Return one random object of a query or None if no match is 
>> found."""
>> for obj in self.order_by()[:1]:
>> return obj
>>
>> That would be short, simple and wouldn't require any imports in client 
>> code.
>>
>> Thank you.
>>
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-d...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/c4337df6-c0f3-44fe-bbc0-01fe01cdf621%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> -- 
> Adam
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c4fbb785-6857-44f5-b0ef-2c5107e0d6b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add to QuerySet method `one` that acts as `first` but without ordering

[Adam Johnson]

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 often (and very often while debugging) there's a need just to
> get one object that satisfy some filters.
>
> Current `first` implementation to compare with:
>
> def first(self):
> """Return the first object of a query or None if no match is
> found."""
> for obj in (self if self.ordered else self.order_by('pk'))[:1]:
> return obj
>
> Proposal (as an example of implementation):
>
> def one(self):
> """Return one random object of a query or None if no match is
> found."""
> for obj in self.order_by()[:1]:
> return obj
>
> That would be short, simple and wouldn't require any imports in client
> code.
>
> Thank you.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/c4337df6-c0f3-44fe-bbc0-01fe01cdf621%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Adam

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM0L7ySa7DYnh_to7oNKFhasK1iqW7zZY_c9JRs6d-qfGQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Tobias McNulty]

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 string normalization:
> https://github.com/hermansc/django/pull/2


Apologies, somehow I missed these links on the first read. Go here for an
overview of lines changed, don't use my numbers. :-)

Tobias

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMGFDKQo2W430rqH4oZ7D89bJ4ix-xmxYx_WWYzAajMyZ493Jg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Adam Johnson]

+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 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 configuration the better. The
> more the Django code style aligns with the larger Python community, the
> better and easier it is few new contributors. But these secondary choices
> are less important to me than the improvement of adopting a tool to
> auto-format code.
>
> On Sat, Apr 13, 2019 at 8:35 AM Herman S 
> wrote:
>
>> 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 to entry
>> lower
>> by taking some uncompromissing choices with regards to formatting.  This
>> is
>> similar to tools such as 'gofmt' for Go and 'prettier' for Javascript.
>>
>> Personally I first got involved contributing to Django couple of weeks
>> back,
>> and from anecdotal experience I can testify to how 'formatting of code'
>> creates
>> a huge barrier for entry. My PR at the time went multiple times back and
>> forth
>> tweaking formatting. Before this, I had to research the style used by
>> exploring
>> the docs at length and reading at least 10-20 different source – and even
>> those
>> were not always consistent. At the end of the day I felt like almost 50%
>> of the
>> time I used on the patch was not used on actually solving the issue at
>> hand.
>> Thinking about code formatting in 2019 is a mental energy better used for
>> other
>> things, and it feels unnecessary that core developers on Django spend
>> their time
>> "nit-picking" on these things.
>>
>> I recently led the efforts to make this change where I work. We have a
>> 200K+
>> LOC Django code-base with more than 30K commits. Some key take-aways: it
>> has
>> drastically changed the way we work with code across teams, new engineers
>> are
>> easier on-boarded, PR are more focused on architectural choices and
>> "naming
>> things", existing PRs before migration had surprisingly few conflicts and
>> were
>> easy to fix, hot code paths are already "blameable" and it's easy to
>> blame a
>> line of code and go past the "black-commit", and lastly the migration went
>> without any issues or down-time.
>>
>> I had some really fruitful discussions at DjangoCon Europe this week on
>> this
>> very topic, and it seems we are not alone in these experiences. I would
>> love to
>> hear from all of you and hope that we can land on something that will
>> enable
>> *more* people to easier contribute back to this project.
>>
>> 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 string normalization:
>> https://github.com/hermansc/django/pull/2
>>
>> Please have a look at the Black documentation. It explains the benefits
>> better
>> than I possibly could do here.
>>
>> With kind regards,
>> Herman Schistad
>>
>> [0]: https://github.com/ambv/black
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers  (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CAN%3DnMTx0EE5WfXuccv_e3MBuCxp9u_pAV_ow5MxNST6MptTDBw%40mail.gmail.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CADhq2b4K6ox%3DZ2YPqF%2BWpxGAFkdF1gjViudJ9QhkVn7UKjy%3DRA%40mail.gmail.com
> 

Re: Proposal to format Django using black

[Tobias McNulty]

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 tests/ (with `--line-length=119`). After the initial pass to fix
everything `black -l 119 tests/ django/` takes only 2.3 seconds to run (!),
though I'm sure my OS had all the files cached at that point.

Without normalizing strings, the number of changed lines comes down to ~14k
(~19%) for django/ and ~23k (~16%) for tests/ (with
`--skip-string-normalization --line-length=119`).

I'm sure some people will see this as "a ton" and others "only that much?"
:-)

(My line counts are imperfect and approximate, and you'll likely get
somewhat different numbers if you try this yourself.)

If we choose to do this there are a few things to consider:
>
>  * Line-length, we probably want to stay at 119 I guess
>

Perhaps we could compromise and choose something in the middle, for the
reasons noted in the docs:
https://black.readthedocs.io/en/stable/the_black_code_style.html#line-length

We should also consider adding max-doc-length for flake8 to our setup.cfg,
and/or forego the shorter requirement for comments/docstrings *if* we
shorten the maximum line length for code.

This section

in the docs will need updating if we hand this off to a 3rd-party formatter
(in particular the sentence, "Don’t limit lines of code to 79 characters if
it means the code looks significantly uglier or is harder to read." since
we'll no longer have the option of shortening lines to 79 characters
arbitrarily).

 * String normalization, I'd be in favor of following black defaults here,
> but I am open to be convinced otherwise
>

It'd be nice to minimize the diff, but I'd be fine either way. If we're
going to do it eventually, better to do so all at once.


>  * We will need to adjust the isort configuration (
> https://github.com/ambv/black/blob/master/README.md#how-black-wraps-lines
> )
>

+1

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 to all in-progress PRs. Problems that can be worked around,
sure, but it would be an interruption to ongoing work nonetheless.

One question: Would we want to update some/all code samples in the docs
with the same code style? I imagine that could be a fairly time-intensive
endeavor, unless someone's already found a way to automate the process. In
particular, Black's format for chaining method calls

differs from Django's preferred style
.
Applying this standard to the docs without discretion may lead to less
readable docs, IMO...on the other hand, it's odd to have code samples that
don't pass our own tests...

In any case, while this sounds like a non-trivial project with some
questions to work through yet, I too like not having to worry about code
formatting and don't have any real objections to this.

Cheers,



*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMGFDKQo_7aru%3DGJWQGj8g1Fv69iq2H3Wp6%3D0%2Bdp2NKTaHh4OA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Jon Dufresne]

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 configuration the better. The
more the Django code style aligns with the larger Python community, the
better and easier it is few new contributors. But these secondary choices
are less important to me than the improvement of adopting a tool to
auto-format code.

On Sat, Apr 13, 2019 at 8:35 AM Herman S  wrote:

> 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 to entry
> lower
> by taking some uncompromissing choices with regards to formatting.  This is
> similar to tools such as 'gofmt' for Go and 'prettier' for Javascript.
>
> Personally I first got involved contributing to Django couple of weeks
> back,
> and from anecdotal experience I can testify to how 'formatting of code'
> creates
> a huge barrier for entry. My PR at the time went multiple times back and
> forth
> tweaking formatting. Before this, I had to research the style used by
> exploring
> the docs at length and reading at least 10-20 different source – and even
> those
> were not always consistent. At the end of the day I felt like almost 50%
> of the
> time I used on the patch was not used on actually solving the issue at
> hand.
> Thinking about code formatting in 2019 is a mental energy better used for
> other
> things, and it feels unnecessary that core developers on Django spend
> their time
> "nit-picking" on these things.
>
> I recently led the efforts to make this change where I work. We have a
> 200K+
> LOC Django code-base with more than 30K commits. Some key take-aways: it
> has
> drastically changed the way we work with code across teams, new engineers
> are
> easier on-boarded, PR are more focused on architectural choices and "naming
> things", existing PRs before migration had surprisingly few conflicts and
> were
> easy to fix, hot code paths are already "blameable" and it's easy to blame
> a
> line of code and go past the "black-commit", and lastly the migration went
> without any issues or down-time.
>
> I had some really fruitful discussions at DjangoCon Europe this week on
> this
> very topic, and it seems we are not alone in these experiences. I would
> love to
> hear from all of you and hope that we can land on something that will
> enable
> *more* people to easier contribute back to this project.
>
> 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 string normalization:
> https://github.com/hermansc/django/pull/2
>
> Please have a look at the Black documentation. It explains the benefits
> better
> than I possibly could do here.
>
> With kind regards,
> Herman Schistad
>
> [0]: https://github.com/ambv/black
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAN%3DnMTx0EE5WfXuccv_e3MBuCxp9u_pAV_ow5MxNST6MptTDBw%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADhq2b4K6ox%3DZ2YPqF%2BWpxGAFkdF1gjViudJ9QhkVn7UKjy%3DRA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Markus Holtermann]



/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 normalization, I'd be in favor of following black defaults 
> here, but I am open to be convinced otherwise
>  * We will need to adjust the isort configuration ( 
> https://github.com/ambv/black/blob/master/README.md#how-black-wraps-lines )
> 
> Cheers,
> Florian
> 
>  -- 
>  You received this message because you are subscribed to the Google 
> Groups "Django developers (Contributions to Django itself)" group.
>  To unsubscribe from this group and stop receiving emails from it, send 
> an email to django-developers+unsubscr...@googlegroups.com.
>  To post to this group, send email to 
> django-developers@googlegroups.com.
>  Visit this group at https://groups.google.com/group/django-developers.
>  To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/698d8e49-0deb-437c-b6ce-a321fe3988e3%40googlegroups.com
>  
> .
>  For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8e323d0c-b077-4bbd-8384-19cf6022a445%40www.fastmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Florian Apolloner]

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 otherwise
 * We will need to adjust the isort configuration ( 
https://github.com/ambv/black/blob/master/README.md#how-black-wraps-lines )

Cheers,
Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/698d8e49-0deb-437c-b6ce-a321fe3988e3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Ian Foote]

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 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 to entry
> lower
> by taking some uncompromissing choices with regards to formatting.  This is
> similar to tools such as 'gofmt' for Go and 'prettier' for Javascript.
>
> Personally I first got involved contributing to Django couple of weeks
> back,
> and from anecdotal experience I can testify to how 'formatting of code'
> creates
> a huge barrier for entry. My PR at the time went multiple times back and
> forth
> tweaking formatting. Before this, I had to research the style used by
> exploring
> the docs at length and reading at least 10-20 different source – and even
> those
> were not always consistent. At the end of the day I felt like almost 50%
> of the
> time I used on the patch was not used on actually solving the issue at
> hand.
> Thinking about code formatting in 2019 is a mental energy better used for
> other
> things, and it feels unnecessary that core developers on Django spend
> their time
> "nit-picking" on these things.
>
> I recently led the efforts to make this change where I work. We have a
> 200K+
> LOC Django code-base with more than 30K commits. Some key take-aways: it
> has
> drastically changed the way we work with code across teams, new engineers
> are
> easier on-boarded, PR are more focused on architectural choices and "naming
> things", existing PRs before migration had surprisingly few conflicts and
> were
> easy to fix, hot code paths are already "blameable" and it's easy to blame
> a
> line of code and go past the "black-commit", and lastly the migration went
> without any issues or down-time.
>
> I had some really fruitful discussions at DjangoCon Europe this week on
> this
> very topic, and it seems we are not alone in these experiences. I would
> love to
> hear from all of you and hope that we can land on something that will
> enable
> *more* people to easier contribute back to this project.
>
> 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 string normalization:
> https://github.com/hermansc/django/pull/2
>
> Please have a look at the Black documentation. It explains the benefits
> better
> than I possibly could do here.
>
> With kind regards,
> Herman Schistad
>
> [0]: https://github.com/ambv/black
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAN%3DnMTx0EE5WfXuccv_e3MBuCxp9u_pAV_ow5MxNST6MptTDBw%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFv-zf%2BAo57rc4k9%2B0Ndu%3DEVprv5JLGu0tM2ihdwWcddCr%3DcXg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Add to QuerySet method `one` that acts as `first` but without ordering

[alTus]

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 satisfy some filters.

Current `first` implementation to compare with:

def first(self):
"""Return the first object of a query or None if no match is 
found."""
for obj in (self if self.ordered else self.order_by('pk'))[:1]:
return obj

Proposal (as an example of implementation):

def one(self):
"""Return one random object of a query or None if no match is 
found."""
for obj in self.order_by()[:1]:
return obj

That would be short, simple and wouldn't require any imports in client code.

Thank you.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c4337df6-c0f3-44fe-bbc0-01fe01cdf621%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Proposal to format Django using black

[Herman S]

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 to entry lower
by taking some uncompromissing choices with regards to formatting.  This is
similar to tools such as 'gofmt' for Go and 'prettier' for Javascript.

Personally I first got involved contributing to Django couple of weeks back,
and from anecdotal experience I can testify to how 'formatting of code' creates
a huge barrier for entry. My PR at the time went multiple times back and forth
tweaking formatting. Before this, I had to research the style used by exploring
the docs at length and reading at least 10-20 different source – and even those
were not always consistent. At the end of the day I felt like almost 50% of the
time I used on the patch was not used on actually solving the issue at hand.
Thinking about code formatting in 2019 is a mental energy better used for other
things, and it feels unnecessary that core developers on Django spend their time
"nit-picking" on these things.

I recently led the efforts to make this change where I work. We have a 200K+
LOC Django code-base with more than 30K commits. Some key take-aways: it has
drastically changed the way we work with code across teams, new engineers are
easier on-boarded, PR are more focused on architectural choices and "naming
things", existing PRs before migration had surprisingly few conflicts and were
easy to fix, hot code paths are already "blameable" and it's easy to blame a
line of code and go past the "black-commit", and lastly the migration went
without any issues or down-time.

I had some really fruitful discussions at DjangoCon Europe this week on this
very topic, and it seems we are not alone in these experiences. I would love to
hear from all of you and hope that we can land on something that will enable
*more* people to easier contribute back to this project.

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 string normalization:
https://github.com/hermansc/django/pull/2

Please have a look at the Black documentation. It explains the benefits better
than I possibly could do here.

With kind regards,
Herman Schistad

[0]: https://github.com/ambv/black

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAN%3DnMTx0EE5WfXuccv_e3MBuCxp9u_pAV_ow5MxNST6MptTDBw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request to reconsider ticket #27910: using an Enum class in model Field choices

[Shai Berger]

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()`)
> 

Yes, that's an improvement.

> Further, we could also simplify the Fields API more and do this:
> 
> class Card(models.Model):
> suit = models.IntegerField(choices=Suit)
> 

I have doubts about this, because enum classes are iterable -- so at
first look, it might not be totally obvious of 

 suit = models.IntegerField(choices=Suit)

actually means

 suit = models.IntegerField(choices=list(Suit))

or

 suit = models.IntegerField(choices=Suit.choices())

although the repetition of the word "choices" in the last version is a
bit jarring. I could be convinced to change my mind.

Thanks,
Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20190413171918.60c5fc66.shai%40platonix.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request to reconsider ticket #27910: using an Enum class in model Field choices

[Tom Forbes]

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 translation support.

Even if we decide to make the display names required in all cases, it’s a
great improvement over the current way of defining choices IMO.

Tom




On 13 April 2019 at 10:33:39, Shai Berger (s...@platonix.com) wrote:

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 implementation -- because it isn't the enum value that
we make translatable, but rather an attribute on it.

I should point that the suggested implementation uses IntEnum and
StrEnum. The Python documentation recommends against using these,
except in the case that one needs to account for compatibility with an
existing protocol -- which, I submit to you, is exactly our case (the
"protocol" being the types available for database fields).

As a reminder, the relevant links are:

https://code.djangoproject.com/ticket/27910
https://github.com/django/django/compare/master...shaib:ticket_27910?expand=1

Thanks,
Shai.

-- 
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/20190413113323.1342ed7d.shai%40platonix.com.

For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFNZOJMMh6nH8VdAozeVnLbQXanqB5b864Ro1g%2BGm2N6hWM%3DgQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request to reconsider ticket #27910: using an Enum class in model Field choices

[Markus Holtermann]

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 simplify the Fields API more and do this:

class Card(models.Model):
suit = models.IntegerField(choices=Suit)

Cheers,

/Markus

On Sat, Apr 13, 2019, at 11:33 AM, Shai Berger wrote:
> 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 implementation -- because it isn't the enum value that
> we make translatable, but rather an attribute on it.
> 
> I should point that the suggested implementation uses IntEnum and
> StrEnum. The Python documentation recommends against using these,
> except in the case that one needs to account for compatibility with an
> existing protocol -- which, I submit to you, is exactly our case (the
> "protocol" being the types available for database fields).
> 
> As a reminder, the relevant links are:
> 
> https://code.djangoproject.com/ticket/27910
> https://github.com/django/django/compare/master...shaib:ticket_27910?expand=1
> 
> Thanks,
>   Shai.
> 
> -- 
> You received this message because you are subscribed to the Google 
> Groups "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send 
> an email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/20190413113323.1342ed7d.shai%40platonix.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e86e12b7-2ee0-4585-ad69-4e22613f0128%40www.fastmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: 2020 Authentication Initiativ

[Florian Apolloner]

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 because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/cc523e73-27f7-4942-acbf-4f2c6fcdee51%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 2020 Authentication Initiativ

[Florian Apolloner]

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 your code shows it 
is quite easy. I think the goal here should be to allow second factor 
authentication via webauth etc -- ie anything that is multistep. I am not 
surprised that email login works easily, it is a single step process after 
all…

I published my work just now, https://django-mail-auth.rtfd.io. I would 
> recommend to have a look at the custom EmailUser 
> 
>  that 
> I built. There are a couple of functions and fields that need to be 
> overridden. BUT to my surprise even the management command 
> “createsuperuser” worked.
>

You could have reused https://github.com/aaugustin/django-sesame for the 
signing stuff :)

Cheers,
Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/27a3e378-09ea-45dd-80e7-f496bcd4ea1c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request to reconsider ticket #27910: using an Enum class in model Field choices

[Shai Berger]

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 implementation -- because it isn't the enum value that
we make translatable, but rather an attribute on it.

I should point that the suggested implementation uses IntEnum and
StrEnum. The Python documentation recommends against using these,
except in the case that one needs to account for compatibility with an
existing protocol -- which, I submit to you, is exactly our case (the
"protocol" being the types available for database fields).

As a reminder, the relevant links are:

https://code.djangoproject.com/ticket/27910
https://github.com/django/django/compare/master...shaib:ticket_27910?expand=1

Thanks,
Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20190413113323.1342ed7d.shai%40platonix.com.
For more options, visit https://groups.google.com/d/optout.