Re: Proposal to add a flatten() to django.utils

[Markus Holtermann]

Hi David,

I think, I'm in support for a django.utilsflatten() function with the 
requirements / constraints you outlined below.

Cheers,

Markus

On Mon, Oct 17, 2022, at 8:31 AM, David Sanders wrote:
> Hi folks,
> 
> As part of PR 16175  there was 
> some discussion around flattening lists/tuples as part of the solution. I 
> proposed that if we create a flattening function that there'd be some benefit 
> in sharing that in django.utils for other components if needed.
> 
> I'd like to garner "approval" + any thoughts on the best way to write such a 
> function.
>  * I'm aware that django.db expressions have similar-ish flatten() methods
>  * The PR author, Ion Alberdi, has done some nice work in writing up 
> alternatives and measuring performance
>  * A generator based solution would be nice if it could finish walking early 
> if used with any()
>  * Opinions on maintainability (readability) vs performance would be great
>  * Ideally I think it would be great if someone with some experience with 
> performant Python could chime in
> Cheers,
> David
> 
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CADyZw-5iwZPtsuw4Z%3D8nP16K%3DnP-0EAD5wZ4WaNy40L5oYuzfw%40mail.gmail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a16146bd-41ba-4c8d-aabf-62825a782328%40betaapp.fastmail.com.

Re: Preparing Django code for the Black stable release

[Markus Holtermann]

That's wonderful news. Thanks for the info, Paolo!

Cheers,

Markus

On Sat, Jan 29, 2022, at 10:24 PM, Paolo Melchiorre wrote:
> Hi all,
>
> Black 22.1.0 has just been released
> https://github.com/psf/black/releases/tag/22.1.0
>
> It seems the time has come to put DEP 0008 into practice and "run
> Black on the entire Django code repository and make a single commit".
>
> Ciao,
> Paolo
>
> On Wed, Oct 20, 2021 at 10:52 PM Paolo Melchiorre  
> wrote:
>>
>> On Wed, Oct 20, 2021, 21:51 Mariusz Felisiak  
>> wrote:
>>>
>>>
 I was thinking we can start right now using black in a branch and see 
 which issue will show up and start fixing them.
>>>
>>>
>>> We don't want to merge multiple commits related to black. According to the 
>>> "Implementation" section in DEP 0008, we're going to run Black on the 
>>> entire Django code repository and make a single commit. Running black 
>>> should not encounter any issues …
>>
>>
>> Okay, I also hope the migration to Black will be this smooth.
>>
>> So now we just have to wait for 2022.
>>
>> Ciao,
>> Paolo
>>
>>
>
>
> -- 
> Paolo Melchiorre
>
> https://www.paulox.net
>
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAKFO%2Bx6dZAw7ftsGvJOV5crHazXLW4RST_t26JDHFcqA1uNXEA%40mail.gmail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/18da12b4-75f0-4f48-a9e5-1fbde5caa0e6%40beta.fastmail.com.

Re: Preparing Django code for the Black stable release

[Markus Holtermann]

There is https://github.com/MarkusH/django-migrations-formatter which I think 
holds everything that's necessary to make the migration writer create 
black-formatted output.

Cheers, Markus

On Wed, Oct 20, 2021, at 11:11 AM, 'Adam Johnson' via Django developers  
(Contributions to Django itself) wrote:
> The extension I added to the DEP may be a bit involved:
>
>> All code Django generates will also be Black-formatted (startproject,
>> migrations, inspectdb, etc.), at least if the user has Black installed.
>>
> But then again it may only need a few calls to black.format_str() in the
> right places.
>
> On Wed, 20 Oct 2021 at 10:37, Mariusz Felisiak 
> wrote:
>
>>
>> As you can see from this pull request in the Black code the first stable
>>> release is expected for January 2022:
>>> https://github.com/psf/black/pull/2529
>>>
>>> I think we can start prepare this great migrations of the Django code so
>>> we will be ready when Black 22.0 will be released and we can finally
>>> benefit from this change.
>>>
>>> We have now more than 2 months to work on this.
>>>
>>
>> Hi
>>
>> Do you have any specific steps in mind? I'm not sure how we need to
>> prepare. Implementation, as described in DEP 0008
>> ,
>> should be rather straightforward and I don't think anything needs to be
>> done in advance. We (Fellows and OPS team) should be able to implement it
>> within a few days.
>>
>> Best,
>> Mariusz
>>
>> --
>> 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 view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/81687d6f-2ea3-44b4-a9c8-fab71e4e0843n%40googlegroups.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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAMyDDM0kbb2aF%2BMK0GObXFm6pVrt%3DWMLsX1TcK6QyEHpDVBjeg%40mail.gmail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/07f0f742-c503-4f8b-81b4-33bda7f937bf%40beta.fastmail.com.

Re: Proposal for a transaction.on_before_commit

[Markus Holtermann]

Hi Raphael,

This is funny. Just last week I looked into exactly the same thing for audit 
logging as well. Except that I'm writing multiple audit log events and want to 
batch them at the end of the transaction in a single bulk_create operation 
instead of a dozen save() calls.

I haven't gotten anywhere for now. But was considering the thread local 
approach as well. But then, thread locals and Django are not the nicest 
combination.

Maybe we can come up with an approach together?

Cheers

Markus

On Sun, Oct 10, 2021, at 3:55 PM, Raphael Michel wrote:
> Hi everyone,
>
> I've spent some days thinking about a use case we have internally where
> we want to create some database records automatically based on some
> other records, think e.g. of an audit log where whenever an instance of
> model X is changed, we want to create an instance of model Y as a log
> record. Of course, there are *lots* of ways and libraries that allow you
> to do this with Django, mostly somehow circling around overriding
> `save()` or using the `post_save` signal.
>
> However, we want to do this in an *aggregated* way, i.e. even if you
> add hundreds of model instances in the same transaction, we only want
> *one* new line in our audit log to be created. This is impossible with
> `save()` or `post_save` alone since we can't know which change is the
> "last" that should trigger the audit log to be created.
>
> I figured a perfect way to do this would be using `save()` or
> `post_save` to add the changed model instance to some kind of
> thread-local list, and then using `transaction.on_commit` to "schedule"
> the aggregation and create the log entries when all changes have been
> made. However, this obviously is not a good enough because `on_commit`
> runs *after* the `COMMIT` statement and thus we're not guaranteed that
> all log entries are persisted to the database.
>
> So I was wondering if there was potential for a
> `transaction.on_before_commit` that works just like
> `transaction.on_commit` except that it is executed before the `COMMIT`
> statement. I imagine there are lots of other possible uses as well and
> without looking into it much deeper, it seems easy enough to implement.
>
> Does anyone have opinions on whether or not this would be a good
> feature to add to Django? Unfortunately it doesn't seem possible to do
> this as third-party code (except if we were shipping entire database
> backends) so it would need to be an acceptable change to Django to be a
> viable option.
>
> Thanks
> Raphael
>
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/20211010155522.6489b86d%40amara.localdomain.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6cd73b6f-d445-4706-b42a-276ae99213d1%40beta.fastmail.com.

Re: RSS access to Google groups?

[Markus Holtermann]

Hi Claude,

I think you're receiving everything because you're a moderator everywhere and 
they get everything they're moderating by default. I'd need to look into this a 
bit more. But I think there's a way to disable excess notifications.

Cheers,

Markus

On Fri, Aug 13, 2021, at 10:53 PM, Claude Paroz wrote:
> So I activated mailing list mode, and chose i18n/geodjango in the watch 
> list. I'm still receiving all forum messages by email, which is 
> evidently not an option. If I have to manually mute/exclude all other 
> categories, it will not be very practical either, as I would have to do 
> it again each time new topics appear. Any other "magical" solution ? 
> 
> Le vendredi 13 août 2021 à 18:57:16 UTC+2, carlton...@gmail.com a écrit :
> > Hey Claude. 
> > 
> > Here: 
> > 
> > https://forum.djangoproject.com/my/preferences/categories
> > 
> > You can set to watch particular categories (or just first posts in a thread 
> > or … ) 
> > 
> > C. 
> > 
> >> On 13 Aug 2021, at 18:24, Claude Paroz  wrote:
> >> 
> >> A question received privately: imagine someone wants to follow the 
> >> Internationalization topic by email, is it possible and how? There is a 
> >> Mailing list mode in the forum prefs, but then I guess that this will send 
> >> messages from all forum topics.
> >> 
> >> -- 
> >> 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-develop...@googlegroups.com.
> >> To view this discussion on the web visit 
> >> https://groups.google.com/d/msgid/django-developers/d9fb0ba1-3dd9-47d9-9fb6-5cd1a633788cn%40googlegroups.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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/5464cff4-d6ef-4b35-851c-e081359b4738n%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0d0cbd91-09f3-437d-a84b-5c2125787544%40beta.fastmail.com.

Re: The certificate for code.djangoproject.com expired on 7/4/2021.

[Markus Holtermann]

We had some intermittent connection issues over the last couple of hours: 
https://status.djangoproject.com/.  All should be fine again.

Cheers

On Sun, Jul 4, 2021, at 4:14 PM, chris.j...@gmail.com wrote:
> Maybe someone can file an issue about it to address the same thing 
> happening in the future. Perhaps here: 
> https://github.com/django/code.djangoproject.com/issues
> 
> --Chris
> 
> On Sunday, July 4, 2021 at 9:14:20 AM UTC-4 Jason Johns wrote:
> > Ahh, I see the issue.
> > 
> > This screenshot is for Summer of Code 2021, at 
> > https://code.djangoproject.com/wiki/SummerOfCode2021.  You can see the cert 
> > is not valid before 0431 eastern
> > 
> > Screen Shot 2021-07-04 at 9.10.01 AM.png
> > 
> > This screenshot is for https://docs.djangoproject.com/en/3.2/:
> > 
> > Screen Shot 2021-07-04 at 9.09.14 AM.png
> > 
> > Looks like the SoC URL cert didn't get applied before this morning, and 
> > users who tried to access that URL would have gotten Certificate Expired 
> > errors.
> > On Sunday, July 4, 2021 at 9:07:55 AM UTC-4 Jason Johns wrote:
> >> FWIW, a user at pyslackers said they got a 503 about the same time about 
> >> 50 minutes after Asif's initial message.  Then about two hours later 
> >> (about an hour before Adam's reply), someone else responded that they 
> >> weren't able to replicate.  Maybe there was a delay in applying the cert 
> >> rotation?  I'm not able to easily see when the cert was generated.
> >> 
> >> On Sunday, July 4, 2021 at 5:38:01 AM UTC-4 Adam Johnson wrote:
> >>> Hi Asif
> >>> 
> >>> I'm not seeing a problem - the certificate I get expires in October.
> >>> 
> >>> Screenshot 2021-07-04 at 10.36.15.png
> >>> 
> >>> Thanks,
> >>> 
> >>> Adam
> >>> 
> >>> On Sun, 4 Jul 2021 at 06:34, Asif Saif Uddin  wrote:
>  
>  Websites prove their identity via certificates, which are valid for a 
>  set time period. The certificate for code.djangoproject.com expired on 
>  7/4/2021.
>   
>  Error code: SEC_ERROR_EXPIRED_CERTIFICATE
>   
>  View Certificate
>  
>  https://code.djangoproject.com/wiki/SummerOfCode2021
>  
>  Asif
>  
>  -- 
>  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-develop...@googlegroups.com.
>  To view this discussion on the web visit 
>  https://groups.google.com/d/msgid/django-developers/539fc003-f4de-4dae-8ace-d5103c19f44en%40googlegroups.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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/4ab92cf4-04e0-4e30-a088-ec13ce3bc3d9n%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/081140f7-e09a-4c6c-b31d-c1a17320b976%40beta.fastmail.com.

Re: Default change password UX: area for improvements

[Markus Holtermann]

Hi Federico,

this is a good idea. Could you check if there's a ticket about this on 
https://code.djangoproject.com/ already, and if not, possibly open one. That 
would be much appreciated. Thank you!

Cheers,

Markus

On Mon, Jun 7, 2021, at 11:12 PM, Federico Capoano wrote:
> Hey everyone,
> 
> Given the following text in the user change page:
> 
> *Raw passwords are not stored, so there is no way to see this user’s 
> password, but you can change the password using this form.*
> *
> *
> Linking the change user password form using the word "this form" is on 
> the same level of links with "click here", which is notoriously bad UX 
> and I believe the django community is made of a lot of experts so there 
> shouldn't be the need to explain this here.
> 
> However, we can do better than just changing the link form, wouldn't it 
> be possible to add a link styled as a button?
> 
> Eg:
> 
> Raw passwords are not stored, so there is no way to see this user’s 
> password, but the password can be changed.
> 
> *Change the password*
> 
> BTW, this idea came from this issue: 
> https://github.com/openwisp/openwisp-radius/issues/265.
> We can easily fix it in our django app but I thought it may be good to 
> raise this here so we may fix it at the root instead.
> 
> Best regards
> Federico Capoano
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAERYH6VUm-bRsHkY_1LX9TwpJvMW%2B-Eyqf0Uye6FL%2B_Pb_%3D%2BQw%40mail.gmail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c73670f4-9324-467b-9861-48fff9eb326a%40www.fastmail.com.

Re: Proposal to add attribute 'step' to FloatField and DecimalField

[Markus Holtermann]

Hi Jacob,

That sounds like a sensible feature. Do you want to open a ticket and maybe 
implement it?

Cheers

Markus

On Wed, Mar 17, 2021, at 12:45 AM, Jacob Rief wrote:
> If someone wants to use the step attribute as provided by the HTML field
>  , she/he has to specify that using for instance
> FloatField(widget=NumberInput(attrs={'step': 0.5})).
> 
> Since the HTML standard offers a step attribute on input fields of type 
> number,
> from my point of view, this feature shall be reflected by Django's 
> FloatField and 
> optionally DecimalField rather than having to parametrize the widget.
> 
> Min- and max-values are already supported by the FloatField, so the step-value
> would make sense here as well. It furthermore would require to revalidate the
> step-value by Django's Form validation, rather than by HTML alone.
> 
> – Jacob
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/9a35aa63-0d22-4353-8f58-70a181e05791n%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/35ea5249-6c7d-44c6-8171-0730e0a660bd%40beta.fastmail.com.

Re: The blacklist / master issue

[Markus Holtermann]

Hi all,

Mariusz renamed the branches this morning and merged the corresponding pull 
requests. Thank you!

Please let us know if you spot problems so they can be fixed.

Cheers,

Markus

On Tue, Mar 2, 2021, at 6:05 PM, Markus Holtermann wrote:
> Brief update on this.
> 
> The overall tracking pull request ist 
> https://github.com/django/django/pull/14048/
> 
> * On 2021-03-03 at UTC morning, well migrate 
> django/code.djangoproject.com and django/djangoproject.com
> 
> * Likely on 2021-03-09 we'll migrate django/django
> 
> Cheers,
> 
> Markus
> 
> On Thu, Feb 25, 2021, at 7:31 PM, Markus Holtermann wrote:
> > Thanks for the input, Matthias. That's useful to know. I'll make sure 
> > the change is announced.
> > 
> > Cheers,
> > 
> > Markus
> > 
> > On Thu, Feb 25, 2021, at 7:24 PM, Matthias Kestenholz wrote:
> > > Yes, please.
> > > 
> > > As a third party app developer I'll have to update a few GitHub 
> > > workflows and tox configurations (since I'm running testsuites against 
> > > the main branch too). It may be useful to announce this change on as 
> > > many channels as possible (mailing lists, the forum, as a news entry on 
> > > the Django website). Just an idea, this shouldn't be a blocker for 
> > > moving forward with this.
> > > 
> > > Thanks,
> > > Matthias
> > > 
> > > 
> > > On 24/02/2021 00:12, 'Adam Johnson' via Django developers (Contributions 
> > > to Django itself) wrote:
> > > > Yes, let's do it. I did it to my open source projects a couple weeks 
> > > > ago 
> > > > and everything has been smooth since. We'll need some find/replace for 
> > > > links in the main repo, on djangoproject.com 
> > > > <http://djangoproject.com>, 
> > > > and I imagine some other places.
> > > > 
> > > > On Tue, 23 Feb 2021 at 22:15, Kenneth  > > > <mailto:kennethl...@gmail.com>> wrote:
> > > > 
> > > > I agree. We should go ahead and do the switch
> > > > 
> > > > On Tue, Feb 23, 2021 at 11:57 AM Markus Holtermann
> > > > mailto:i...@markusholtermann.eu>> wrote:
> > > > 
> > > > Hi all,
> > > > 
> > > > Reviving an old topic. GitHub has by now tooling in place to
> > > > rename branches and keep open PRs in sync. In fact, if I were to
> > > > change the `master` branch to `main`, GitHub tells me this:
> > > > 
> > > > Renaming this branch:
> > > > * Will update 158 pull requests targeting this branch across 112
> > > > repositories.
> > > > * Will update 1 branch protection rule that explicitly targets
> > > > master.
> > > > * Will not update your members' local environments.
> > > > 
> > > > I'd suggest to go through with this change and make the
> > > > necessary changes to the CI / website.
> > > > 
> > > > Cheers,
> > > > 
> > > > Markus
> > > > 
> > > > 
> > > > On Tue, Jun 23, 2020, at 11:04 AM, Mark Bailey wrote:
> > > >  > +1 on a good decision to make this change.
> > > >  >
> > > 
> > > -- 
> > > 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 view this discussion on the web visit 
> > > https://groups.google.com/d/msgid/django-developers/81446dcd-e04c-3c28-91b5-a276a38baaf7%40feinheit.ch.
> > >
> > 
> > -- 
> > 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 view this discussion on the web visit 
> > https://groups.google.com/d/msgid/django-developers/8caebe33-6b52-46f7-8f7b-b324474a546b%40www.fastmail.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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/dd0f1e1a-3e6b-4202-8c55-f0741b35f88e%40www.fastmail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6eadf150-3208-4300-bedb-c2b615e023f2%40www.fastmail.com.

Re: The blacklist / master issue

[Markus Holtermann]

Brief update on this.

The overall tracking pull request ist 
https://github.com/django/django/pull/14048/

* On 2021-03-03 at UTC morning, well migrate django/code.djangoproject.com and 
django/djangoproject.com

* Likely on 2021-03-09 we'll migrate django/django

Cheers,

Markus

On Thu, Feb 25, 2021, at 7:31 PM, Markus Holtermann wrote:
> Thanks for the input, Matthias. That's useful to know. I'll make sure 
> the change is announced.
> 
> Cheers,
> 
> Markus
> 
> On Thu, Feb 25, 2021, at 7:24 PM, Matthias Kestenholz wrote:
> > Yes, please.
> > 
> > As a third party app developer I'll have to update a few GitHub 
> > workflows and tox configurations (since I'm running testsuites against 
> > the main branch too). It may be useful to announce this change on as 
> > many channels as possible (mailing lists, the forum, as a news entry on 
> > the Django website). Just an idea, this shouldn't be a blocker for 
> > moving forward with this.
> > 
> > Thanks,
> > Matthias
> > 
> > 
> > On 24/02/2021 00:12, 'Adam Johnson' via Django developers (Contributions 
> > to Django itself) wrote:
> > > Yes, let's do it. I did it to my open source projects a couple weeks ago 
> > > and everything has been smooth since. We'll need some find/replace for 
> > > links in the main repo, on djangoproject.com <http://djangoproject.com>, 
> > > and I imagine some other places.
> > > 
> > > On Tue, 23 Feb 2021 at 22:15, Kenneth  > > <mailto:kennethl...@gmail.com>> wrote:
> > > 
> > > I agree. We should go ahead and do the switch
> > > 
> > > On Tue, Feb 23, 2021 at 11:57 AM Markus Holtermann
> > > mailto:i...@markusholtermann.eu>> wrote:
> > > 
> > > Hi all,
> > > 
> > > Reviving an old topic. GitHub has by now tooling in place to
> > > rename branches and keep open PRs in sync. In fact, if I were to
> > > change the `master` branch to `main`, GitHub tells me this:
> > > 
> > > Renaming this branch:
> > > * Will update 158 pull requests targeting this branch across 112
> > > repositories.
> > > * Will update 1 branch protection rule that explicitly targets
> > > master.
> > > * Will not update your members' local environments.
> > > 
> > > I'd suggest to go through with this change and make the
> > > necessary changes to the CI / website.
> > > 
> > > Cheers,
> > > 
> > > Markus
> > > 
> > > 
> > > On Tue, Jun 23, 2020, at 11:04 AM, Mark Bailey wrote:
> > >  > +1 on a good decision to make this change.
> > >  >
> > 
> > -- 
> > 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 view this discussion on the web visit 
> > https://groups.google.com/d/msgid/django-developers/81446dcd-e04c-3c28-91b5-a276a38baaf7%40feinheit.ch.
> >
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/8caebe33-6b52-46f7-8f7b-b324474a546b%40www.fastmail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/dd0f1e1a-3e6b-4202-8c55-f0741b35f88e%40www.fastmail.com.

Re: The blacklist / master issue

[Markus Holtermann]

Thanks for the input, Matthias. That's useful to know. I'll make sure the 
change is announced.

Cheers,

Markus

On Thu, Feb 25, 2021, at 7:24 PM, Matthias Kestenholz wrote:
> Yes, please.
> 
> As a third party app developer I'll have to update a few GitHub 
> workflows and tox configurations (since I'm running testsuites against 
> the main branch too). It may be useful to announce this change on as 
> many channels as possible (mailing lists, the forum, as a news entry on 
> the Django website). Just an idea, this shouldn't be a blocker for 
> moving forward with this.
> 
> Thanks,
> Matthias
> 
> 
> On 24/02/2021 00:12, 'Adam Johnson' via Django developers (Contributions 
> to Django itself) wrote:
> > Yes, let's do it. I did it to my open source projects a couple weeks ago 
> > and everything has been smooth since. We'll need some find/replace for 
> > links in the main repo, on djangoproject.com <http://djangoproject.com>, 
> > and I imagine some other places.
> > 
> > On Tue, 23 Feb 2021 at 22:15, Kenneth  > <mailto:kennethl...@gmail.com>> wrote:
> > 
> >     I agree. We should go ahead and do the switch
> > 
> > On Tue, Feb 23, 2021 at 11:57 AM Markus Holtermann
> > mailto:i...@markusholtermann.eu>> wrote:
> > 
> > Hi all,
> > 
> > Reviving an old topic. GitHub has by now tooling in place to
> > rename branches and keep open PRs in sync. In fact, if I were to
> > change the `master` branch to `main`, GitHub tells me this:
> > 
> > Renaming this branch:
> > * Will update 158 pull requests targeting this branch across 112
> > repositories.
> > * Will update 1 branch protection rule that explicitly targets
> > master.
> > * Will not update your members' local environments.
> > 
> > I'd suggest to go through with this change and make the
> > necessary changes to the CI / website.
> > 
> > Cheers,
> > 
> > Markus
> > 
> > 
> > On Tue, Jun 23, 2020, at 11:04 AM, Mark Bailey wrote:
> >  > +1 on a good decision to make this change.
> >  >
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/81446dcd-e04c-3c28-91b5-a276a38baaf7%40feinheit.ch.
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8caebe33-6b52-46f7-8f7b-b324474a546b%40www.fastmail.com.

Re: The blacklist / master issue

[Markus Holtermann]

Hi all,

Reviving an old topic. GitHub has by now tooling in place to rename branches 
and keep open PRs in sync. In fact, if I were to change the `master` branch to 
`main`, GitHub tells me this:

Renaming this branch:
* Will update 158 pull requests targeting this branch across 112 repositories.
* Will update 1 branch protection rule that explicitly targets master.
* Will not update your members' local environments. 

I'd suggest to go through with this change and make the necessary changes to 
the CI / website.

Cheers,

Markus


On Tue, Jun 23, 2020, at 11:04 AM, Mark Bailey wrote:
> +1 on a good decision to make this change.
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/1e3d742a-7f38-4258-a5a3-bfb01a333020o%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6fb9c6cc-39a6-4741-9d61-d03a44d9c477%40www.fastmail.com.

Re: Revisiting Python support for after Django 3.2 LTS

[Markus Holtermann]

I think I need to go through all proposed options a few more times to 
understand their differences and implications.

But what about a more pragmatic approach: Django supports the currently 
supported Python versions at any given time. Except for our LTS versions, which 
would never drop support. That means, a Django 2.2 might need to get fix in 
2.2.x to support e.g. Python 3.11. But if Python support for 3.8 is dropped, 
why not drop it from Django' non-LTS versions. Where "drop" is meant as a , we 
won't add fixes to support an old Python version, and we won't add new features 
from a new Python version that's around. But if a new Python version requires a 
fix, let's back port it.

Cheers,

Markus

On Wed, Jan 27, 2021, at 4:22 PM, Carlton Gibson wrote:
> OK... urgh. I don't think there's a perfect answer here. 
> 
> As you say Tim, assuming the "support unless EOL before the Django 
> version's EOL"  we end up dropping the Python version before the LTS, 
> which is going to be just as "premature" as we have now, but for the 
> x.0. 
> 
> If I've not counted wrong (again) the 4.2 LTS, for example, due April 
> 2023, would drop Python 3.8 and 3.9, which have until Oct 2024 and 2025 
> to run. 
> 
> So we'd be trading extra life here for probably more complaints there. 
> 
> I've played around with various variations of the cut-off date without 
> any real ground being made. 
> 
> Thus, we probably need to stick as we are, in the main. 
> 
> A last option would be to say that the x.0 will support one extra older 
> version after the LTS, in cases like this where the otherwise dropped 
> version is supported for the whole lifetime of the x.0 release. 
> 
> That I think would look like this, assuming we backport support for new 
> versions within the mainstream support period: 
> 
> 4.0: 3.7, 3.8, 3.9, 3.10
> 4.1: 3.8, 3.9, 3.10, 3.11
> 4.2 LTS : 3.8, 3.9, 3.10, 3.11, 3.12
> 
> 4.2 is in danger of taking 3.13 as well, but that's released after 4.2 
> leave mainstream support.
> It's akin for what we did for Django 2.2 and Python 3.9
> That's independent of whether we keep support for 3.7 a bit longer. 
> 
> Having looked it through now, I think, fully, that's my final thought. 
> I'd need to think about the __exact wording, but I hope the idea is clear.
> 
> I take Claude's point about contributing but, for me, the desire to 
> support slightly more versions if we can is for beginners, picking up a 
> couple of year old laptop, with SOME version of Python on it, and being 
> able to get going, with hopefully the latest version. I appreciate they 
> can install an older version, but it's hard enough to get started 
> without hitting subtle version changes. I'd like to support that 
> use-case as best we can. 
> 
> The current policy begins, "Typically...". I'd suggest supporting 
> Python 3.7 for Django 4.0 is merely leveraging that. 
> 
> We should decide. I'd be +1 to maintain the current policy but keep 3.7 
> support for Django 4.0, dropping it at Django 4.1. 
> 
> Thanks all, and especially you Tim for taking the time to explain and 
> explore the options. 
> C.
> 
> 
> 
> On Tuesday, 26 January 2021 at 22:00:31 UTC+1 timog...@gmail.com wrote:
> > Looking at this again, I'm not sure it would be six versions. Carlton's 
> > suggested policy has the effect of dropping a lot of Python versions right 
> > before the LTS since it's supported for 3 years. For example, in Django 5.2 
> > LTS, I think it's incorrect that Python 3.10 and 3.11 would be supported 
> > since their support expires in Oct 2026 & 7, before Django 3.2's expiration 
> > in April 2028)? The current policy means we have Django LTS's supporting 
> > some Python's well after they expire. I never liked that aspect of it. 
> > Anyway, the decision won't affect my life.
> > On Tuesday, January 26, 2021 at 5:32:50 AM UTC-5 Mariusz Felisiak wrote:
> >> Hi y'all,
> >> 
> >> I think we should keep the current policy. There is never a good time 
> >> to drop support for anything and extending support especially for Python 
> >> 3.7 will end with more exceptions in the future. Current policy is really 
> >> patronizing and with the new Python release schedule we can reach 6 
> >> supported versions of Python for every LTS. I would make it even more 
> >> aggressive :) It's not only about the maintenance burden but also about 
> >> new features and syntax, we have tickets waiting 2-3 years until Python X 
> >> becomes the minimal Python supported by Django. My 2 cents 路
> >> 
> >> Best,
> >> Mariusz
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/ef691a05-1a1a-434f-bd0c-56b6f5d8a027n%40googlegroups.com
>  

Re: Technical Board Decision Needed: Admin append_slash behaviour.

[Markus Holtermann]

Thanks you for bringing this up, Carlton. And thanks Jon for tackling the 
issues.

I concur with what has been said so far. Especially what James said, that there 
are so many places where one possibly/maybe/theoretically could come up with 
timing attacks. Mitigating the difference in response code behavior (302 vs 
404) seems like a sensible idea.

But adding the append slash behavior to the Admin seems unnecessary. Especially 
given the example Adam brought up. Maybe you want to post that approach on the 
corresponding ticket, Adam, and close it as wontfix?

Cheers,

Markus

On Thu, Jan 7, 2021, at 5:26 PM, Florian Apolloner wrote:
> 
> 
> On Thursday, January 7, 2021 at 2:16:57 PM UTC+1 carlton...@gmail.com wrote:
> > 1. Add the catch-all view to admin to stop the unauthenticated probing, as 
> > per the Security Teams initial idea, but not the AdminSite.append_slash 
> > option.
> > 2. Don't even add the catch-all, and close the ticket as wontfix. 
> 
> I think the catch-all view is certainly a worthwhile addition, it is a 
> low hanging fruit that makes fast probing if auth.user is installed 
> impossible.
> 
> > * It SEEMS to me that the catch-all view does serve it's purpose as as the 
> > AdminSite.admin_view decorator redirects all non-staff requests equally to 
> > login (whether they exist or not, because the catch-all view exists.) This 
> > is prior to any per-view timing variation. (I think )
> 
> Technically you could already mount a timing attack because url 
> resolving is not constant time, the first matching view wins :þ
> 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/03910826-32d4-44c9-a3d5-a35f984c05e7n%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a19773d6-4482-45b6-aaf0-08f08626b398%40www.fastmail.com.

Re: Anonymous access to the forum

[Markus Holtermann]

Thanks Adam. I did set the value to "Anyone on the web" again (it had that 
value already). And since that didn't change anything I went public: 
https://twitter.com/m_holtermann/status/1295635386820157440

What _does_ work, is viewing threads directly, only showing a list of threads 
doesn't work for me as an anonymous user.

Cheers,

Markus

On Tue, Aug 18, 2020, at 10:31 AM, Adam Johnson wrote:
> You're not the only one, I also get redirected to login when visiting 
> the group URL in a "private mode" window: 
> https://groups.google.com/group/django-developers
> 
> I did some research and found there's a "New Google Groups" update. I 
> think this has done it. Links:
>  * Beta announcement post: 
> https://gsuiteupdates.googleblog.com/2020/03/new-google-groups-beta.html
>  * General release post: 
> https://gsuiteupdates.googleblog.com/2020/05/new-google-groups-generally-available.html
>  * List of changes: https://support.google.com/a/answer/9687393 (I 
> couldn't spot anything related to removing anonymous access)
> I checked on another group I'm an admin for and in settings I found 
> "Who can see group" with options "Group members" and "Anyone on the 
> web". Perhaps Google didn't migrate this setting and we need to reset 
> it to "Anyone on the web"? Can one of the admins for django-users and 
> django-developers check?
> 
> On Tue, 18 Aug 2020 at 08:14, Claude Paroz  wrote:
> > Hello,
> > 
> > Am I the only one or did Google closed anonymous access to Google groups?
> > Could it be a setting in the group config?
> > 
> > In my opinion, it is not acceptable for the project if accessing the
> > Django group posts require authentication.
> > 
> > If someone has more information about that change, that would be great.
> > 
> > Claude
> > -- 
> > www.2xlibre.net
> > 
> > -- 
> > 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 view this discussion on the web visit 
> > https://groups.google.com/d/msgid/django-developers/45961852-2b29-e763-23f9-f55aca70e074%402xlibre.net.
> 
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAMyDDM1GgzzLnLx4GSiDfvuEWkdO9TS6Uw0%3DXzkfxso%2BBaaAWg%40mail.gmail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/cd206b2e-d837-4cf0-8416-e0bdfe3d27cc%40www.fastmail.com.

Re: Anonymous access to the forum

[Markus Holtermann]

Thanks for bringing this up, Claude. I'll look into it.

Cheers,

Markus

On Tue, Aug 18, 2020, at 9:14 AM, Claude Paroz wrote:
> Hello,
> 
> Am I the only one or did Google closed anonymous access to Google groups?
> Could it be a setting in the group config?
> 
> In my opinion, it is not acceptable for the project if accessing the
> Django group posts require authentication.
> 
> If someone has more information about that change, that would be great.
> 
> Claude
> -- 
> www.2xlibre.net
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/45961852-2b29-e763-23f9-f55aca70e074%402xlibre.net.
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/40cc7a4a-954f-4b46-8725-0f74aba6c701%40www.fastmail.com.

Re: Set up autolinks on Django's GitHub repositories

[Markus Holtermann]

Hi Sage,

thank you for the suggestion. There's already autolinking setup for 
`ticket-123`. I'm happy to add another one which would be a bit briefer. But if 
this is done, the contribution documentation needs to be updated as well.

/Markus

On Mon, Aug 3, 2020, at 8:06 AM, laym...@gmail.com wrote:
> Hi folks,
> 
> I came across this feature on GitHub today:
> https://docs.github.com/en/github/administering-a-repository/configuring-autolinks-to-reference-external-resources
> 
> In short, it adds autolinks to external resources (e.g. our issue 
> tracker) by referencing them using a prefix in GitHub comments or 
> commits. So, instead of using Markdown to manually link to a ticket, we 
> can just use the prefix followed by the ticket number, e.g. *TR-123* 
> and GitHub will automatically convert it to a link.
> 
> Currently, we use the # character as a convention to refer to the 
> tickets. However, this conflicts with the use of # on GitHub which 
> automatically links to PRs (and issues if enabled). As a result, 
> commits that refer to a ticket whose number is also a valid PR number, 
> incorrectly link to the PR. Here's an example: 
> https://github.com/django/django/commit/5d4b9c1cab03f0d057f0c7751862df0302c65cf9
> 
> As you can see, the commit message links to PR#12990 which actually 
> isn't relevant. This also generates noise in the PR itself: 
> https://github.com/django/django/pull/12990. I think that can be 
> misleading to new contributors.
> 
> By using the autolinks, we can properly link the reference to the 
> tickets. Sadly, we can't replace GitHub's # autolinks. So, we need to 
> create a new prefix. This has some downsides, though:
>  * It breaks the current convention of using # to refer to tickets.
>  * The prefix must only contain letters, numbers, or -:/#
>  * The prefix is 3 characters minimum, so this means commit messages 
> will be at least 2 characters longer than with the current convention.
> However, considering the benefits:
>  * No more incorrect links to irrelevant PRs.
>  * No more noise in PRs from irrelevant commits.
>  * Clickable ticket numbers in commits that take you to the tickets.
>  * Quick linking to tickets in GitHub comments (no need to use 
> Markdown).
>  * Less confusion to new contributors.
> I think it's worth it.
> 
> What do y'all think? If we're to agree upon this, I guess we need to 
> come up with the prefix. I don't have any preference; as long as it 
> makes sense, I'm in.
> 
> Oh, and one more thing: maybe we can also set up a prefix for PRs to 
> easily differentiate between the two from now on. Here are some 
> proposals:
>  * *TR-1234* for TRac tickets, and *PR-5678* for PRs.
>  * *TR#1234* for TRac tickets, and *PR#5678* for PRs.
> And maybe we can set up another for DEPs, but that may not be 
> necessary...
> 
> Regards,
> Sage
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/e070dd97-0d22-4566-a605-867141f7e0aan%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0f9ddf24-b903-4bf1-9b27-bc73353b1957%40www.fastmail.com.

Re: Status of 3.1 release blockers.

[Markus Holtermann]

Can we come up with a way that we have the settings variable around for now, 
only to allow transitioning, and then add it as a proper feature in 3.2.

As for the feature, I think we could choose a path like passlib does: A list of 
2 (n>=1) algorithms. The first one will be used for signing, and all of them 
for verification. We could then limit the set of options to sensible algorithms 
(or put some algorithms on a blocklist, such as md5). But I think that's 
nothing we should add the day before the final release.

Cheers,

Markus

On Mon, Aug 3, 2020, at 8:48 AM, Mariusz Felisiak wrote:
> It seems that adding DEFAULT_HASHING_ALGORITHM setting is an acceptable 
> solution, we have one remaining question: Do we keep the setting around?
>  1. we can treat DEFAULT_HASHING_ALGORITHM as a transitional setting, 
> limit its values to `sha1` and `sha256`, and deprecate it immediately. 
> Florian said: *"From a security perspective I wonder if we should limit 
> this that the existing sha1 and the new sha256 algos. We really don't 
> ever want anyone to put md5 there and it is really just a transitional 
> setting.", "...setting this to sha256, running with it and then 
> changing it to sha512 will be a hard cut. There will be no migration 
> path like there would be for sha1. Imo that limits the usefulness of 
> such a setting for long term usage and makes it questionable if we want 
> to support such usage."*
>  2. we can treat DEFAULT_HASHING_ALGORITHM as a new feature and allows 
> any secure hash algorithm supported by hashlib. Simon said: *"**It does 
> add one more setting but it feels like having this configurable project 
> wide will be a plus as it will allow the ecosystem to rely on it and 
> hopefully make audit of large Django application a bit easier when 
> having specific hashing requirements.".*
> Personally I think we should choose the first option because it's 
> safer. 
> 
> *We're delaying the 3.1 release until tomorrow.*
> 
> Best,
> Mariusz
> 
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/023a0518-a58c-48c6-8b36-9d5fb7a7c108n%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/17636c67-cdb5-4cf9-bb95-b10b8cc0885d%40www.fastmail.com.

Re: Status of 3.1 release blockers.

[Markus Holtermann]

No, it won't move the problem to 3.2. The problem is that 3.0 only knows about 
sha1. 3.1 and later know about sha1 and sha256. Meaning, any >=3.1,<4.0 version 
can decode and verify signed data from 4.0 and before.

Cheers

Markus
 
On Fri, Jul 31, 2020, at 12:08 PM, Raffaele Salmaso wrote:
> On Fri, Jul 31, 2020 at 11:47 AM Carlton Gibson 
>  wrote:
> > Add the new setting default to sha1.
> > Raise a DeprecationWarning unless it’s set to sha256 (so folks can opt-in 
> > to the future.)
> > Remove setting, and change default to sha256, when 4.0?
> > 
> > Does that sound right? (Grrr.)
> I think this just move the migration problem from 3.2 to 4.0. 
> What about the other way: add a migration setting set to new algorithm, 
> so who really need sha1 can opt-in to old algorithm?
> 
> -- 
> | Raffaele Salmaso
> | https://salmaso.org
> | https://bitbucket.org/rsalmaso
> | https://github.com/rsalmaso
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CABgH4Jt0xXzXrFO8vAFFbF_zabF6xhFGnnTS1rJi_iWAT9fJRg%40mail.gmail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1b35a40d-c3e3-4aab-a856-078f2efad7c4%40beta.fastmail.com.

Re: Status of 3.1 release blockers.

[Markus Holtermann]

Thank you for summarizing our IRC discussion, Mariusz. To be clear, the problem 
occurs during the upgrade process where more than 1 server is involved. That 
might be the case in small deployments with just 2 servers, where the time of 
two Django versions running simultaneously is likely small, or on huge 
deployments of the course of days or weeks, when a staged rollout occurs.

Cheers, Markus

On Fri, Jul 31, 2020, at 11:28 AM, Mariusz Felisiak wrote:
> Markus reported a release blocker #31842 
>  related with running an 
> app on multiple servers with different versions of Django (3.0.x or 
> 3.1). Signatures created on servers with Django 3.1 are not valid on 
> Django 3.0, it's not only about signing.loads()/dumps but also about 
> sessions etc. (see #27468 
> ). We have several 
> possible approaches:
>  * revert commits related with #27468,
>  * change the default hashing algorithm to SHA-1,
>  * add the new setting for the default hashing algorithm,
>  * add the "algorithm" parameter to signing.dumps()/loads() (PR13260 
> ) and ignore the rest of 
> the problem (it's probably not an option),
>  * add the new setting "MIN_DJANGO_VERSION" and change the default 
> hashing algorithm if it's 3.0 or less.
>  * ... (ideas are welcome)
> Best,
> Mariusz
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/2a3d706d-6f78-406e-b7a9-3bba3ea9b7e6n%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d8d56bc4-98a4-460b-ac8c-3b194b11daa4%40beta.fastmail.com.

Re: f-strings again.

[Markus Holtermann]

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 vulnerability vectors 
are fairly small. Hence:

+1 to allow them in PRs that add new code or adjust existing code
-1 on PRs who's primary focus is to change either % or .format() to use 
f-strings

/Markus

On Tue, Jul 21, 2020, at 11:24 AM, Tom Carrick wrote:
> 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 is interpolated in the 
> code or if they're placeholders for sql params or logging calls. But I 
> don't see a reason to change any of the current ones because of that.
> 
> Cheers,
> Tom
> 
> On Tue, 21 Jul 2020 at 10:55, Dave Vernon  wrote:
> > +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 authorised.  Any liability (in 
> > negligence, contract or otherwise) arising from any third party taking any 
> > action or refraining from taking any action on the basis of any of the 
> > information contained in this E-Mail is hereby excluded to the fullest 
> > extent of the law.  In the event that you are not the addressee, please 
> > notify the sender immediately.  Do not discuss, disclose the contents to 
> > any person or store or copy the information in any medium or use it for any 
> > purpose whatsoever.*
> > 
> > 
> > 
> > 
> > On Tue, 21 Jul 2020 at 09:43, Nick Pope  wrote:
> >> 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 replacing .format() with f-strings on a 
> >> case-by-case basis, however, where performance is a concern.
> >> 
> >> Thanks for your initial documentation, Carlton. Am wondering whether we 
> >> should be more explicit about the pros and cons of each to help people 
> >> make the correct decision? Here are my thoughts:
> >> 
> >> %-formatting:
> >> 
> >> + Simple to use printf-style familiar to all.
> >> + Default (can be changed 
> >> ) 
> >> style used internally by the logging module, e.g. logging.info('Message 
> >> with %s.', value)
> >> − Much less flexibility for formatting, see pyformat.info.
> >> 
> >> ``.format()``:
> >> 
> >> + Useful for interpolating a stored template string, e.g. from a database, 
> >> which isn't possible with f-strings.
> >> − Worst performance due to method call.
> >> − Much more verbose, makes code less readable.
> >> 
> >> f-strings:
> >> 
> >> + Better performance than other methods due to dedicated FORMAT_VALUE 
> >>  opcode.
> >> + Allows for embedding more complex expressions, e.g. f'Hello 
> >> {user.get_full_name()}'
> >> + Much more concise, makes code more readable.
> >> − Cannot be used if string must be translated.
> >> − Complex expressions can get out of control. A sensible balance needs to 
> >> be struck.
> >> 
> >> Regarding performance, here are some simple numbers:
> >> 
> >> python -m timeit -s 'x="test"' 'f"{x}"'
> >> 2000 loops, best of 5: 11.8 nsec per loop
> >> $ python -m timeit -s 'x="test"' '"%s" % x'
> >> 1000 loops, best of 5: 39.1 nsec per loop
> >> $ python -m timeit -s 'x="test"' '"{}".format(x)'
> >> 500 loops, best of 5: 76.1 nsec per loop
> >> 
> >> I think it is probably also worth updating the documentation added in this 
> >> commit 
> >> .
> >>  It isn't that xgettext doesn't support f-strings... It does:
> >> 
> >> $ echo "_('Hello %s') % user.username" | xgettext --language=python 
> >> --omit-header --output=- -
> >> #: standard input:1
> >> #, python-format
> >> msgid "Hello %s"
> >> msgstr ""
> >> $ echo "_('Hello {}').format(user.username)" | xgettext --language=python 
> >> --omit-header --output=- -
> >> #: standard input:1
> >> msgid "Hello {}"
> >> msgstr ""
> >> $ echo "_('Hello {name}').format(name=user.username)" | xgettext 
> >> --language=python --omit-header --output=- -
> >> #: standard input:1
> >> #, python-brace-format
> >> msgid "Hello {name}"
> >> msgstr ""

Re: The blacklist / master issue

[Markus Holtermann]

First things first:

I'm glad, Django changed master/slave and blacklist/whitelist to more 
appropriate and adequate terms. Naming things is hard. And just because 
somebody came up with a name decades ago doesn't mean it can't — or even 
shouldn't — be changed. Especially when there are more descriptive alternatives.

I'm glad, Django is in the position to take a stance for a more inclusive 
language in technology and against decades old, racist, terminology.

I'm glad, Django, as several other software projects out there, picked up on 
the Black Lives Matter protests happening in the US and around the globe.

I'm glad, Django has a Code of Conduct 
(https://www.djangoproject.com/conduct/) and a community where racist behavior 
is not tolerated.

---

Alexander, since you brought up the news, I'm sure you're aware that the 
BlackLivesMatter protests are happening around the globe and are not only in 
the US. Racist behavior exists pretty much everywhere, certainly in the US and 
Germany.

I'm a young, white man, from Germany. I have never experienced any racist 
behavior towards me. But I'm fairly certain that there are plenty of people on 
this list who have.

We're still living in a society where white men are privileged in many ways. If 
I can stand in solidarity and support of black colleagues, friends, and members 
of the Django community, by reexamining and addressing language choices that 
have ugly backgrounds to their history, I'm glad!

Markus

On Sun, Jun 21, 2020, at 10:10 PM, Alexander Lyabah wrote:
>  Daryl, that is very strange, that you bring it here now.
> 
> > One of Django's strengths is that decision making is *not* polluted by one 
> > strong opinion, a whim by a marketing department, or trend-following. 
> 
> renaming whitelist and blacklist is exactly what is in trend right now. 
> I understand that not everybody are following US-news, but if you 
> google "blacklist blm" you will find, how big the trend is, actually.
> 
> Also, thank you sharing those link, but can you plz elaborate more, why 
> do you bring those and what do you what to proof by sharing those 
> links, so when I read those links again, I know on what point I should 
> focus more. 
> 
> Thank you for being involved in this conversation.
> 
>  -- 
>  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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/267f6649-a434-47fb-93c9-880b594d213ao%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/cd9101a8-f93d-4ba7-b6e8-f97f8bc57d3b%40beta.fastmail.com.

Re: The blacklist / master issue

[Markus Holtermann]

I'd be in favor of changing blacklist/whitelist into something that makes 
sense. In many cases, that's going to be context dependent, but often 
blocklist/allowlist will work.

With regards to "master" as the development branch on GitHub, I'd like to pick 
whatever GitHub eventually goes with as a "new default".

Cheers,

Markus

On Mon, Jun 15, 2020, at 9:56 PM, Daniele Procida wrote:
> Tom Carrick wrote:
> 
> >I don't think there is an easy answer here, and I open this can of worms
> >somewhat reluctantly. I do think Luke is correct that we should be
> >concerned with our credibility if we wrongly change this, but I'm also
> >worried about our credibility if we don't.
> 
> There are plenty of black-something terms in English that are both 
> negative and have nothing whatsoever to do with race. The black and the 
> dark are those things that are hidden and sinister, as contrasted with 
> those that are in the light and open to scrutiny (black magic, dark 
> arts, black legs, blackguards, blackmail, etc).
> 
> I think it would look pretty silly to confuse meanings that refer to 
> what's shadowy and obscure with things that have racial overtones, and 
> I think we should steer well clear of that. It's not at all like 
> metaphors such as master/slave. 
> 
> If we made such a change and tried to justify it on the grounds of a 
> connection between race and the word "black" in those terms, we'd be 
> rightly laughed at.
> 
> 1000 neckbeards would immediately come out of the woodwork having done 
> some basic web searches going 'neeer neeer neeer, the Django Software 
> Foundation overflowing with snowflakes who think that "blacklist" means 
> [etc etc etc]', and who has the stomach for that? 
> 
> Even choosing to do it on the basis of the potential for offence seems 
> to be a fairly flimsy argument.
> 
> On the other hand, we can do whatever the hell we like. 
> 
> We don't have to justify anything to anyone. If we want to change words 
> in *our* framework, it's absolutely nobody's business but our own.
> 
> If black members of the DSF or the community are disheartened that the 
> word "black" gets to refer to so many negative things and are bothered 
> when they see them in Django, then that alone is sufficient 
> justification. 
> 
> If we want a reason for changing "blacklist" (or whatever), it's that 
> people in our community said they would feel better about it and asked 
> to have it changed. 
> 
> Acknowledging how someone feels about something and acting because you 
> care about their feelings seems to be a respectful thing to do.
> 
> "We did it because we felt like it" is an utterly unanswerable justification.
> 
> The DSF has credibility because the software is first rate, the 
> foundation is well-governed and the community is an international 
> example of decency and kindness. Things like this become credible 
> because the DSF chooses to do them - it's not the other way round.
> 
> Daniele
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/20200615195628.938692561%40mail.gandi.net.
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/64e1b503-289c-4119-acfc-51fe6537addb%40www.fastmail.com.

Re: Unsolicited mentorship requests

[Markus Holtermann]

Interesting. Because I got a similar messages this morning, one on Twitter and 
one on LinkedIn. Here's my response:

> Hi {{ name }}. Thank you for reaching out. Unfortunately, I'm not available 
> for outside help at this time. If you need help working on Django projects 
> would like to suggest the django-users mailing list, the discussion forum, or 
> the IRC channel as documented on djangoproject.com/community/ . If you are 
> looking for mentoring working on Django itself, please use the 
> django-core-mentorship mailing list 
> (https://docs.djangoproject.com/en/dev/internals/mailing-lists/#django-core-mentorship)
>  or the discussion forum. Cheers and stay safe. Markus

Maybe that helps?

Cheers, Markus

On Mon, Jun 8, 2020, at 7:02 PM, Daniele Procida wrote:
> Elena Williams wrote:
> 
> >Just want to bring this up in case it's a "Thing"[tm] now, that I have
> >missed: this last week I've had 3 different non-Australia non-female-
> >presenting individuals who I don't know solicit me privately on social
> >media for personal Django "mentorship". Frankly it's made me feel pretty
> >uncomfortable, but I've never been approached like this so rather than
> >just ruminating I thought I should just ask around if any one is
> >familiar with this happening? It's just several in a short window of
> >time seemed like a weird pattern.
> 
> That seems unusual, to me at least.
> 
> I also get contacted regularly about all kinds of things, but not in 
> such a pattern.
> 
> Is there something off about the tone, or the assumptions?
> 
> One never really knows where one's name has been shared, and what 
> expectations have been formed. I have in the past felt bothered by such 
> things without always being able to put my finger on why.
> 
> Asking for personal mentorship without an introduction or explanation 
> certainly seems a bit weird, and I would not like it either.
> 
> Regards,
> 
> Daniele
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/20200608170210.534891312%40mail.gandi.net.
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3eeb180d-9f36-4d37-b051-93eaebb44337%40www.fastmail.com.

Re: What happens if a Fellow has a holiday?

[Markus Holtermann]

Enjoy your time off. I'll keep my eyes open for PRs.

Cheers,

Markus

On Thu, Jun 4, 2020, at 2:09 PM, charettes wrote:
> Happy to review help as well.
> 
> Enjoy your well deserved time off!
> 
> Le jeudi 4 juin 2020 06:47:57 UTC-4, Carlton Gibson a écrit :
> > Hi all. 
> > 
> > Short answer is we don't really know, since we never take holidays. 
> > 
> > I though am having a much needed week off from tomorrow, to be back on the 
> > 16th. 
> > 
> > Mariusz will need assistance as available *Approving changes*, from Claude 
> > (our third merger) and the Technical Board, who can also Approve PRs. 
> > Mostly that's not needed for contributor PRs, but Mariusz makes a lot of 
> > his *own PRs* as he's working, and those do need approval.
> > Both these points by DEP 10.
> > 
> > To facilitate this I have added the Django Technical Board GitHub team to 
> > the django/django repo, with the non-write "Triage" role. 
> > In this context, mostly this allows Mariusz to ask the TB by team handle 
> > for a review. 
> > (I trust this is OK.) 
> > 
> > 3.1b1 is due on the 15th. We can delay that but... 
> > 
> > Please can I ask the 6 of you to be aware that you might be needed. 
> > Thanks. 
> > 
> > 
> > Kind Regards,
> > 
> > Carlton
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> 
>  -- 
>  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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/b566bbf5-a470-4700-8fed-4b9edc6d7c11%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ad9a8c62-d0ba-4ce3-ab4b-8fde0ba7c594%40www.fastmail.com.

Re: Clear all filters

[Markus Holtermann]

I tend to agree with Adam.

>From a UI/UX perspective, the location where the "Clear all filters" button 
>is, as well as the wording, suggest to me that it's only the filters on the 
>right side. The search query, while technically filtering the query set, 
>doesn't seem like a filter in the UI.

I'd potentially argue otherwise if the search field was in the filter box on 
the right.

Additionally, looking at it from the back-end, search terms and filters have 
nothing in common except for the queryset.

Cheers,

Markus


On Mon, May 18, 2020, at 11:10 AM, Mariusz Felisiak wrote:
> > I disagree Mariusz. I would NOT expect this. The "Clear all filters" button 
> > is grouped with the filters, visually separate from the search and sort 
> > controls. It's a very legitimate use case to clear the filters and maintain 
> > the search or sort, and quite a common workflow when trying to find a 
> > particular object.
> 
> The idea of this feature was to remove all filters and *search 
> criteria* in one click (see the ticket description[2]). The first 
> proposition was to put this link in actions [2], but I proposed moving 
> it to filters. I'm not sure if link for clearing only filters is still 
> necessary (and it wasn't the intention of reporter), we can remove this 
> feature if it's misleading. Link to the right of the search box ("X 
> total") already removes the entire query string, so ...
> 
> > Additionally, I see that the link only preserves the _popup=1 query param. 
> > if users have extended their admin views with any extra query params, they 
> > will also be wiped, which is less than helpful. I know I have extended the 
> > admin with extra params before e.g. to control the queryset.
> 
> Link to the right of the search box ("X total") that was added in 2005 
> [3] do the same. We should probably use `add_preserved_filters`.
> 
> [1] https://code.djangoproject.com/ticket/27888
> [2] https://github.com/django/django/pull/12351#issuecomment-577415747
> [3] 
> https://github.com/django/django/commit/9dda4abee1225db7a7b195b84c915fdd141a7260
> 
>  -- 
>  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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/ed3810c9-bb86-4e05-97dd-4818efa1617c%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a366340a-9b8e-4ac5-9478-10380680de99%40www.fastmail.com.

Re: Django Version 3.2 Roadmap

[Markus Holtermann]

Hi Carlton,

thank you. The proposal looks good to me. +1

Cheers,

Markus

On Wed, May 13, 2020, at 2:51 PM, Carlton Gibson wrote:
> Hi all. 
> 
> I've prepared a draft of the Roadmap for Django 3.2 here: 
> 
> https://code.djangoproject.com/wiki/Version3.2Roadmap
> 
> Following the established release cadence, Django 3.2 will be due in 
> April 2021. 
> 
> The key dates are these. 
> 
> `
> = ==
> January 14, 2021 Django 3.2 alpha; feature freeze.
> 
> February 18 Django 3.2 beta; non-release blocking bug fix freeze.
> 
> March 18 Django 3.2 RC 1; translation string freeze.
> 
> April 1 Django 3.2 final
> = ==
> `
> 
> In accordance with DEP 10, I'd like to ask the Technical Board to 
> review this when able, and approve it or suggest adjustments if needed.
> 
> Thanks. 
> 
> Kind Regards,
> 
> Carlton
> 
> 
> 
> 
>  -- 
>  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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/d19d3303-34aa-4e87-b867-04e7b48f81a5%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/78f612d8-58e6-4f46-b371-c079d503f826%40www.fastmail.com.

Re: Ticket #25236: Remove ifequal from the template language

[Markus Holtermann]

Yes please! Nice catch and followup :)

Cheers,

Markus

On Mon, May 4, 2020, at 4:08 PM, Jon Dufresne wrote:
> Hi,
> 
> I'd like to raise this topic for renewed discussion. I think it is time 
> to begin deprecating the obsolete template tags. So +1 for removal.
> 
> I had all but forgotten about the {% ifequal %} template tag and then 
> eventually stumbled across it doing unrelated work. Upon rediscovering 
> it as a practical duplicate of {% if %}, I thought I'd help out Django 
> by deprecating it for eventual removal so that we're back to "one -- 
> and preferably only one -- obvious way to do it". I created the PR to 
> begin the deprecation here: https://github.com/django/django/pull/12851
> 
> We're now coming up on 10 years since Django 1.2 was released with the 
> smart if template tag. Projects and third party apps have had a 
> generous extended time to update their code.
> 
> For projects that don't follow Django releases in detail, they may not 
> be aware that the {% ifequal %} tag is obsolete and so have not had any 
> motivation to change. Adding a deprecation warning may help such 
> projects to understand they should update their templates.
> 
> For projects that find it is a burden to update, they've had 10 years 
> to do so. I think adding more time isn't what they need at this point. 
> The actual upgrade can be mostly automated with sed (I could even put a 
> recommended command in the release notes). So the update doesn't need 
> to be very time consuming.
> 
> While perhaps we agree leaving old code around can mostly go unnoticed, 
> technical debt has subtle ways of showing up. For example, time was 
> spent by me rediscovering this feature exists and wondering why there 
> are two way to write {% if ... %} (this could happen to other 
> contributors studying the template tag system). Time has been spent on 
> this mailing list discussing what to do with old unused code. Its tests 
> -- which mostly don't matter at this point -- run on every PR and in 
> local environments. If there is ever an attempt at an internal 
> refactoring of the template code, the ifequal tag will need to be 
> considered and maintained. And so on.
> 
> On Sun, Aug 9, 2015 at 12:37 PM Collin Anderson  wrote:
> > Hi All,
> > 
> > I really like the "don't use this on new code, but there's no rush in 
> > replacing it" category. I think that's really important to have that in a 
> > project that's this old. I think it would be great to minimize the amount 
> > required changes that need to be done.
> > 
> > Thanks,
> > Collin
> > 
> 
> >  -- 
> >  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 http://groups.google.com/group/django-developers.
> >  To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/django-developers/2ddf20f1-af1a-47c1-b07c-669818846b53%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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CADhq2b5%3D3A03OjPTGa7mUgm-7braWgJwLUU_xW5pFJrgPP6Uow%40mail.gmail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6f2a7ca0-f223-4b24-8851-5fe37db3e89a%40www.fastmail.com.

Re: [FEATURE] Allow squashmigrations to squash the whole project

[Markus Holtermann]

But for isort one specifies the `known_first_party` and `known_third_party` 
packages. https://github.com/timothycrosley/isort#configuring-isort

At least I was under the impression that that's the only way how it decides 
where to place imports.

Cheers,

Markus

On Tue, Apr 28, 2020, at 9:41 PM, charettes wrote:
> It's notoriously hard to distinguish between first-party and 
> third-party apps but I know some package manage to do it relatively 
> well (e.g. isort).
> 
> Le mardi 28 avril 2020 14:32:13 UTC-4, Javier Buzzi a écrit :
> > To be kind to the user, absolutely! .. any idea on how to implement it O:)
> > 
> >> On Apr 28, 2020, at 2:29 PM, charettes  wrote:
> >> 
> >> Don't we need to prevent that from happening anyway? I guess we'd want to 
> >> prevent --crossapp=auth from working as well.
> >> 
> >> Le mardi 28 avril 2020 13:50:54 UTC-4, Javier Buzzi a écrit :
> >>> To do that we need to know which apps are part of your project, and which 
> >>> are not. Otherwise you'll be squashing "django.contrib.auth" as an 
> >>> example, and you're not going to have a fun time at 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-d...@googlegroups.com.
> >>  To view this discussion on the web visit 
> >> https://groups.google.com/d/msgid/django-developers/ca814e82-9258-40eb-afed-82edb0bc29c8%40googlegroups.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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/8af08a8f-4f4d-4fef-8daa-e3743a1f8468%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3f95c379-9958-4ec9-8a14-aa0243f0ecb8%40www.fastmail.com.

Re: [FEATURE] Allow squashmigrations to squash the whole project

[Markus Holtermann]

Have you considered to allow for multiple app_labels in the `squashmigrations` 
command, maybe together with a `--cross-app` flag, to specify the apps from 
which migrations should be squashed? That way we don't need to rely on paths at 
all, but can log up all migrations in question, based on the provided app 
labels.

Cheers,

Markus

On Tue, Apr 28, 2020, at 2:47 PM, Adam Johnson wrote:
> That's good, but unfortunately BASE_DIR is only a "pseudo setting." 
> It's something in the startproject template that's useful for building 
> file paths but nothing inside Django actually relies on it or checks 
> that it's set. Perhaps we should consider "promoting" it to a real 
> setting though, to make this easier. Still, that might be naive for 
> projects that bundle their dependencies in some way :/
> 
> (Slightly tangential - my post on BASE_DIR and its move to pathlib in 
> 3.1: 
> https://adamj.eu/tech/2020/03/16/use-pathlib-in-your-django-project/ )
> 
> On Tue, 28 Apr 2020 at 13:36, Javier Buzzi  wrote:
> > Correct. Im adding that functionality currently -- im taking the VERY naive 
> > approach of looking at BASE_DIR and if the app is not in there, its foreign 
> > to the project. Some insight or better ideas to this would be appreciated.
> 
> >  -- 
> >  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 view this discussion on the web visit 
> > https://groups.google.com/d/msgid/django-developers/f202a4bb-1d7b-4c85-9695-f4ef3b996c3c%40googlegroups.com
> >  
> > .
> 
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAMyDDM2%3DSTi9pe3LyaYL4%2BLEu8ZcWCgcjynR5MvV30PJiTsoDQ%40mail.gmail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/eaa8b320-15b9-43ab-b50c-3bb6a704898f%40www.fastmail.com.

Re: Generate JWTs with Django

[Markus Holtermann]

Nice work, Claude!

However, dealing with JWTs, and especially verifying them is notoriously hard 
and fragile. Frankly, I think I'd rather see smaller libraries do one job and 
do it well, than having Django implement an incomplete JWT spec. As far as I 
can tell, only HS256 signing/verification is implemented, but nothing else, 
right?

Cheers,

Markus

On Wed, Apr 22, 2020, at 3:38 PM, Adam Johnson wrote:
> Hi Claude
> 
> JWT's are indeed popular for API's. I think if Django was being created 
> "from the ground up" today, JWT's would be a no-brainer to include, so 
> it seems reasonable to add some support.
> 
> I've had a look at the PR, and yes it is indeed a small amount of code 
> - and thanks for the documentation.
> 
> Have you got any data on how often encrypted vs. non-encrypted JWT's 
> are used? Personally I can't remember from the projects I've worked on 
> which format has been used.
> 
> Thanks,
> 
> Adam
> 
> On Wed, 22 Apr 2020 at 09:57, Claude Paroz  wrote:
> > For your information, I now added docs to the tentative patch:
> > 
> > https://github.com/django/django/pull/12728
> > 
> >  Claude
> > 
> >  Le 15.04.20 à 21:26, Claude Paroz a écrit :
> >  > Thanks Abhijeet for the pointer, I know there are some rather complete
> >  > JWT libs around, but my proposal is not about a complete package to
> >  > manage JWT in general.
> >  > It's rather some low level ability for Django to produce and decode
> >  > simple HS256 JWT. Then other third-party libs could build on that
> >  > ability to write more elaborate packages.
> >  > 
> >  > The main doubt I have about my proposal is whether HS256 JWTs are too
> >  > limited for most usages or in the contrary if they are appropriate for a
> >  > fair amount of use cases.
> >  > 
> >  > Claude
> >  > 
> >  > Le 15.04.20 à 21:13, Abhijeet Viswa a écrit :
> >  >> Hi,
> >  >>
> >  >> You might want check out django-restframework-simplejwt. It requires the
> >  >> Django Rest Framework. But, then again, if you are making an API, you'd
> >  >> already be using it.
> >  >>
> >  >> Regards,
> >  >> Abhijeet
> >  >>
> >  >> On Thu, 16 Apr, 2020, 00:39 Claude Paroz,  >  >> > wrote:
> >  >>
> >  >> Hi all,
> >  >>
> >  >> With the recent addition of the algorithm parameter to the
> >  >> signing.Signer class, it's now rather straightforward for Django to
> >  >> generate HS256 (non-encrypted) JSON Web Tokens.
> >  >> With a growing popularity of JS-client/Django server communications
> >  >> (DRF and al.), I think there might be some interest for Django to be
> >  >> able to generate and decode such tokens. For any other types of JWTs
> >  >> which generally require access to a cryptography module, we can
> >  >> point users to third-party libs like PyJWT (the docs should be clear
> >  >> about that).
> >  >>
> >  >> I made a proof-of-concept PR (docs missing) here:
> >  >> - https://github.com/django/django/pull/12728
> >  >>
> >  >> What people here think about that proposal?
> >  >>
> >  >> Claude
> > 
> >  -- 
> >  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 view this discussion on the web visit 
> > https://groups.google.com/d/msgid/django-developers/87ddf575-0756-b99e-51d8-99de1b258c21%402xlibre.net.
> 
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAMyDDM2x%3D%2BB0xM0YRauHxwDDm2ymxeGmYqYCVdOMJS94-F4Xdg%40mail.gmail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/bb569a66-38d5-4165-8da9-fa0cd6a799da%40www.fastmail.com.

Re: Progress report: DEP 10 implementation

[Markus Holtermann]

Thanks for the summary, James.

As one of the IRC group contacts, here's the proposal for what happens to the 
cloaks on Freenode:

- Right now there's a @django/committer/$name cloak. We'd abandon that cloak.

- Instead, every DSF member can apply for a @django/member/$name cloak by 
getting in touch with one of the IRC group contacts (namely apollo13 and 
myself, MarkusH) and pointing them to their name on the DSF member list. I'm 
not entirely sure yet how we would do the verification. Maybe by asking for the 
IRC handle when people become IRC members?

- To ensure we have moderators in place for every #django-* channel we'd also 
introduce the @django/moderator/$name cloak. Each DSF member can apply for that 
cloak. It will give cloak holders "voice" privileges in #django-* channels. One 
needs to show "regular activity" in at least one official channel to become a 
moderator.

- Former @django/committer/$name holders will be migrated to 
@django/member/$name unless they reach out to an IRC group contact before (or 
after, but that's double the work ).

With regards to the #django-core IRC channel, we'll figure out how to delete 
it. People in there, expect to be kicked out .

Cheers,

Markus

On Tue, Apr 21, 2020, at 5:34 AM, James Bennett wrote:
> Last month the process of adopting DEP 10 -- new governance for the
> Django project -- was completed:
> 
> https://www.djangoproject.com/weblog/2020/mar/12/governance/
> 
> As a result, we are now in the implementation stage. Although there
> will almost certainly be other items that pop up on the to-do list,
> here's a quick status update on what has been done so far, and what
> still needs to be done.
> 
> Some of these items require particular permissions; for example, I
> believe I currently have the necessary permissions to handle the PyPI
> configuration change, and I know I have the necessary permissions to
> create a page on djangoproject.com for listing the recipients of the
> initial grant of "Django Core Developer" status, but some others --
> particularly closing mailing lists, and IRC-channel bureaucracy -- I
> don't have access for, so consider this message a call to anyone who
> *does* have those permissions to get in touch and coordinate on
> getting them done.
> 
> 
> * DONE -- Create a Mergers group for the main Django repository
> * DONE -- Remove commit access for the main Django repository from the
> former "Django Core" team
> 
> * IN PROGRESS -- DSF Board develops infrastructure for running a
> Technical Board election
> * IN PROGRESS -- Restrict PyPI package-upload access to Releasers
> * IN PROGRESS -- Add page on djangoproject.com listing recipients of
> "Django Core Developer" title
> * IN PROGRESS -- Update Django documentation to describe DEP 10 governance
> 
> * TODO -- Close django-core mailing list
> * TODO -- Close django-technical-board mailing list
> * TODO -- Close #django-core IRC channel
> * TODO -- Remove or change Django "committer" cloak on Freenode IRC
> * TODO -- DSF Board to create a process for granting "Django Core
> Developer" title beyond initial DEP 10 grant
> * TODO -- First DEP 10 election of Technical Board
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAL13Cg9vj6qGbnR9Zj6inYNsRTv1Orbvn-CkWBmtCFRDoLTxGA%40mail.gmail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0ddfcd81-7495-46c6-973b-47d8c5c3df4d%40www.fastmail.com.

Re: New Merger nomination.

[Markus Holtermann]

I vote in favor of Claude becoming a MERGER.

Cheers,

Markus

On Thu, Apr 16, 2020, at 10:31 PM, charettes wrote:
> I cast my vote in favor of Claude's nomination as well.
> 
> Le jeudi 16 avril 2020 16:16:31 UTC-4, Adam Johnson a écrit :
> > This has fallen by the wayside, let's try restarting.
> > 
> > As Carlton points out, Claude hasn't been merging in code without others 
> > reviewing it. But as I understand it is useful to keep translations moving 
> > that he can merge in his or others' (accepted) PR's. It gets us to the 
> > minimum of three mergers, and Claude has stated he's willing to do his best 
> > in the role of merger. And I hope Claude can help inform us what we can do 
> > to make i18n more smooth.
> > 
> > I nominate Claude as a merger.
> > 
> > Technical board, please post your votes.
> > 
> > On Thu, 19 Mar 2020 at 07:59, Carlton Gibson  wrote:
> >> I don't know if this got blocked in the now-obsolete use of cognates of 
> >> "commit"? 
> >> 
> >> > The Merger role is not just a new name for "committer". If Claude is 
> >> > appointed a Merger, he will be forbidden to do what you are saying -- 
> >> > a Merger cannot push their own contributions directly into Django! 
> >> 
> >> Claude hasn't, and wouldn't, "commit" directly to Django here. He's always 
> >> opened a 
> >> PR with the translations updates, which has then been reviewed, and which 
> >> then, yes, he has 
> >> merged, and forward/backported as necessary — which IS the Merger role. 
> >> (IIUC)
> >> 
> >> In the Merger role, Claude would also be able to approve and Merge other 
> >> PRs. 
> >> 
> >> Beyond this important translations case, we do need a third Merger, and I 
> >> cannot think of a better candidate. 
> >> (The two most active contributors are Claude and Simon, and Simon cannot 
> >> serve as a Merger because of his 
> >> role on the Technical Board.) 
> >> 
> >> I would ask the Technical Board to proceed with the nomination, as, bar 
> >> the loose language, I think it is in line with the DEP. 
> >> 
> >> Kind Regards,
> >> 
> >> Carlton
> >> 
> 
> >>  -- 
> >>  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 view this discussion on the web visit 
> >> https://groups.google.com/d/msgid/django-developers/14af7b19-bcd3-4462-9e25-606f30ff6eda%40googlegroups.com
> >>  
> >> .
> > 
> > 
> > -- 
> > 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/c13e6529-0e75-4e04-8ea6-501982420504%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ce2d7acb-8ad8-4d79-b76b-643499ca745a%40www.fastmail.com.

Re: Technical Board statement on type hints for Django

[Markus Holtermann]

Thanks for pushing this public, Adam. In the discussion I brought up these 
points.

I've been using static typing in Python for about 1.5 years now. Every now and 
then it's neat, but often enough I get annoyed by it. Either because I simply 
don't know how to use the tools at hand correctly or because there's something 
that's just not expressible via type annotations.

The DEP is indeed very much draft. It covers so much, for a rather young setup, 
that at this point, I would not accept it. Everything from it's mention of 
`@overload` is too complex and I'm not sure any of that API is stable enough to 
rely on it in Django.

What I could see Django doing is having type annotations that don't go beyond 
the stdlib support: e.g. `def foo(bar: str) -> Optional[int]` or `def 
foo(instance: models.Model) -> int:`. But far more complex constructs will 
eventually cause breakage and displeasure during development of and with Django.

Often enough at work there's situations where no one can figure out how to 
properly type-annotate something. We then end up with `# type: ignore` or not 
typing a function at all. That's technical dept that we'll hardly ever lose. 
And because it doesn't show up in any CI, it won't cause any issue. But that 
means, we'll eventually have everything type-ignored or heaps of function not 
typed at all. I do not want to see that in Django. If something can't be typed 
or the typing is wrong: `# type: ignore` shouldn't ever be used. At this point, 
I'd instead drop the typing that causes it.

The DEP kind of singles out mypy. As Adam already mentioned, there's about four 
type checkers out there. I wouldn't want Django to pick one and have special 
support for that. Instead, everything that would be special to one of them 
should be developed externally. Especially since these tools iterate quickly 
and change quickly. If a plugin were to be bundled with Django, we'd need to 
support it for 3 years. What when that tool changes the entire API (again, 
young scenery, high velocity).

With regards to the PR Carlton asked about 
(https://github.com/django/django/pull/12405), if that helps people to build 
tooling around Django, let's do it.

Cheers,

Markus

On Fri, Apr 17, 2020, at 11:41 AM, Adam Johnson wrote:
> So we in the technical board were a bit opaque and had our discussion 
> in private before Carlton posted our summary. Apologies for this. We'll 
> repeat the discussion in the open so you can see our reasoning.
> 
> On 4 March Carlton prompted for our input. I replied:
> 
> > My experience using types, so far:
> >  * I'm the author of flake8-no-types, the flake8 plugin for banning type 
> > annotations  I wrote it whilst reviewing a client's code base which had 
> > type annotations, mostly added by PyCharm autocomplete, but no MyPy 
> > running. Running MyPy produced >1k errors. Eventually I actually fixed the 
> > errors rather than stripping the annotations and installing flake8-no-types 
> > - there was thankfully a lot of repetition in the errors.
> >  * I have a vague memory writing one open source PR using types but can't 
> > remember the project.
> >  * I'm a little confused keeping up with the various ways of declaring 
> > types, 'best practices", and which type checkers are out there (last I 
> > heard there are 4!?).
> > I agree that the tools are young, and evolving relatively quickly - both 
> > MyPy and the standard library. I'm not sure there's quite enough stability 
> > yet to roll types out across the whole of Django.
> > 
> > There's the risk that we end up in a chicken/egg stalemate where if no 
> > major Python project commits to being typed, types don't get enough 
> > adoption to progress. But I think there are enough popular projects, like 
> > Starlette, that are using them.
> > 
> > At current it does seem to be a vocal niche of developers who want them.
> > 
> > 
> > Yes it will make PR's harder to review, and definitely adds a barrier to 
> > contribution. Even relatively Pythonic Django-ey constructs like "accept 
> > anything with an as_expression method, or castable to a string" require 
> > quite a lot of type system knowledge to write correctly. On top of this the 
> > best practices seem to still be changing.
> > 
> > 
> > One extra benefit would be a little more clarity around Django API's. For 
> > example, I think a past mistake was allowing database expressions' 'params' 
> > to be *either* a tuple or list, which means casting everywhere (a bug for 
> > years in django-mysql: 
> > https://github.com/adamchainz/django-mysql/pull/558/files ). That said this 
> > is relatively low impact - the documentation often doesn't mention types at 
> > all and Python developers are used to checking things in a REPL.
> > 
> > I think accepting the current PR is okay. [the one for `__class_getitem__` ]
> > 
> > A next step could potentially be experimentally by providing type 
> > annotations in more limited scope projects. One that could work well is 

Re: Proposal to deprecate NullBooleanField (and remove in Django 4.0)

[Markus Holtermann]

Makes sense. We'd have the deprecation shims around for a while anyway.

/Markus

On Tue, Mar 17, 2020, at 11:10 AM, Carlton Gibson wrote:
> Ok, that’s pretty quick and conclusive, so let’s progress. Thanks all. 
> 
> On Tue, 17 Mar 2020 at 11:00, Shrawan Poudel  wrote:
> > +1 from me
> > 
> > On Tue, Mar 17, 2020 at 3:00 PM Adam Johnson  wrote:
> >> +1 from me.
> >> 
> >> On Tue, 17 Mar 2020 at 07:59, Aymeric Augustin 
> >>  wrote:
> >>> Hello,
> >>> 
> >>> I'm inclined to Accept as well.
> >>> 
> >>> -- 
> >>> Aymeric.
> >>> 
> >>> 
> >>> 
>  On 17 Mar 2020, at 08:49, Carlton Gibson  
>  wrote:
>  
>  Hi all. 
>  
>  
>  https://code.djangoproject.com/ticket/31369
>  Proposes to deprecate NullBooleanField. 
>  
>  
>  https://code.djangoproject.com/ticket/29227 
>  Allowed BooleanField to be null=True. 
>  Introduced in Django 2.1. 
>  
>  
>  I'm inclined to Accept. 
>  Wonder if folks consider it a little too fast? 
>  (We could defer for 5.0.) 
>  
>  
>  Kind Regards,
>  
>  Carlton
>  
>  
>   -- 
>   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 view this discussion on the web visit 
>  https://groups.google.com/d/msgid/django-developers/02a4b01d-e47f-4092-826e-c0cfa074901f%40googlegroups.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 view this discussion on the web visit 
> >>> https://groups.google.com/d/msgid/django-developers/6353F843-B61D-4C50-8A45-98DAD860301A%40polytechnique.org
> >>>  
> >>> .
> >> 
> >> 
> >> -- 
> >> 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 view this discussion on the web visit 
> >> https://groups.google.com/d/msgid/django-developers/CAMyDDM3bCYzz3JMCVgXP1%2BmB56CCmTiHmw1ij%3Dbj_5aQSGWaZQ%40mail.gmail.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 view this discussion on the web visit 
> > https://groups.google.com/d/msgid/django-developers/CAPD6JmmfPwGKjQ_Zjet0SENz3Rk26UhfRL9TrpX0Kxo7HdMWtA%40mail.gmail.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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAJwKpyRU95YkyRYbyZi388GB-wx9EMjGOMRQ6-3-exS1s46%3Dyg%40mail.gmail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/02c3cca0-ca87-4b56-a1ca-866b516a5e7d%40www.fastmail.com.

Re: New Merger nomination.

[Markus Holtermann]

Thanks James for summarizing the process. Thanks Mariusz for the suggestion.

Let's make it official, then. I'd like to nominate Claude Paroz 
(https://github.com/claudep) to be a Merger for the Django project and ask my 
fellow Technical Board members to cast their votes.

Claude has been contributing to Django for almost a decade. His roles in i18n 
related matters has been a constant help to the project. Providing Claude with 
commit access to github.com/django/django and giving him the MERGER role will 
allow him to continue his work and maintain an up to date translation base in 
the project, especially in the days leading towards a release.

I vote +1

/Markus 

On Sat, Mar 14, 2020, at 10:05 AM, Claude Paroz wrote:
> Hey! Thanks for suggesting me as a merger!
> 
> However, I'd like to clarify that I'm not requesting this commit bit. 
> If the project thinks it's good that I get it, I'll accept that and do 
> my best to use it as the new DEP suggests. If not, I can certainly 
> continue to contribute as I've done in the past.
> 
> Cheers,
> 
> Claude
> 
>  -- 
>  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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/a3ae8f2e-b6a8-4d93-8c62-954dc1646b3d%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7f64628f-ac87-4992-9663-d651848a18a7%40www.fastmail.com.

Re: Django security releases issued: 3.0.1, 2.2.9, and 1.11.27

[Markus Holtermann]

Thanks for checking and asking!

On Python 2, the email address with "i without dot" isn't a valid email address 
according to the EmailValidator and thus shouldn't be in your database in the 
first place.

Cheers,

/Markus 

On Wed, Dec 18, 2019, at 11:23 AM, Sam Willis wrote:
> Hi,
> 
> It looks to me like this has introduced a slight behaviour difference 
> with 1.11 on python 2.7 than on 3.x:
> 
> https://github.com/django/django/commit/f4cff43bf921fcea6a29b726eb66767f67753fa2#diff-e840e362abe9e625eee52d91897400bdR36
> 
> The release notes don't indicate what the difference in behaviour is 
> between python 2 and 3.
> 
> I'm trying to follow the change and test cases but it looks like if you 
> have two users 'm...@example.org' and 'mık...@example.org' (which is 
> highly unlikely anyway to happen legitimately) neither can reset their 
> password anymore on py2?
> 
> See: 
> https://github.com/django/django/commit/f4cff43bf921fcea6a29b726eb66767f67753fa2#diff-d4ef44f66fdc7127c6178eee0fdcaf57R697
>  
> 
> I'm guessing this was found after the similar GitHub vulnerability was found?
> 
> Thanks for the hard work!
> 
> On Wednesday, December 18, 2019 at 9:23:35 AM UTC, Mariusz Felisiak 
> wrote:Details are available on the Django project weblog: 
> > 
> > https://www.djangoproject.com/weblog/2019/dec/18/security-releases/ 
> > 
> 
>  -- 
>  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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/5cde448c-7631-472f-857f-168bd872fe3e%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d7e03a11-10c3-4f7b-9932-2a9e0497e318%40www.fastmail.com.

Re: Django 3.0 Release Notes - ASGI

[Markus Holtermann]

Good point, Josh.

I think we should either add an "experimental" note to the ASGI notes or 
introduce an "Experimental changes" section (I'm open to other naming 
suggestions)

/Markus

On Tue, Oct 15, 2019, at 9:45 AM, Josh Smeaton wrote:
> A co-worker just linked me to 
> https://docs.djangoproject.com/en/dev/releases/3.0/#asgi-support and 
> asked me (basically) if we can start doing all kinds of async work in 
> one of our projects. Unfortunately, I didn't really know how to answer.
> 
> Preface: I haven't followed the ASGI plan very closely (I read the DEP 
> and have a vague understanding of the vision).
> 
> It's my understanding that there's only very limited support for ASGI, 
> and most features of Django won't work properly when running under 
> ASGI. But that's not clear from reading the release notes or the deploy 
> on ASGI section of the docs. Should we have a section in the docs that 
> show what is and is not supported, along with examples?
> 
> It'd be good to have a spot in the docs to point to that shows what is 
> in and out of scope for each milestone.
> 
> Thoughts?
> 
>  -- 
>  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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/9b11ecd8-997f-4edc-a627-5523da611a55%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5f103d87-7128-4ce3-8491-a0ed02e0b18a%40www.fastmail.com.

Re: Add Optional Slash Syntax for Path

[Markus Holtermann]

Hi Jason,

Great catch, but I think I agree with Carlton on this one for the reason he 
mentioned, but even more so for what you already pointed out: "it is better 
design to not allow for two  lvalid endpoints for the same path".

Cheers

Markus

On Thu, Aug 29, 2019, at 7:15 AM, Carlton Gibson wrote:
> Hi Jason 
> 
> I think in this case “just use re_path()” is the way to go. (path() 
> being a convenience, rather than a replacement.) 
> 
> For me, complicating the signature of path() for such a corner case 
> wouldn’t be a good trade-off. 
> 
> Kind regards,
> Carlton. 
> 
> On Wed, 28 Aug 2019 at 20:47, Jason Brill  wrote:
> > As re_path and url syntax utilize regex, true optional trailing slashes are 
> > allowed for with the following example:
> > 
> > re_path(r'^about/?$', AboutView.as_view(), name='about')
> > 
> > In this example, a request to both /about and /about/ would yield a 200 
> > response.
> > 
> > 
> > 
> > Using *path* would look like this:
> > 
> > path('about/', AboutView.as_view(), name='about')
> > 
> > Assuming we have *APPEND_SLASH* set to true in our settings, a request to 
> > 'about' would yield a redirect with a 300, and a request to 'about/' would 
> > yield a 200.
> > 
> > 
> > Moreover, using *path* without the slash would look like this:
> > 
> > path('about', AboutView.as_view(), name='about')
> > 
> > Here we'd obtain a 400 when trying to access 'about/', as intended.
> > 
> > 
> > It is impossible to obtain the same behavior when migrating from 
> > url/re_path to path. Although it is better design to not allow for two 
> > valid endpoints for the same path, I believe we should support the ability 
> > to easily maintain the same behavior during migrations.
> > 
> > A solution may be to add a simple parameter for path, so that our route 
> > declaration would look something like this:
> > 
> > path('about', AboutView.as_view(), name='about', optional_slash=True)
> > 
> > *or*
> > 
> > path('about/', AboutView.as_view(), name='about', optional_slash=True)
> > 
> > 
> > Another design may be to declare a new global like OPTIONAL_TRAILING_SLASH 
> > similar to APPEND_SLASH in our middleware.
> 
> >  -- 
> >  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 view this discussion on the web visit 
> > https://groups.google.com/d/msgid/django-developers/f74a7074-a66e-4aeb-8b8a-82a845c3f84a%40googlegroups.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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAJwKpyR%2Bqytt%3Dw2tPTMtH93EowLuvVgb37RZm2GikCZBx3xjqQ%40mail.gmail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8168adb0-2827-45b5-b0ea-8794c034b01a%40www.fastmail.com.

Re: Proposing development discussion forums

[Markus Holtermann]

Thank you for bringing up the idea, Andrew.

As expressed at PyCon AU, I'd be interested in giving an alternative to a 
mailing list a shot. Something that supports subscribing to topics sounds like 
a good idea to overcome the amount of mails one may not be interested in.

Cheers, Markus


On Sat, Aug 10, 2019, at 3:30 PM, Andrew Godwin wrote:
> ‪On Fri, Aug 9, 2019 at 10:16 PM ‫אורי‬‎  wrote:‬
> > Every Google Group also has an online forum:
> > https://groups.google.com/forum/#!forum/django-developers
> 
> Indeed, I am aware of this, I usually use it when I link threads on Twitter.
> 
> However, it is not really a forum in the sense I am describing - one 
> that has categories, editable posts, and the ability to selectively get 
> email for certain categories or threads rather than all-or-nothing. The 
> Groups forum interface is more just an online mailing list interface, 
> with all the problems of the underlying list model.
> 
> Andrew
> 
>  -- 
>  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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAFwN1urt8pfhdyoGe%3D2u31YSg8sf%2BanDNEO6ogX3y4xnfa4WPQ%40mail.gmail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/15d73ed5-4cc6-4cb9-b4fd-b8b4c59d6326%40www.fastmail.com.

Re: Migrations: A bug or a feature needing documentation?

[Markus Holtermann]

Hi Barry,

TL;DR: I think this is a bug and can lead to inconsistencies in other project 
setups than yours.

Let's look at the last question first, regarding duplicate entries in the 
django_migrations table: Yes, this is to be a bug. At least how it's currently 
used.
Let's say you have migration foo.0001_initial and apply it. You then have (foo, 
0001_initial) in the django_migrations table. You now create migration 
foo.0002_something and also add a squashed migration 
foo.0001_initial_squashed_0002_something. When you now run migrate, Django will 
apply foo.0002_something and your database will have (foo, 0001_initial), (foo, 
0002_something) as well as (foo, 0001_initial_squashed_0002_something).
So far so good. That's all as expected. If you now remove foo.0001_initial and 
foo.0002_something from your filesystem and remove the replaces section in 
foo.0001_initial_squashed_0002_something it is as if Django never new about 
foo.0001_initial or foo.0002_something. You can add new migrations, everything 
works the way it should. However, if you were to add e.g. foo.0002_something 
again, Django would treat it as already applied, despite it being somewhere 
later in your migration graph.
At this point, I don't think this is the intended behavior. That said, I'm 
inclined to say that applying a squashed migration should "unrecord" all 
migrations it replaces. I've not yet thought too much about the "fallout" 
(backwards compatibility, rollback of migrations, ...). But at least with 
regards to migrating forwards, this seems to be the right behavior.


Regarding your second point around "replaces" and merging migrations: I think 
this will lead to inconsistencies in your migration order, thus potentially 
causing trouble down the line. I'm yet to think of an example. For now I don't 
see us to change the behavior, but I would definitely *not* rely on it.
I suspect that two data migrations could easily conflict or result in 
inconsistent data if applied in the wrong order. For example, one data 
migration adding new records to a table, and another one ensuring that all 
values in a column are in upper case. If you apply both migrations in that 
order (insert and then ensure uppercase) you can be certain that all values 
will be uppercase. If you, however, first ensure uppercase and then insert 
additional values, you need to make sure that the data in the second migration 
is properly formatted.

Cheers,

Markus


On Tue, Aug 6, 2019, at 7:55 AM, Johnson, Barry wrote:
> 
> [ TL;DR: A migration may use a “replaces” list pointing to migrations 
> that don’t actually exist. This undocumented technique cleanly solves a 
> recurring difficult migration problem. We seek consensus on whether 
> this should become a documented feature or that it is an unexpected 
> side effect subject to change in the future. ]
> 
> 
> 
> We have found an undocumented behavior in the migration system that 
> gracefully solves the troublesome problem of merging migrations created 
> in parallel development branches. If this behavior should survive, 
> we’ll enter a documentation ticket – but if it’s considered a bug, 
> we’ll need to stay away from it and fall back to the more difficult 
> manual editing approaches we’ve used in the past.
> 
> 
> The Use Case
> 
> --
> 
> We’re rapidly developing a large multi-tenant application (hundreds of 
> ORM models, thousands of migrations and hundreds of thousands of lines 
> of code so far, with quite a bit of work remaining) punctuated by 
> periodic production releases. We create a source code branch from our 
> mainline development trunk for each production release, just in case we 
> must rapidly issue patches to those production releases. On rare 
> occasions, we’ve had to make a schema change (such as adding a new 
> field) as a patch to a production release, and make a parallel schema 
> change in the mainline development trunk. 
> 
> 
> Of course, this normally causes a migration failure when migrating a 
> production tenant from the patch release up to a later version of the 
> mainline release – since the mainline release has a subsequent 
> migration that adds the same field. We’ve solved this in the past by 
> manually rearranging the dependency order of the mainline trunk 
> migrations (moving the replacement step before other new migrations for 
> this later release), and fiddling with the contents of the 
> django_migrations table to make it look like that mainline step has 
> already been run before running the migrations. We’re unhappy with that 
> approach – it’s both time consuming and error prone.
> 
> 
> This problem is similar to, but not identical to, that of squashing 
> migrations.
> 
> 
> (And yes, we do periodically squash our migrations. We have about 600 
> migration steps at the moment, left over from more than 2,000 
> originally created. We’ve got another round of squashing coming up soon 
> that should take us to less than 100 migrations – 

Re: Translation templatetag aliases

[Markus Holtermann]

Easy: +1 from me as well for reasons state before.

/Markus

On Sat, Jul 27, 2019, at 6:15 PM, Adam Johnson wrote:
> +1 from me too for the reasons that Aymeric states.
> 
> Another small pro: "translate" is a few more characters to type, but it 
> should make it easier to understand the purpose of the tags to 
> newcomers. "trans" is a prefix used for many words - Wiktionary lists 
> 609: 
> https://en.wiktionary.org/wiki/Category:English_words_prefixed_with_trans- . 
> I guess quite a few Django apps out there have *some* domain term on this 
> list, so using the full word "translate" can help differentiate the tags from 
> those other concepts.
> 
> On Sat, 27 Jul 2019 at 09:51, Aymeric Augustin 
>  wrote:
> > Hello,
> > 
> > I'm in favor of adding support for {% translate %} and {% blocktranslate %} 
> > and switching the Django documentation to use these for two reasons:
> > 
> > - As stated by Mike, the mental associations that "block trans" creates for 
> > those who identify as trans are just bad — I can't believe it took us 12 
> > years to notice :-/
> > - Even if we leave that aside, I'm not sure saving 4 characters (8 with the 
> > closing tag) is really worth the uncommon abbreviation of "translate".
> > 
> > Since this change brings mostly a social benefit rather than a technical 
> > benefit, we could keep the {% trans %} and {% blocktrans %} aliases 
> > forever. Also, this could minimize arguments between those who recognize 
> > the benefits of such changes and those who don't, as we've seen when we 
> > changed master / slave to primary / replica.
> > 
> > In my opinion, such debates mostly reflect the political rift that appeared 
> > in many Western countries in the recent years. It's completely predictable 
> > that they spill into our community. Since they aren't our main focus, we're 
> > trying to avoid spending too much time there. But we can't escape the fact 
> > that we're making Django first for people writing software, then for 
> > computers running that software.
> > 
> > As a community, we chose to state in our Code of Conduct that "we strive to 
> > be a community that welcomes and supports people of all backgrounds and 
> > identities [including] sexual orientation, gender identity and expression". 
> > I believe that the change proposed here is in line with this statement. I 
> > know that some community members will feel that we're doing too much here — 
> > and that others feel that we aren't doing enough in general — which is why 
> > I'm referencing something we already agreed upon.
> > 
> > Best regards,
> > 
> > -- 
> > Aymeric.
> > 
> > 
> > 
> >> On 26 Jul 2019, at 13:17, 'Mike Hansen' via Django developers 
> >> (Contributions to Django itself)  
> >> wrote:
> >> 
> >> Hello all,
> >> 
> >> Recently I had a member of my team bring up that it was uncomfortable
> >> for them to work in parts of our codebase where they regularly had to
> >> see "blocktrans" in the template files. To make our work environment
> >> more inclusive, I wrote a Django package 
> >>  which adds 
> >> "translate" and 
> >> "blocktranslate" templatetag aliases so that we could update our own 
> >> internal templates to use these.
> >> 
> >> We felt that this change would be in line with the Django community
> >> so I made a ticket and pull request to Django at
> >> https://code.djangoproject.com/ticket/30585 . The ticket was closed as
> >> "wontfix", and it was mentioned that I should bring it to django-developers
> >> if I wanted to make further progress on the ticket.
> >> 
> >> Thanks,
> >> --Mike
> >> 
> >> 
> >>  -- 
> >>  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 view this discussion on the web visit 
> >> https://groups.google.com/d/msgid/django-developers/a43ec0ab-f73a-4c11-8fc1-b05d081b24c3%40googlegroups.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 view this discussion on the web visit 
> > https://groups.google.com/d/msgid/django-developers/EF4EE680-BBA1-40EB-979E-2671349186D6%40polytechnique.org
> >  
> > .
> 
> 
> -- 
> Adam
> 
>  -- 
>  You received this message because you are subscribed to the Google 
> Groups "Django 

Re: Resource loading (Django without a filesystem)

[Markus Holtermann]

Hi Peter,

PyOxidizer looks indeed super interesting. Talking about templates and 
specifically Jinja2 templates, they are internally converted to the Python AST 
if I'm not mistaking. Turning them into Python modules that a new 
Jinja2ModuleTemplateLoader could load doesn't seem like that far fetched.

Similarly for Django's migration files. Swapping out the MigrationLoader would 
already be sufficient.

I'd definitely be interested to see what's needed to change in core to have a 
3rd party package provide the necessary support.

Cheers,

Markus

On Thu, Jun 27, 2019, at 9:09 PM, Peter Baumgartner wrote:
> I'm interested in using PyOxidizer [1] to create single-file executable 
> Django projects. This currently isn't possible because of all the 
> places Django assumes it is operating on a proper filesystem. I haven't 
> done a full audit, but templates, migrations, and static files come to 
> mind. Python has full support this scenario (aka resource loading), but 
> it would require some changes to Django internals to use it. One of the 
> biggest hurdles I see on the surface is that you can only load a 
> resource from a Python module (not from a sub-directory). That being 
> said, I have a feeling resource loading could be added such that users 
> could opt-in or backwards compatibility is maintained with the current 
> implementation.
> 
> Some additional reading/watching on the subject:
> 
> * Topic overview: 
> https://pyoxidizer.readthedocs.io/en/latest/packaging_pitfalls.html#reliance-on-file
> * Barry Warsaw talk on resource loading: 
> https://www.youtube.com/watch?v=ZsGFU2qh73E
> 
> I'm posting here to see if there is general support for this and to 
> discuss what sort of changes would be required. Thanks!
> 
> [1] https://pyoxidizer.readthedocs.io/
> 
>  -- 
>  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/b6229b20-0647-4e0a-b9e6-31136a774e13%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/2faec64a-da9f-4d55-9378-a3cb6a308d53%40www.fastmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Redis cache support in core

[Markus Holtermann]

Hi all,

may I suggest that django-redis may be "promoted" to an official Django package 
under the Django GitHub organization? This would follow 
https://github.com/django/deps/blob/master/final/0007-official-projects.rst . 
The package would be pointed out explicitly in the Django docs but would be 
shipped outside of Django.

The benefit with 3rd party packets is their shorter release cycle. Which, in 
the context of django-redis could be beneficial .

/Markus

On Fri, Jun 21, 2019, at 2:43 PM, 'Ivan Anishchuk' via Django developers  
(Contributions to Django itself) wrote:
> I wouldn't say it's that complicated a setup. It would require a single 
> settings snippet -- just like the ones for other backends -- and, I 
> guess, a link to django-redis docs for more details (if django-redis is 
> what we recommend), maybe a quick explanation of what is CLIENT_CLASS 
> and other options. While it would add some maintenance burden 
> (occasionally checking whether any breaking changes were introduced in 
> the 3rd party package that require updating settings) it's still way 
> easier than adding a backend to django core.
> 
> While I agree with others about redis being popular and adding such a 
> backend in django being a good idea (I would love if that happened) I 
> understand the reasons for not doing it. A recommendation of a 3rd 
> party package + setup documentation, on the other hand, is pretty 
> simple thing to do.
> 
> If we want, it's also not very hard to provide 
> `django.core.cache.backend.redis.Redis Cache` that depends on 
> django-redis and is an alias for `django_redis.cache.RedisCache` -- 
> it's basically the way it works with DB backends, I don't see why it 
> wouldn't be a good idea for cache as well.
> 
> Ivan.
> 
> On Thu, Jun 20, 2019, 04:02 Josh Smeaton  wrote:
> > Celery explicitly document their integration with Redis though. I don't 
> > think we want to take over documenting the setup of a 3rd party package in 
> > Django.
> > 
> > On Thursday, 20 June 2019 11:00:27 UTC+10, Ivan Anishchuk wrote:
> >> How about making one of the third-party packages an optional dependency? 
> >> Celery, for example, does that: you can just install celery[redis] without 
> >> having to figure out what other packages you need to enable redis support.
> >> 
> >> Ivan.
> >> 
> >> On Wed, Jun 19, 2019 at 6:44 AM Josh Smeaton  wrote:
> >>> There are already several 3rd party packages that implement redis as a 
> >>> django cache backend, for example https://github.com/niwinz/django-redis
> >>> 
> >>> We already have a base class for cache backends - and several 
> >>> implementing it (such as memcache). I don't think there's much benefit 
> >>> taking on another backend when it's already got very good support as an 
> >>> external package.
> >>> 
> >>> 
> >>> On Tuesday, 18 June 2019 01:14:25 UTC+10, Dulmandakh Sukhbaatar wrote:
>  Hello,
>  
>  I would like to work on Redis support in core, and I would like to 
>  discuss proper solution for that.
>  
>  Redis is getting so popular and almost every modern backend stack uses 
>  it someway, therefore I think that supporting it as a cache backend in 
>  core would make Django more appealing. A solution I'm proposing is to 
>  extract base KV backend from current Memcached and extend it for both 
>  Memcached and Redis, and this won't add many new code to the core. Also 
>  we'll have base class for KV storage backends.
>  
>  Thanks.
> 
> >>>  -- 
> >>>  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/bdb84d20-0489-4ecd-b198-fa5878f5c617%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/335b087c-801a-452b-a5b3-a9711e4a00b8%40googlegroups.com
> >  
> > 

Re: Faster Migrations! But at what cost?

[Markus Holtermann]

Thanks Raphael for bringing this topic up and Simon for your input already.

I just left a note on your PR: 
https://github.com/django/django/pull/11388#issuecomment-494076750 . I'll quote 
it here for ease of readability:

As far as I can see right now, a similar caching happened as a first approach 
to the Django 1.8 release but cause significant problems, specifically with 
regards to relational fields. Relational fields (ForeignKey, OneToOneField, 
ManyToManyField) keep an instance reference to the related model in 
`.related_model` or the related fields in `.related_fields`. The problem now 
is, if you reuse a field (and you do because you're only calling `list()` on 
`self.fields` to copy but not deepcopy the list), you're screwing up references 
between the models that _will_ cause trouble with `RunSQL` and other operations 
that use related field or model attributes.

https://github.com/django/django/blob/1d0bab0bfd77edcf1228d45bf654457a8ff1890d/django/db/models/fields/__init__.py#L495-L499

>From my work on migrations, I see essentially 2 approaches that are viable and 
>would lead to significant performance improvements:

## 1. Make the schema editor work with model states

There's a _very old_ branch on my fork that tries to implement this approach: 
https://github.com/MarkusH/django/commits/schemaeditor-modelstate

I lost interest and eventually also didn't have the time to pursue this 
approach further. I think that's the better of the two approaches, as it gets 
rid of the piece of code that actually _causes_ the slow behavior: turning a 
model state into a model class to be used in the schema editor.

However, making the schema editor backward compatible has been proven difficult 
and to be a huge pain (just check out the commits :wink: )

## 2. Don't resolve models/fields to instances but rely on string references.

This approach is IMO merely a workaround as it would allow us to cache the 
fields and models as you're doing in your PR. 
`model._meta.get_field("author").related_model` would not return `` but `"myapp.Author"`. However, as far as I can tell, 
that's highly backward incompatible. And at this point, I also don't see a way 
to make this backward compatible.

Cheers,

Markus

On Mon, May 20, 2019, at 5:26 PM, charettes wrote:
> Hello Raphael,
> 
> > Have there ever been any surveys about how the size of Django projects? I 
> > don't know the value of investigating this further except for our own usage.
> 
> I'm not aware of any similar surveys in the recent years but I would 
> say *240 models across 90 apps, with roughly 500 migrations* would be 
> considered a really large project in my experience. Did you look into 
> squashing these 500 migrations by any chance? Something we did at 
> $DAYJOB to speed up the test bootstraping process is to prebuild 
> containers with migrations already applied in production so CI running 
> PRs only applies new migrations on top of them.
> 
> > Does the caching of ModelState.render as done in this PR (still need to 
> > work through a couple failing tests) sound reasonable? Or is this veering 
> > too far in the performance/safety guarantee tradeoff?
> 
> While the layer you added seems to yield significant benefits I would 
> argue that it complicates an already too complex apps rendering caching 
> layer. As you'll probably come to discover while trying to resolve the 
> currently failing tests model.Fields equality is not implemented how 
> you'd expect it to be[0] and thus require costly deconstruction to be 
> used as a cache staleness predicate[1].
> 
> > Is the migration operation infrastructure considered a public API? As in, 
> > would changing the Operation model API (potentially breaking subclasses) be 
> > considered a major undertaking? Or would it be an acceptable cost to pay 
> > for some performance improvements?
> 
> Given the large adoption of migrations and the fact the Operation API 
> is publicly documented[2] I would say the performance benefits would 
> need to be quite substantial to break backward compatibility. In my 
> opinion, and I think that's something Markus Holtermann who also worked 
> a lot on speeding up migrations would agree on, we should focus our 
> efforts on avoiding model rendering at all cost. We've already made all 
> state mutation (Operation.state_forwards) avoid all accesses to .apps 
> and I think the next step would be to make `database_forwards` and 
> `database_backwards` do the same. This is something Markus worked on a 
> few years ago[3].
> 
> Cheers,
> Simon
> 
> [0] 
> https://github.com/django/django/blob/1d0bab0bfd77edcf1228d45bf654457a8ff1890d/django/db/models/fields/__init__.py#L495-L499
> [1] 
> https://github.com/django/django/blob/1d0bab0bfd77edcf1228d45bf654457a8ff189

Re: Proposal to format Django using black

[Markus Holtermann]

The primary author of Black, Łukasz Langa, just announced that Black was moved 
under the PSF umbrella: https://twitter.com/llanga/status/1123980466292445190

I updated the link in the DEP-8 accordingly to https://github.com/python/black/

/Markus

On Wed, May 1, 2019, at 2:32 AM, Andrew Godwin wrote:
> Hi all,
> 
> As per the DEP process, I have merged DEP 8, Formatting Code With 
> Black, into the DEP repo as a draft. This doesn't mean it's decided yet 
> - any DEP that meets quality requirements gets merged as a draft - but 
> it means that we're one step closer to doing so.
> 
> What follows is further discussion until it is either revised, 
> withdrawn, or the author thinks they have enough feedback to put it to 
> the technical board.
> 
> I will draw attention to the following part of DEP 1:
> 
> "However, wherever possible, long open-ended discussions on public 
> mailing lists should be avoided. Strategies to keep the discussions 
> efficient include: setting up a separate mailing list for the topic, 
> having the DEP author accept private comments in the early design 
> phases, setting up a wiki page, etc. DEP authors should use their 
> discretion here"
> 
> Given this thread is now over 100 replies long, we might want to 
> consider a better avenue for constructive feedback.
> 
> Andrew
> 
> On Tue, Apr 30, 2019 at 12:31 PM Christian González 
>  wrote:
> > 
> >  Am 30.04.19 um 14:28 schrieb 'Laurens A. Bosscher' via Django developers
> >  (Contributions to Django itself):
> >  > The Chrome team fixed this issue with
> >  > git-hyper-blame: 
> > https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-hyper-blame.html
> >  >
> >  >
> >  > That could be a solution that would work for Django. IDE support for
> >  > git-hyper-blame is lacking (at the moment) but might improve in the
> >  > future.
> > 
> >  I made a feature request for git itself, and they told me this is
> >  already in the works *within* git dev:
> > 
> > https://public-inbox.org/git/20190410162409.117264-1-b...@google.com/
> > 
> >  So on the long run, no need for git-hyper-blame.
> > 
> >  Christian
> > 
> >  -- 
> >  Dr. Christian González
> > https://nerdocs.at
> > 
> >  -- 
> >  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/74e4842c-24fa-6055-2b1e-d70b42153b69%40nerdocs.at.
> >  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/CAFwN1uq0AEP4wL0%3D1xQOF%2BWBVQfGgU5Zfz0V5BurVCbyMeOA3Q%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/97b94a37-430f-40c6-9160-562f03ace56c%40www.fastmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Markus Holtermann]

 Aymeric. Thank you!

On Sun, Apr 28, 2019, at 4:51 PM, Aymeric Augustin wrote:
> Hello,
> 
> Here's my attempt at summarizing the conversation in a DEP: 
> https://github.com/django/deps/pull/55.
> 
> It's easier to read as a rich diff: 
> https://github.com/django/deps/pull/55/files?short_path=95a1a7b#diff-95a1a7b430e2608b84f5c834fd6c258c
> 
> Please let me know if I missed or represented unfairly some ideas!
> 
> Best regards,
> 
> -- 
> Aymeric.
> 
> PS: while I'm eager to listen to feedback and iterate on this draft, I 
> would also prefer if this DEP didn't turn into a novel, so let's avoid 
> going into every detail and trust the implementation team to do a good 
> job — thank you :-)
> 
> 
> > On 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/ECC90690-D27E-40D3-B69E-765D988A1690%40polytechnique.org
>  
> 

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: 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: De-assigning "Easy pickings" tickets

[Markus Holtermann]

Hi Carlton,

my only question would be why you picked 2 months over 1 or 3. Generally in 
favor. I think de-assigning somebody after $time of inactivity on a ticket is 
fair, regardless of the complexity of the ticket.

/Markus

On Fri, Mar 8, 2019, at 8:30 PM, Carlton Gibson wrote:
> Hi all. 
> 
> We don't have many Easy Pickings tickets, they're all assigned, and get 
> assigned quickly, but don't often get closed. 
> 
> Looking at the current batch...
> 
> https://code.djangoproject.com/query?status=assigned=new=1=id=status=changetime=1=changetime
> 
> ... I'd like to suggest that after 2 months we de-assign them, so they 
> can get picked up by people looking, who are likely not 
> willing/able/whatever to take over an assigned ticket themselves. 
> 
> Any thoughts/objections to that as a policy? 
> 
> Thanks. 
> 
> Kind Regards,
> 
> Carlton
> 
> 
> 
> 
>  -- 
>  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/7bb67aa2-c898-4b97-a43a-eba38c00e00e%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/8c599482-9c8e-4335-a5ff-7ffac96e94f8%40www.fastmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Use CDN for djangoproject.com

[Markus Holtermann]

Hi all

to elaborate on what Tobias said: we deliberately have the infrastructure 
spread across multiple service providers: DNS registry, nameservers, hosting, 
TLS certificate authority, … None of them have access to everything. The reason 
is that we offer the download of the release artifacts from the 
djangoproject.com website. And we would like to ensure that the TLS termination 
happens by us and not some random service provider. After all, Django is used 
by enterprises that do have some restrictions on where you're allowed to 
download software from.

By handing over DNS to some CDN provider, we loose the ability to ensure that 
happens.

That said, if there's a CDN that works as a reverse proxy and doesn't require 
us to hand over control of DNS, I guess we could be interested in moving the 
docs behind that.

/Markus

On Thu, Feb 14, 2019, at 2:22 AM, Tobias McNulty wrote:
> For me it's the trust factor (allowing someone else to decrypt and 
> re-encrypt all our data). This may be less of an issue for the docs 
> site, *if* we don't have to assign DNS authority for the whole domain 
> to the CDN provider.
> 
> Tobias
> 
> 
> On Wed, Feb 13, 2019, 7:47 PM Kye Russell  > I’ve been hearing that there are other CDN providers that offer a very 
> > comparable service for a fraction of the cost of CloudFront. 
> > 
> > Anyways, at this stage let’s not get bogged down on provider decisions. I’m 
> > curious if anyone has any general objections to a CDN of any kind. 
> > 
> > It shouldn’t be that big a deal to automatically invalidate when the docs 
> > are updated. But I’m sure there’s something I’m missing. 
> > 
> > On Thu, 14 Feb 2019 at 8:36 am, Cristiano Coelho  
> > wrote:
> >> Consider AWS's cloudfront then :)
> >> 
> >> El martes, 12 de febrero de 2019, 2:34:09 (UTC-5), Florian Apolloner 
> >> escribió:
> >>> Especially cloudflare is a service we do not want to use. as for the docs 
> >>> only, does the mirror on rtd work better for you? They are probably 
> >>> behind a CDN.
> >>> 
> >>> Cheers,
> >>> Florian
> >>> 
> >>> On Tuesday, February 12, 2019 at 6:43:41 AM UTC+1, Cheng C wrote:
>  Hi,
>  
>  Is it possible to utilize a CDN service for djangoproject.com, or at 
>  least on docs.djangoproject.com? The site is actually quite fast for me 
>  but I think there is still room for improvement. Cloudflare sponsored 
>  dozens of open source projects 
>  , probably they can 
>  provide free service for django as well.
>  
>  Tested from Melbourne, Australia:
>  
>  https://www.djangoproject.com/
>   Average Ping: 245ms
>   Browser: 21 requests, 211KB transferred, Finish: 2.52s, 
>  DOMContentLoaded: 1.16s, Load: 1.48s
>  
>  https://git-scm.com/
>   Average Ping: 5ms
>   Browser: 42 requests, 351KB transferred, Finish: 717ms, 
>  DOMContentLoaded: 564ms, Load: 699ms
>  
>  Tested on Chrome with "Disable cache" checked (but not the first time 
>  visit, so DNS query time might not be included).
>  
>  Best regards and thanks for all your great work. 
> >>  
> 
> 
> >>  -- 
> >>  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/548db807-647f-4d0b-99c2-f9f229f7175e%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/CANK-yknQ1Auf6CFD-%2B94qoATQ2K%2By0poLw%3DaxyJYjO3PaHOQWA%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 

Re: Breaking change vs deprecation on Sitemaps `ping_google` command

[Markus Holtermann]

Hi all,

I'm in favor of _not_ having another settings variable. Completely forgot to 
add that underneath my suggestion of how a migration path _could_ look like. 
臘‍♂️

/Markus

On Wed, Jan 9, 2019, at 10:03 PM, Aymeric Augustin wrote:
> Ditto.
> 
> I'd rather have a small, documented backwards incompatibility (and 
> that's unlikely to cause significant problems) that another setting.
> 
> Cheers,
> 
>  
> -- 
> Aymeric.
> 
> 
>  
>  
> 
> > On 9 Jan 2019, at 16:09, charettes  wrote:
> > 
> > I agree with Tim, this is a minor change in a contrib app.
> > 
> > I don't think it warrants all the efforts required for a deprecation period 
> > given the large adoption of https in the recent years.
> > 
> > Le mercredi 9 janvier 2019 06:41:25 UTC-5, Tim Graham a écrit :
> >> Adding temporary settings to the default project template sounds like a 
> >> fair bit of cruft for a contrib app that isn't enabled by default. I don't 
> >> use ping_google but I'm in favor of making the switch without a 
> >> deprecation. Users of ping_google please comment, but switching to https 
> >> doesn't seem like the sort of change that's going to cause massive pain.
> >> 
> >> On Wednesday, January 9, 2019 at 5:26:37 AM UTC-5, Markus Holtermann 
> >> wrote:Hi all, 
> >>> 
> >>> We could introduce a settings variable `SITEMAPS_PING_GOOGLE_HTTPS` 
> >>> that's part of newly created projects' settings (in 
> >>> https://github.com/django/django/blob/master/django/conf/project_template/project_name/settings.py-tpl)
> >>>  and set to `True`. In global_settings.py it defaults to `False`. Users 
> >>> could then turn it on for existing projects. Once the deprecation period 
> >>> is over we would simply remove the variable and thus enforce HTTPS. We 
> >>> could then also possibly issue a notice through the checks framework that 
> >>> the variable is now obsolete. 
> >>> 
> >>> Cheers, 
> >>> 
> >>> Markus 
> >>> 
> >>> On Wed, Jan 9, 2019, at 10:59 AM, Carlton Gibson wrote: 
> >>> > Hi all. 
> >>> > 
> >>> > There's PR to fix long-standing issue with HTTP-only URLs being 
> >>> > generated by the `ping_google` sitemaps command. 
> >>> > 
> >>> > https://code.djangoproject.com/ticket/23829 
> >>> > https://github.com/django/django/pull/10651 
> >>> > 
> >>> > (The PR also allows specifying the domain, so you don't need 
> >>> > contrib.sites installed.) 
> >>> > 
> >>> > The idea is to generate HTTPS URLs by default, having a flag to switch 
> >>> > (back) to HTTP if that's what you really need. (`--use_http`) 
> >>> > 
> >>> > This though is a breaking change potentially: you'd need to add the new 
> >>> > flag to your deployment scripts, or wherever, to keep existing HTTP 
> >>> > URLs working. 
> >>> > 
> >>> > Because of this Adam suggested putting it through the deprecation 
> >>> > process: keep the HTTP default and switch to HTTPS as the default 
> >>> > later. 
> >>> > 
> >>> > However, I can't see how we can offer the new preferred usage (default 
> >>> > to HTTPS without additional flags to the command) from day-one, 
> >>> > allowing a shim to fallback to the existing behaviour: the best we seem 
> >>> > to be able to do is emit a warning saying there'll be a breaking change 
> >>> > in the future. If that's the case I'd rather just bite the bullet on 
> >>> > it: clearly state that the new flag will be needed to keep using HTTP 
> >>> > URLs in the v2.2 release notes and move on. 
> >>> > 
> >>> > Thoughts please. Thanks. 
> >>> > 
> >>> > Carlton. 
> >>> > 
> >>> > 
> >>> >  
> >>> > 
> >>> > 
> >>> > -- 
> >>> > 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-develop...@googlegroups.com. 
> >>> > To post to this group, send email to 
> >>> > django-d...@googlegroups.com. 
> >>> > Visit this gro

Re: Breaking change vs deprecation on Sitemaps `ping_google` command

[Markus Holtermann]

Hi all,

We could introduce a settings variable `SITEMAPS_PING_GOOGLE_HTTPS` that's part 
of newly created projects' settings (in 
https://github.com/django/django/blob/master/django/conf/project_template/project_name/settings.py-tpl)
 and set to `True`. In global_settings.py it defaults to `False`. Users could 
then turn it on for existing projects. Once the deprecation period is over we 
would simply remove the variable and thus enforce HTTPS. We could then also 
possibly issue a notice through the checks framework that the variable is now 
obsolete.

Cheers,

Markus

On Wed, Jan 9, 2019, at 10:59 AM, Carlton Gibson wrote:
> Hi all. 
> 
> There's PR to fix long-standing issue with HTTP-only URLs being 
> generated by the `ping_google` sitemaps command. 
> 
> https://code.djangoproject.com/ticket/23829
> https://github.com/django/django/pull/10651
> 
> (The PR also allows specifying the domain, so you don't need 
> contrib.sites installed.)
> 
> The idea is to generate HTTPS URLs by default, having a flag to switch 
> (back) to HTTP if that's what you really need. (`--use_http`)
> 
> This though is a breaking change potentially: you'd need to add the new 
> flag to your deployment scripts, or wherever, to keep existing HTTP 
> URLs working.
> 
> Because of this Adam suggested putting it through the deprecation 
> process: keep the HTTP default and switch to HTTPS as the default 
> later. 
> 
> However, I can't see how we can offer the new preferred usage (default 
> to HTTPS without additional flags to the command) from day-one, 
> allowing a shim to fallback to the existing behaviour: the best we seem 
> to be able to do is emit a warning saying there'll be a breaking change 
> in the future. If that's the case I'd rather just bite the bullet on 
> it: clearly state that the new flag will be needed to keep using HTTP 
> URLs in the v2.2 release notes and move on. 
> 
> Thoughts please. Thanks. 
> 
> Carlton.
> 
> 
>  
> 
> 
>  -- 
>  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/4188349d-a72a-4c2b-92d9-ee607c4c8b04%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/62496331-bdcd-4cdf-9fad-6d779f837f00%40www.fastmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add Python 3.7 support for Django 1.11?

[Markus Holtermann]

Agreed, let's add official 3.7 support.

/Markus

On Sat, Nov 17, 2018, at 1:15 PM, Adam Johnson wrote:
> Since it's about 3 lines in django itself, I think it's a good idea to
> backport and save users the pain.
> 
> On Fri, 16 Nov 2018 at 15:37, Ramiro Morales  wrote:
> 
> > On Fri, Nov 16, 2018 at 12:32 PM Tom Forbes  wrote:
> >
> >> Do we have an idea of how many fixes would need to be backported?
> >>
> >
> >
> > https://github.com/django/django/compare/stable/1.11.x...moneymeets:moneymeets/1.11.16-py37
> >
> >
> >> 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/CAFNZOJNqLQtq03ee-Sfc5v5z1YzETbxu%3D-bWN9FQk0%3D5Yd1Whg%40mail.gmail.com
> >> 
> >> .
> >> For more options, visit https://groups.google.com/d/optout.
> >>
> >
> >
> > --
> > Ramiro Morales
> > @ramiromorales
> >
> > --
> > 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/CAO7PdF_VpdxxCPkLSh3GHCA6svsoCKa7zb0WiLnxuZFSPQe4%2Bw%40mail.gmail.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/CAMyDDM1VANrdq0M70N4%3DPX1b2zzuCguz83u82DM6s%3DJS1FXWfQ%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/1542474667.1346971.1580307392.1296E6C5%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Standalone is_safe_url() function

[Markus Holtermann]

Hi all,

Django provides a function `django.utils.is_safe_url()` to ensure that a given 
URL (absolute or relative) is safe to redirect to. I needed that functionality 
on another project that doesn't use Django at all. I thus built a standalone 
is-safe-url Python package that can be installed from PyPI and exposes exactly 
that functionality:

  $ pip install is-safe-url
  Collecting is-safe-url
Downloading https://files.pythonhosted.org/packages/7a/c3  
/40c363bc4c3d0ddcda3489239ba64752b8c18cb6493e058f8f1b73154925/is_safe_url-1.0-py3-none-any.whl
  Installing collected packages: is-safe-url
  Successfully installed is-safe-url-1.0

The code is available on GitLab: https://gitlab.com/MarkusH/is_safe_url

I'd love to get some feedback on a couple of things:

- As Django is published under the BSD-3 clause license, the standalone package 
is published under the same license. I'd love some feedback if the package 
adheres to the required references and naming of the source.

- I added a note that security issues should be reported privately to the 
Django security team at secur...@djangoproject.com or me personally (I'm a 
member of the security team and could forward the report accordingly). Are 
there suggestions how the statement in the README could be made more clear?

- The package is available for Python 2.7, 3.4, 3.5, 3.6, and 3.7. Should I 
keep 2.7 or drop it? I know some people are still on 2.7 and 2.7 is still 
supported for another 2 years.

- How would security releases work? When there's a security report against 
Django's built-in is_safe_url(), this package would need to be released as well.

- Jannis Leidel raised a valid concern about abandonment of this or similar 
packages (thanks!): "I'm mostly worried about abandonment of packages (from 
experience) that makes maintenance of sec infrastructure brittle." — 
https://twitter.com/jezdez/status/1049955307558981634

I want to approach the latter concern about abandonment upfront. But I don't 
have a clear answer or solution to it yet.

- Would it be useful to have this package under the Django GitHub org?
- If so, should Django possibly depend on that package by itself? Given how 
often Django had security releases because of issues in `is_safe_url()` 
releasing a smaller package and not the full Django package could possibly be 
beneficial.
- Does somebody from the security team want or should be another maintainer?

Thanks for reading.

Markus

-- 
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/1539165995.555224.1537024600.56847611%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adjusting Django's security notification policy

[Markus Holtermann]

Can: yes. Should: no.

I would be really saddened to see companies being able to buy security by 
throwing money at us. That makes us look like we can be bought. And that sends 
the wrong signal, from my perspective. Timely security updates should be 
available to everyone. 

Should enterprises sponsor the DSF, open source projects, or the open source 
community in general: yes, absolutely.

What we could think about is something where companies above a yearly revenue 
of US$ x need to sponsor in order to be on a pre-notification list. But the 
moment we do that we put people's data at risk. A company that doesn't want to 
pay for that sponsorship and thus won't get pre-notifications may remain on an 
insecure version longer that they should or would if they had received a 
pre-notification. And that's terrible as well.

My 2¢

Markus

On Wed, Oct 3, 2018, at 9:14 AM, Carlton Gibson wrote:
> 
> On Sunday, 30 September 2018 06:51:41 UTC+2, James Bennett wrote:
> >
> > Does anyone else have feedback on this? I'd like to push it forward.
> >
> 
> I don't know if this would fly but, given that pre-notification is mainly 
> thought of for large-scale ("enterprise"?) deployments that can't 
> realistically "Just Update!", 
> could we make Corporate Sponsorship of the DSF a requirement for 
> pre-notification? (These are big companies, with payroll. A sponsorship is 
> loose change in this context, and may at least encourage trying to 
> update...) 
> 
> (Just a thought.) 
> 
> 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/b3f4aa4c-9b00-41ac-8668-87ffa570f2d6%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/1538558277.1719089.1528965704.3DA7E4ED%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Mixins] - Order of the Mixins - Is it a bug?

[Markus Holtermann]

Hi Vinnicyus,

this is by design.

There's an interesting talk by Ana Balica on Mixins in Django: 
https://www.youtube.com/watch?v=rMn2wC0PuXw

/Markus

On Fri, Jun 15, 2018 at 02:31:42PM -0300, Vinnicyus Gracindo wrote:

Hi. I beat my brains out trying to find out why my cbv was not working
with LoginRequiredMixin.
I found the order of the mixins in the inheritance:
It works: class UserListView(LoginRequiredMixin, ListView)
Doesn't work:  class UserListView(ListView, LoginRequiredMixin)

Is that how it was designed? or is it a bug?

Thanks.

--
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/CAMjWKi8LdUEwBnTfPX43x%3D5DWUam74dy-eVBof5%2BJmGOr1SLYQ%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/20180615175002.t4wrac4ok5i47f52%40inel.local.
For more options, visit https://groups.google.com/d/optout.

Re: RFC : Migration Adapters

[Markus Holtermann]

Hey Curtis,

the key of the migration operations ordering is in
https://github.com/django/django/blob/d0a42a14c06e033922f6d51e6384cba53be887b6/django/db/migrations/autodetector.py#L159-L195
as you probably have figured out.

What _could_ work, it's not more than idea w/o much thinking about it,
turning these function calls into a list or whatnot that you can inject
functions into that could do "stuff". Or create a dozen hooks that are
called before/after each of these steps.

The other important part is the MigrationGraph in
https://github.com/django/django/blob/d0a42a14c06e033922f6d51e6384cba53be887b6/django/db/migrations/graph.py#L99
that defines in which order migrations are being applied. Injecting
something there is relatively easy by adding more nodes and dependencies
to the graph. There's no official interface to do so, though.

I hope that already helps.

/Markus

On Sat, Feb 03, 2018 at 08:29:24PM +1100, Curtis Maloney wrote:

Hey,

I've recently written an app that implements a closure tree using 
views... and in order to make the migrations work as needed you must 
manually add an entry to the migrations.


Another friend of mine, a recent django convert, was wanting a way to 
add to the migration script generated when creating certain tables...


And today I realised I wanted quite involved control of how migration 
actions are written for the idea I was working on...


What I conceived was what I call a MigrationAdapter, which controls at 
least how create/modify/delete actions for a given object are 
generated.


I've started looking into the migrations code, and it appears the 
steps are very much hard-coded [and, it appears, with much painfully 
learned good reasons]...


Anyone with more familiarity with the migration machinery got input on 
if this is feasible?


--
Curtis

--
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/12134aff-d37c-2b35-27a2-58d52f9358ff%40tinbrain.net.
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/20180203125940.dllawwoxiqwchgev%40pyler.local.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: GLOBAL_PERMS

[Markus Holtermann]

Thanks Curtis,

I had a quick look. Some thoughts (in no particular order):

- IMO a nice idea. I've attached all model independent permissions to
 the user model in the past to work around the limitation.

- How do you envision 3rd party apps handling their own permissions? If
 I install 2 independent apps and both use a permission can_do_foo, one
 can't distinguish between those two, right?

- What do you think about adding an 'app_label' to the Permission model
 that can be used instead of a content type. That could solve the issue
 from the previous point? content_type and app_label would be
 exclusive?

- I dislike the seetings approach of GLOBAL_PERMS and would rather see
 users writing explicit data migrations.

/Markus

On Sat, Dec 30, 2017 at 08:31:57PM +1100, Curtis Maloney wrote:


So, after a discussion with a new user on #django today I decided to 
make "permissions not bound to models" a first-class feature.


So I've written a simple patch that is in 
https://github.com/django/django/compare/master...funkybob:feature/cjm/global_perms?expand=1

Basically:

1. Allow Permission.content_type to be null

2. Adjust everything else to cope with that

3. Add new setting "GLOBAL_PERMS"

4. Teach create_permissions to honor that.

5. Write minimal test and documentation.

Would welcome further input.

--
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/1a028faa-beb1-7e67-69a7-a9c1028a4e17%40tinbrain.net.
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/20171230135038.GA29952%40inel.local.
For more options, visit https://groups.google.com/d/optout.

Re: Provide option to chain QuerySet.order_by()

[Markus Holtermann]

Thanks for the input, Shai. I'd like to keep the current behavior
around. So .order_by(None) would still reset the ordering as-is.

But I agree, if we'de exposing QuerySet.query.order_by through a
documented API that would work for me as well (in fact, I'm using that
right now to work around the issue).

Cheers,

Markus

On 12/11/2017 10:27 PM, Shai Berger wrote:
> Hi Markus and all,
> 
> My instinct is that it's better to just make sure it's easy to find the 
> current 
> ordering on a queryset. I suspect the use-case for modifications is not super 
> common, and I'd rather not bother with specifying the exact behavior of 
> nonsense cases like order_by(None, append=True) and 
> order_by('?', prepend=True) -- which, as the framework, we'd be required to 
> do, but if you're modifying a list on your own, you're free to ignore.
> 
> My 2 cents,
>   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/d1258e72-93a0-4075-da65-9f09902845f1%40markusholtermann.eu.
For more options, visit https://groups.google.com/d/optout.

Provide option to chain QuerySet.order_by()

[Markus Holtermann]

Hi all,

I'm in the situation where I'd like to join two .order_by() calls on a 
QuerySet without losing the ordering set by the first call.

This was formerly discussed in https://code.djangoproject.com/ticket/9415 . 
I agree that simply changing the current behavior is not going to fly due 
to its backwards incompatibility.

My proposed API is similarly to force_insert/force_update on Model.save():

class QuerySet:
def order_by(self, *field_names, append=False, prepend=False):
if append and prepend:
raise AssertionError('Can only append or prepend, not both')
assert self.query.can_filter(), \
"Cannot reorder a query once a slice has been taken."
obj = self._chain()
if not append and not prepend:
obj.query.clear_ordering(force_empty=False)
obj.query.add_ordering(*field_names, prepend=prepend)
return obj


class Query:
def add_ordering(self, *ordering, prepend=False):
if append and prepend:
raise AssertionError('Can only append or prepend, not both')
# ...
if ordering:
if prepend:
self.ordering = ordering + self.ordering
else:
self.order_by += ordering
# ...

I'm happy to open a ticket once I got some feedback.

Cheers,

Markus

-- 
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/c9279d82-6b81-42cb-8577-16004e623e3d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Default to BigAutoField

[Markus Holtermann]

Thanks for taking the effort to work on this, Kenneth!

I'm don't fully agree with the approach. This essentially forces 3rd
party package authors to make the call about the primary key field size.
While for small to medium size projects BigAutoField is unlikely
required and only comes with additional (storage) costs. Given that the
migrations would need to be part of the 3rd party package there's also
no (trivial) way for project developers to force or change to
SmallAutoField for those packages. The same thing holds the other way
round.

Unfortunately, I don't have another solution at hand.

I realized that I'm a bit late to the discussion and should've chimed
in before all that work was done. Please accept my apologies for that.

/Markus


On Thu, Aug 17, 2017 at 02:43:07PM -0700, Andrew Godwin wrote:

To elaborate on the solution we eventually came up with - we default models
to use a new BigAutoField that migrations will pick up on and generate
migrations to alter columns to, but for safety reasons for those that don't
read release notes, made the migration autodetector ask you if you want to
make these migrations with a slowness warning.

It also tells you how to preserve the old behaviour and avoid new
migrations if you wish (manually set id = SmallAutoField)

I like this approach as it means no new settings or Meta options or
anything, has a reasonable upgrade path, and won't let people unwittingly
wander into giant changes. The downside is that it does add slightly more
friction to the upgrade process.

Andrew

On Thu, Aug 17, 2017 at 2:36 PM, Kenneth Reitz  wrote:


I have opened a pull request:

https://github.com/django/django/pull/8924

Andrew and I came up with a good solution for migrations, together at
DjangoCon.

On Wednesday, June 14, 2017 at 7:36:36 AM UTC-7, Melvyn Sopacua wrote:


On Friday 09 June 2017 15:59:50 Kenneth Reitz wrote:

> However, it should also be noted that those same larger applications

> are the ones that are likely to run into this problem eventually, so

> perhaps forcing the migration is the best path moving forward.





Existing models are the problem. Then again the database knows the truth.
So with a little inspection during apps.get_models we might be able to do
the right thing and even allow migrating in steps.



Apps is also the place to mark an app as migrated.



In fact - couldn't an AppConfig grow a method "get_autoid_type()" and
inject the right one?



You asked fr thoughts, so there's my 2c stream.

--

Melvyn Sopacua


--
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/e3effc41-10e1-42e2-9037-
84c98217cd91%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/CAFwN1uo4Y_pWSf3zAe_4R0GGkDqBv1YGus8Q%2BWPPZ%3DZ6FPwdYQ%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/20170818124354.GA1898%40inel.local.
For more options, visit https://groups.google.com/d/optout.

Re: Problems around SchemaEditor._alter_field

[Markus Holtermann]

Agreed. As mentioned on IRC, _alter_field() should really be cleaned up.
It's also private API and only called from alter_field() I think. And as
long alter_field()'s API stays backwards compatible you're pretty much
free to do what you need with _alter_field().

/Markus

On 05/09/2017 09:23 PM, charettes wrote:
> Hey Florian,
> 
> I think both options are viable.
> 
> The main issue with a feature flag would be that it isn't tested by our CI. 
> I guess we
> could make it True on SQLite and have it call remake_table to have some 
> tests rely
> on it or mock it to True in tests and make sure everything goes well.
> 
> In all cases breaking the humongous _alter_field method into smaller ones 
> can't
> hurt.
> 
> Cheers,
> Simon
> 
> Le mardi 9 mai 2017 09:24:46 UTC-4, Florian Apolloner a écrit :
>>
>> I am currently trying to (again?) write a database backend for Informix. 
>> So far so good, but I am running into one major issue: All of Django's 
>> other databases support changing null/default properties via "ALTER TABLE 
>> ALTER col DROP NULL/DEFAULT" or what not. In Informix I can only use "ALTER 
>> TABLE MODIFY" and rewrite the column completely [1]. This means that I 
>> would need more information in [2] (which I initially tried in 
>> https://github.com/django/django/commit/2b3a9414570af623853ca0f819c7d77d0511f22c
>>  
>> before noticing that I need to repeat the whole column declaration). I am 
>> looking into options to extend _alter_field [3] in a way that I can either 
>> add a database feature that says something along the line of: "field 
>> property changes need full remake" and then call into 
>> _alter_column_type_sql directly, or at least factor the (for me) annoying 
>> parts out into _alter_column_properties.
>>
>> Which of the two would you prefer?
>>
>> Thanks,
>> Florian
>>
>> [1] 
>> https://www.ibm.com/support/knowledgecenter/en/SSGU8G_12.1.0/com.ibm.sqls.doc/ids_sqs_0290.htm
>>  
>> [2] 
>> https://github.com/django/django/blob/837259a63ff03fbc0ca2bc2999a6fbc8c6c40bcc/django/db/backends/base/schema.py#L39-L42
>>  
>> [3] 
>> https://github.com/django/django/blob/837259a63ff03fbc0ca2bc2999a6fbc8c6c40bcc/django/db/backends/base/schema.py#L581-L640
>>
> 

-- 
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/f69a6590-f882-8e1b-230b-117b60a4fc73%40markusholtermann.eu.
For more options, visit https://groups.google.com/d/optout.

Re: Organizing utilities for Django's test suite

[Markus Holtermann]

Hey Tim,

I think we can make a case for including this in django/tests/testcases.py 
and in a new module tests/utils/something.py which is then only available 
within Django's own the test suite. I think we should include that test 
case as part of Django's own test suite for now. It's IMO easier to move 
code from tests/utils/something.py to django/tests/something.py than vice 
versa.

That said, I think we should make capture_stdout()/err()/in() public API. 
It's super helpful.

/Markus

On Thursday, April 27, 2017 at 6:57:34 PM UTC+2, Tim Graham wrote:
>
> At present, we have a number of functions in django.test.utils which 
> aren't documented and are meant for use in Django's test suite. Things like:
>
> * extend_sys_path()
> * isolate_lru_cache() 
> * captured_stdout()/err()/in()
> * freeze_time()
> * require_jinja2()
>
> I have the need to reuse a WidgetTestCase from forms_tests in 
> postgres_tests so I tentatively proposed putting it in 
> django/test/testcases.py with a comment that it's not a public API [0]. 
> Simon proposed creating a django/tests/tests/utils.py submodule (alongside 
> runtests.py) instead of defining it in django.test since it's not meant to 
> be a public API.
>
> Do you have any feelings about how to best organize things? I agree that 
> mixing public and private things in django.test is not ideal. Another idea 
> I had was to create something like django/test/_utils.py (underscore 
> prefix) for private stuff. That would allow user code to continue using 
> private APIs at their own risk (whereas putting test helpers in tests/ 
> would not). 
>
> [0] https://github.com/django/django/pull/8425
>

-- 
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/05cff3b6-ded2-4243-9d77-bddf61c572c8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Some thoughts about improving migration squashing

[Markus Holtermann]

On Thu, Feb 16, 2017 at 03:25:16PM -0800, raph...@makeleaps.com wrote:

When you have AddField('A', 'foo', ForeignKey('B')), this operation
references A and foo, but also references B.


correct.


RemoveField('A', 'foo') also references A and foo, but does it reference B?
if it does, then it' s hard to have optimizations that pass through this,
because this field could be referencing any model (theoretically).


No, that field can not reference any model. It reference exactly one
model (that even holds for FK to abstract models as fields from abstract
models are inlined in the concrete models in migrations). However,
RemoveField doesn't have the information to "just" figure out the
referenced model. RemoveField would need to look into the from_state's
apps and actually even look into the actual field that's referred.
ForeignKeys have an implicit to_field attribute, so, having

 AddField('A', 'foo', ForeignKey('B', to_field='bar'))

a

 RemoveField('A', 'foo')

references exactly one field on one particular model. Not more and not
less. The issue here is that RemoveField needs to take that information
from the state and not from one of its attributes.

/Markus



But if we assert that RemoveField doesn't refer to any models referenced to
by its field, then our optimizer can take a couple more liberties.

Raphael

On Friday, February 17, 2017 at 2:15:47 AM UTC+9, Markus Holtermann wrote:


I'm not sure if it's related or not wo what you're investigating,
RemoveField cannot "just" optimized through, as you might have another
AddField operation afterwards adding another field with the same name.

/Markus

On Thu, Feb 16, 2017 at 08:19:01AM -0800, rap...@makeleaps.com
 wrote:
>Hey Simon,
>
> I looked through your PR and added a couple comments. The main thing is
I
>think we can actually ignore the field context on "RemoveField", if only
>because the executor doesn't need it. Even though the field might be
>pointing to a related model, that doesn't prevent being optimized
through.
>
> This is hard to explain, but intuitively, each "RemoveField" is paired
>with an "AddField" or "CreateModel" that *does *depend on the related
>model. So if we have a potentially dangerous optimization, those initial
>operations will "protect" the causal order, not "RemoveField".
>
> Raphael
>
>--
>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-develop...@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/9dfdcec6-b98c-44f2-86af-99aaa8857cc9%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/7515c909-a015-451d-bdaa-f040e6322166%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/20170220104923.GA17288%40inel.local.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Some thoughts about improving migration squashing

[Markus Holtermann]

I'm not sure if it's related or not wo what you're investigating,
RemoveField cannot "just" optimized through, as you might have another
AddField operation afterwards adding another field with the same name.

/Markus

On Thu, Feb 16, 2017 at 08:19:01AM -0800, raph...@makeleaps.com wrote:

Hey Simon,

I looked through your PR and added a couple comments. The main thing is I
think we can actually ignore the field context on "RemoveField", if only
because the executor doesn't need it. Even though the field might be
pointing to a related model, that doesn't prevent being optimized through.

This is hard to explain, but intuitively, each "RemoveField" is paired
with an "AddField" or "CreateModel" that *does *depend on the related
model. So if we have a potentially dangerous optimization, those initial
operations will "protect" the causal order, not "RemoveField".

Raphael

--
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/9dfdcec6-b98c-44f2-86af-99aaa8857cc9%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/20170216171532.GE8346%40inel.local.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Some thoughts about improving migration squashing

[Markus Holtermann]

Thanks Raphael, that's a pretty good write up!

You're essentially speaking about 2 things here, in my opinion:

1. Adding a new feature for interactive squash
2. Improving the MigrationOptimizer

I certainly see a point for 2. Not sure how much for 1. Anyway, your 
reasoning for 2 sounds great! I'd be more than happy if you want to get 
this into Django! Can you create a respective ticket and drop your 
explanation in there, please :)

Cheers,

/Markus

On Wednesday, February 15, 2017 at 1:22:11 PM UTC+1, rap...@makeleaps.com 
wrote:
>
> Hello everyone,
>
>I spent a couple hours last night trying to improve the migration 
> squasher optimizer (migrations were taking almost 15 minutes in CI). I came 
> up with a couple ideas for anyone interested in improvements:
>  
>  1- Having an interactive mode for squashing would be interested. 
> Currently, when squashing migrations, I do the following: 
>
>- Generate an initial squash
>- Edit it (namely, move around operations to get more optimizations to 
>work)
>- remove the "replaces" tag, then rerun migration squashing to 
>"re-optimize"
>- repeat until I get something I like, then add the original 
>"replaces" tag
>
>It would be cool if instead, the process were (with a flag):
>
>- Generate an initial squash, but have the process wait for 
>confirmation to "commit" this squash as final (though writing out the file)
>- Edit the file, and tell the process to try re-optimizing with the 
>same file (getting around the "no-squash of squashes" rule)
>- Potentially, allow us to also step back
>
>  For example, the "squashmigrations" command output could look like:
>
> generated 0001_squashed_mig.py
>> optmize migration[yN]? 
>> 
>> regenerated 0001_squashed_mig.py
>> ( 20 operations -> 10 operations)
>> optimize migration[Ynr]? 
>> 
>> regenerated 0001_squashed_mig.py
>> ( No change in operation count)
>> optimize migration[Ynr]? 
>> 
>> rolled back to previous version
>> optimize migration[Ynr]? 
>> 
>> Saved migration
>>
>
>
> A simpler version of this command would simply be to add an 
> "optimizemigration" command that just reads in a single migration and 
> optimizes the operations, without touching any of the squashiness. 
>
>
>  2- The reducer might be a bit too pessimistic
>
>  Currently, the optimizer lets "reduce" operations (that take 2 operations 
> and return 0,1, or 2 operations, or None if nothing can be change) do 
> whatever they want. Because of that, if you have [A, B, C ,D] and B depends 
> on A, you can't reduce A and C because the reduction might remove A.
>
>  In reality there are two kinds of reduction operations that we could be 
> taking into account:
>
>- reducing "left". if you have [A, B, C, D] (for example, A is a 
> CreateModel , C is an AddField for the same model),  and you can reduce A 
> and C into just A' (A with C), giving [A', B, D], then it doesn't matter 
> that B depends on A. 
>
> The thing that matters is if C depends on B (for example, C adds a foreign 
> key to a model created in B). This is actually already encoded in the 
> CreateMode + AddField reduction, but is perhaps a more general case.
>
> In a sense, reducing A and C "to the left" means that we're bringing A and 
> C closer together only by moving C. This is a major part of the potential 
> reductions that the current optimizer is missing.
>
>- reducing right. If you have [A, B, C, D] (for example, A is a 
> CreateModel, C is a RemoveModel for the same model), and you can reduce A 
> and C into just C' (C with A), giving [B, C', D], then it does matter that 
> B depends on A. C can't depend on B (assuming causality holds in our 
> universe)
>
> This is the current mechanism, essentially. If B depends on A, then you 
> can't move A past B. 
>
>  Removing both operations is a special case of reducing right (You can 
> make C' into a no-op).
>
> I had monkeypatched a special case of  reducing left (taking CreateModel, 
> AddField of different models and swapping them . For example 
> [CreateModel(A), CreateModel(B), AddField(A.foo)] -> [CreateModel(A), 
> AddField(A.foo), CreateModel(B)]) and got decent results, but I think 
> making the optimization code express these two concepts separately would 
> catch even more of the optimizations I saw that the optimizer didn't.
>
>
> I hope some of this is useful 
>  
>   Raphael
>

-- 
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/bcc73cef-e6f8-4aaf-b5a9-4592895b3b2e%40googlegroups.com.
For more options, 

Re: Some thoughts about improving migration squashing

[Markus Holtermann]

What might be interesting to look into when squashing all migrations in one 
app would be to assume no migrations would exist. That could then result in 
only 2 migrations which could run through the optimizer (as opposed to 
let's say 20 migrations with many more operations).

/Markus

On Wednesday, February 15, 2017 at 3:46:01 PM UTC+1, Florian Apolloner 
wrote:
>
> Fwiw I think by default it could/should try to optimize all migrations of 
> an app, manually specifying the migration name should be optional.
>
> On Wednesday, February 15, 2017 at 2:00:54 PM UTC+1, rap...@makeleaps.com 
> wrote:
>>
>> I ended up having some time today, so wrote up a management command for 
>> the first suggestion!
>>
>> I called it "optizemigration"
>>
>>
>> >>> ./manage.py optimizemigration appname 0001_squashed
>>   # snipped django startup noise
>>   Optimized from 9 operations to 4 operations
>>
>> Optimized migration /Users/rtpg/proj/projname/projname/appname/migrations
>> /0001_squashed_20170215.py
>>
>>
>> This reads in the migration file, runs the migration optimizer, and then 
>> outputs to the same file. Writing it has paid off almost immediately for me.
>>
>> Those who are interested can take a look here 
>> 
>> .
>>
>> How much testing/coverage requirements are there for management commands 
>> like these?
>>
>>
>>

-- 
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/24896164-cf2f-4eb9-8d87-3932f2c30e78%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Migrating to new Servers / Trac downtime

[Markus Holtermann]

Hi y'all,

We'll be migrating parts of our infrastructure to new servers. This comes 
with a short (read-only) downtime of Trac, our issue tracker. We expect the 
documentation and website to remain online. We'll update here when the 
migration is done.

Cheers,

/Markus

-- 
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/eafe3494-6551-49be-a7fa-7a4a461fe833%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Re-open ticket 25192

[Markus Holtermann]

Yeah, reopening and fixing in 1.11 sounds worth the effort. Thanks Shai!

/Markus

On Sun, Jan 29, 2017 at 02:12:49AM -0800, Florian Apolloner wrote:



On Sunday, January 29, 2017 at 12:02:21 AM UTC+1, Shai Berger wrote:


I suggest that we re-open this ticket and solve it in the 1.11.x branch.



Seems sensible, go ahead

--
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/e984d61f-45bc-4620-a10f-91bf1113979c%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/20170129160635.GB5396%40inel.local.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Authenticating with Django without the password being sent to the server

[Markus Holtermann]

That's as correct, Anthony. Any you then want to hash the hash so that
you can't just login knowing the hashed password when the database is
leaked. Essentially you haven't won anything.

Second, how do you make sure the JavaScript is properly transmitted and
doesn't contain any code that sends off the credentials anywhere else?
TLS encrypted connections? Well, then I trust the encryption and can
just send the plain-text password. Or I don't trust the encryption and
I'm screwed either way.

/Markus

On 01/14/2017 07:32 PM, Anthony King wrote:
> Chris, then the password is the hash itself. It doesn't really have any
> security benefits.
> 
> Disclaimer: I'm not a security expert
> 
> On 14 Jan 2017 18:24, "Chris Priest"  wrote:
> 
>> The way django's authentication system works is that when you register,
>> you send the password to the server, then the server runs that password
>> through some hashing algorithms, then the resulting hash is stored in the
>> database. When the user logs in, the password again is sent to the server,
>> and the hash is calculated and then compared to the hash that was
>> calculated when they registered.
>>
>> This results in the plain text password not being stored in the database,
>> but the password is still being sent back to the server. A better way would
>> be for the hash to be calculated on the front end, in javascript, and then
>> sent back to be stored in the database. This way, the user *knows for sure*
>> that the password isn't being saved in plain text because the server
>> doesn't even know the plain text password.
>>
>> Has anyone ever tried building an authentication system that worked this
>> way? If someone built such a thing, could it get included in django contrib?
>>
>> --
>> 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/440694cb-853e-4150-a356-
>> 1f176f59b3c7%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/81461daa-0eae-06e2-fd60-ea0c6e30fb04%40markusholtermann.de.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Consider reverting or adding guidelines on how to use class based views for security sensitive features

[Markus Holtermann]

Hi all,

As it turned out [1], due to their complexity, using class-based generic 
views for security-sensitive functionality can result in unintended 
behavior. Essentially, the reset token was only checked on GET requests, 
not on POST. This was due to the check being in `get_context_data()` (which 
is only called on GET but not POST except for invalid forms) and not higher 
up the stack. Validation could happen in the SetPasswordForm but doesn't 
really belong there either. The form is being used by the admin to allow 
superusers to change other users' password. Also, password resets could 
probably happen via other ways that want to leverage a form that doesn't 
require a token. In the end, from my perspective the check for the correct 
token does belong in the view.

While the reported issue was fixed [2] it raises the question if the added 
functionality of class-based generic views is worth the danger of shooting 
ourselves in the foot. I see the benefits of GCBVs. But given that the 
reported issue stayed unnoticed for 4 months makes me think that those 
views are not the best for these use cases and easily underpin the security 
functionality. Hence I suggest to revert the patch (including all 
additional features they gained) unless they are integrated in the 
function-based views and add guidelines on how to use class-based generic 
views for security sensitive feature.

This is the thread to get the discussion about this started.

One thing I want to suggest regardless if the class-based generic views are 
removed again or not, is to hold off the deprecation of the function-based 
views. This allows users who feel the same to not use class-based generic 
views without having deprecation warnings. At least until the next LTS 
release.

Furthermore, myself and Florian Apolloner, who discovered the issue, are 
leaning +0 to +1 on the revert of the class-based views.

Cheers,

Markus Holtermann

[1] 
https://www.djangoproject.com/weblog/2016/nov/21/passwordresetconfirmview-security-advisory/
[2] https://github.com/django/django/pull/7591

-- 
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/19b675f5-c25a-43e8-ac73-2a31b9e351d6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: disclosing security release dates on django-announce

[Markus Holtermann]

While we haven't decided of any particular format, you can expect the 
announcements to look a bit 
like 
https://mta.openssl.org/pipermail/openssl-announce/2016-September/76.html

/Markus

On Friday, October 7, 2016 at 4:58:00 PM UTC+2, Tim Graham wrote:
>
> The Django team proposes [0] to add the following to the security policy:
>
> Approximately one week before public disclosure, ...
> we notify django-announce [1] of the date and approximate time of the
> upcoming security release. No information about the issues is given. This 
> is to 
> aid organizations that need to ensure they have staff available to handle 
> triaging our announcement and upgrade Django as needed.
>
> [0] https://github.com/django/django/pull/7356
> [1] 
> https://docs.djangoproject.com/en/dev/internals/mailing-lists/#django-announce
>
> Feedback is welcome.
>

-- 
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/0e0ce8fc-3a99-448c-92c6-907052b30b97%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Markus Holtermann]

Thanks for your update, Tom!

1. I think `route` is used in Django Channels (haven't looked it up. Not
a real issue but something to think about). I'd prefer `path` instead.

2. Too much magic for my taste. I like the explicit name `typed_url`
though (if we stick with `url` as opposed to `path` as per 1.). So
either `regex_url` and `typed_url` or `regex_path` and `typed_path`.
Either one with a import chim for `django.conf.urls.url` to point to
`regex_url` or `regex_path`.

3. Consider me -0 to -1 on deprecating `url()`. If we "rename" `url` to
`path` I'd rather see the docs updated and have a chim around for _a
while_. It's unnecessary work for every user to fix this in _every_
Django project.

/Markus

On Tue, Oct 04, 2016 at 02:17:00AM -0700, Tom Christie wrote:

Some possibilities:

1. Use a different name for the new function.

   path('/users//')

Actually `path` is pretty valid as a name there - that's *exactly* what it
represents - the path portion of the URL.
Alternately `route`?

2. Keep `url` for both styles, but with a really simple determination
between regexs/typed urls.

   The pattern *must* start with either `^` or `/`.  (Include a
`regex_url` and `typed_url` for the explicit cases)

3. As per (2) but additionally have the usage of regexs in `url(...)` be
placed on the deprecation path.

I think (1) is probably my favorite choice of those, but I'm open to
discussion.
That'd give us `from django.conf import path`, and `from django.conf import
regex_path`. The existing `from django.conf.urls import url` would keep the
existing behavior but move towards deprecation.

I'm very strongly in favor of keeping Flask's style for "".
Considering the wider ecosystem, the choice between having Python's two
biggest web frameworks share the same routing syntax vs. having them share
subtly different syntaxes is pretty clear.
I think that's a far bigger concern that if the routing syntax echos
Python's type hinting syntax or not.

To me, the alternative reads like this:

A: "Hey folks! Django's got a new routing sytnax!"
B: "Great what's it like?"
A: "Exactly the same as Flask. Oh, but we've reversed two of the arguments
around."
B: "Uh, WTF?"

Cheers for the input everyone,

 Tom



--
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/20161004092630.GC2270%40inel.local.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: DEP pre-proposal for a simpler URLs syntax.

[Markus Holtermann]

Hi y'all,

On Tue, Oct 04, 2016 at 08:15:45AM +0200, Aymeric Augustin wrote:

I agree that different names would be better. I wouldn’t use the word
“simple” since many “simple” things grow and become less simple in the
long run. SOAP stands for Simple Object Access Protocol… For this
reason url() and regex_url() have my preference.


By all means, if we can find another prefix that's not "simple" I'm all
in. I believe it will be too confusing for people who have used Django
for years to get used to the rename of regex_url to url, especially if
you can import two `url()` functions from different places where one is
a chim for the old regex-y function and one is the new flask-y function.


I’m in favor of the  order because I believe that
“consistency with Python” is a stronger argument than “consistency with
Flask”, but I have to admit that I never made significant use of Flask.


I somewhat disagree. I think we shouldn't make switching between Flask
and Django more annoying than necessary in that we swap the ordering in
which the parameter types are defined in URLs.

The Python syntax for type hints feels different for me by the very
nature of "being Python code" whereas the URL definitions are "just
strings"

/Markus


--
Aymeric.


On 04 Oct 2016, at 00:11, Markus Holtermann <i...@markusholtermann.eu> wrote:

Thanks for the draft, Tom. I'm a bit concerned that the different
`url*()` functions you can import will become confusing. Can we have
`regex_url()` (with chim for `url()`) -- as proposed -- and
`simple_url()` instead?

/Markus

On Mon, Oct 03, 2016 at 02:34:58PM -0700, Tom Christie wrote:

Okay then, I've made some updates:

* Updated the import design, in line with Jacob's suggestion.
* Brief note on URL conventions, and the leading '/'.
* Section on guarding against errors between `from django.conf.urls import
url` and `from django.urls import url`.
* Brief note on the internal RegexURLPattern API.
* Breakout of required implementation tasks.

Also, wrt Ryan's suggestion of reversing the ordering of name and type:
I've some sympathy towards it, but I believe that presenting a consistent
API between both Flask and Django is a more important factor.

Cheers all,

Tom

--
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/6a75cb7d-6df2-45e7-8efe-6c2f0526cfbe%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/20161003221128.GB23889%40pyler.local.
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/DF8D81E2-7370-494C-90E4-E28E0A9B3897%40polytechnique.org.
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/20161004075413.GD23889%40pyler.local.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: DEP pre-proposal for a simpler URLs syntax.

[Markus Holtermann]

Thanks for the draft, Tom. I'm a bit concerned that the different
`url*()` functions you can import will become confusing. Can we have
`regex_url()` (with chim for `url()`) -- as proposed -- and
`simple_url()` instead?

/Markus

On Mon, Oct 03, 2016 at 02:34:58PM -0700, Tom Christie wrote:

Okay then, I've made some updates:

* Updated the import design, in line with Jacob's suggestion.
* Brief note on URL conventions, and the leading '/'.
* Section on guarding against errors between `from django.conf.urls import
url` and `from django.urls import url`.
* Brief note on the internal RegexURLPattern API.
* Breakout of required implementation tasks.

Also, wrt Ryan's suggestion of reversing the ordering of name and type:
I've some sympathy towards it, but I believe that presenting a consistent
API between both Flask and Django is a more important factor.

Cheers all,

 Tom

--
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/6a75cb7d-6df2-45e7-8efe-6c2f0526cfbe%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/20161003221128.GB23889%40pyler.local.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Migration Questioner and String-Type Fields

[Markus Holtermann]

Thank you for your input, Jarek.

Assuming I have an existing model, adding

   models.CharField(blank=True, max_length=150)

to it, doesn't invoke the questioner on current master. Changing this
field to

   models.CharField(max_length=150)

doesn't call the questioner either.

Looking at the SQL Django generates, the first change results in

   ALTER TABLE "example_mymodel" ADD COLUMN "name2" varchar(150) DEFAULT '' NOT 
NULL;
   ALTER TABLE "example_mymodel" ALTER COLUMN "name2" DROP DEFAULT;

and the second in a noop.

I'm trying to understand what change you're proposing in order to figure
out if going forward with your proposal is something we should do.

Cheers,

Markus

On Sun, Sep 11, 2016 at 05:08:38AM -0700, Jarek Glowacki wrote:

Mm, convenience over strict correctness. Perhaps all that's needed is a
slight rephrasing of the prompt and we can have both?

Adding field with no `blank=True` and no `null=True`:

You are trying to add a non-nullable field '%s' to %s without a default; we
can't do that (the database needs something to populate existing rows).
[provide default | cancel]

Removing `null=True` from field:

You are trying to change the nullable field '%s' on %s to non-nullable
without a default; we can't do that (the database needs something to
populate existing rows). [provide default | fix later | cancel]

Removing `blank` from field:

?? (I only skimmed the code; not sure if this even opens up questioner)


This kind of implies to the user that they're doing something wrong. Maybe
if, for string fields, it read something more along the lines of:

You are adding/altering a field without setting `blank=True`. This will
populate existing rows with emptystring despite it being an invalid form
input. Are you sure? [yes | let me provide a one-time default for existing
rows | cancel]


So basically changing "you can't do this!" (exception-esque) to "are you
sure you want this?" (warning-esque).

Anyway I think I'll leave it here. I've exhausted my discussion points now,
and you already resolved my particular use case back in the ticket, so I no
longer feel so strongly about this to continue trying to push for a change
(though am willing to submit a PR if any of the suggested changes are
approved).

Cheers,


On Saturday, September 10, 2016 at 10:08:27 AM UTC+10, Tim Graham wrote:


Sure, but I don't think that use case should take priority. It's not much
work to type an empty string into the questioner if that's what you want.
If we remove the prompt, it's significantly more work (editing a migration
file or using RunPython) for a developer to set a non-empty value.

On Friday, September 9, 2016 at 7:19:37 PM UTC-4, Jarek Glowacki wrote:


Instances created afterwards, via `MyModel.objects.create()`, with this
field unset won't pass form validation either.
The use case is where this field is not expected to appear on a Django
form.

On Friday, September 9, 2016 at 11:58:38 PM UTC+10, Tim Graham wrote:


If blank=False, then a new column with a non-blank value means that all
existing objects won't pass form validation. Therefore, I don't see why a
prompt for a value isn't helpful.

On Friday, September 9, 2016 at 6:42:02 AM UTC-4, Jarek Glowacki wrote:


I made a rant/ticket regarding the hidden usage of `blank` here: #27197
.

In short, I don't think that `blank` should dictate whether or not the
migration questioner runs.
Building on this, I don't think it should run for for string-type
fields at all. If they have `default` set, use that for existing rows. Else
if they have `null=True`, set existing rows to `NULL`. Else, set existing
rows to empty string.

See linked rant/ticket for some (hopefully) compelling arguments..

Thoughts?





--
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/60bf1464-7e70-41c4-b8de-b201af84b4b7%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/20160912092451.GB17876%40inel.local.
For more options, visit 

Re: Migration Questioner and String-Type Fields

[Markus Holtermann]

Thank you for your input, Jarek.
  
Assuming I have an existing model, adding
  
   models.CharField(blank=True, max_length=150)
  
to it, doesn't invoke the questioner on current master. Changing this field 
to
  
   models.CharField(max_length=150)
  
doesn't call the questioner either.
  
Looking at the SQL Django generates, the first change results in
  
   ALTER TABLE "example_mymodel" ADD COLUMN "name2" varchar(150) DEFAULT '' 
NOT NULL;
   ALTER TABLE "example_mymodel" ALTER COLUMN "name2" DROP DEFAULT;
  
and the second in a noop.
  
I'm trying to understand what change you're proposing in order to figure 
out if going forward with your proposal is something we should do.
  
Cheers,
  
Markus

On Monday, September 12, 2016 at 12:08:39 AM UTC+12, Jarek Glowacki wrote:
>
> Mm, convenience over strict correctness. Perhaps all that's needed is a 
> slight rephrasing of the prompt and we can have both?
>
> Adding field with no `blank=True` and no `null=True`:
>
> You are trying to add a non-nullable field '%s' to %s without a default; 
> we can't do that (the database needs something to populate existing rows). 
> [provide default | cancel]
>
> Removing `null=True` from field:
>
> You are trying to change the nullable field '%s' on %s to non-nullable 
> without a default; we can't do that (the database needs something to 
> populate existing rows). [provide default | fix later | cancel]
>
> Removing `blank` from field:
>
> ?? (I only skimmed the code; not sure if this even opens up questioner) 
>
>
> This kind of implies to the user that they're doing something wrong. Maybe 
> if, for string fields, it read something more along the lines of:
>
> You are adding/altering a field without setting `blank=True`. This will 
> populate existing rows with emptystring despite it being an invalid form 
> input. Are you sure? [yes | let me provide a one-time default for existing 
> rows | cancel]
>
>
> So basically changing "you can't do this!" (exception-esque) to "are you 
> sure you want this?" (warning-esque).
>
> Anyway I think I'll leave it here. I've exhausted my discussion points 
> now, and you already resolved my particular use case back in the ticket, so 
> I no longer feel so strongly about this to continue trying to push for a 
> change (though am willing to submit a PR if any of the suggested changes 
> are approved).
>
> Cheers,
>
>
> On Saturday, September 10, 2016 at 10:08:27 AM UTC+10, Tim Graham wrote:
>>
>> Sure, but I don't think that use case should take priority. It's not much 
>> work to type an empty string into the questioner if that's what you want. 
>> If we remove the prompt, it's significantly more work (editing a migration 
>> file or using RunPython) for a developer to set a non-empty value.
>>
>> On Friday, September 9, 2016 at 7:19:37 PM UTC-4, Jarek Glowacki wrote:
>>>
>>> Instances created afterwards, via `MyModel.objects.create()`, with this 
>>> field unset won't pass form validation either.
>>> The use case is where this field is not expected to appear on a Django 
>>> form.
>>>
>>> On Friday, September 9, 2016 at 11:58:38 PM UTC+10, Tim Graham wrote:

 If blank=False, then a new column with a non-blank value means that all 
 existing objects won't pass form validation. Therefore, I don't see why a 
 prompt for a value isn't helpful.

 On Friday, September 9, 2016 at 6:42:02 AM UTC-4, Jarek Glowacki wrote:
>
> I made a rant/ticket regarding the hidden usage of `blank` here: 
> #27197 .
>
> In short, I don't think that `blank` should dictate whether or not the 
> migration questioner runs.
> Building on this, I don't think it should run for for string-type 
> fields at all. If they have `default` set, use that for existing rows. 
> Else 
> if they have `null=True`, set existing rows to `NULL`. Else, set existing 
> rows to empty string.
>
> See linked rant/ticket for some (hopefully) compelling arguments..
>
> Thoughts?
>


-- 
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/05deaeaf-49da-4b07-9641-8a996863960b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PEP 484 type hinting in Django

[Markus Holtermann]

Hi Alex,

I haven't heard of any discussion on that topic. I'd certainly like to
have a DEP before we start implementing it, though.

Cheers,

Markus

On Wed, Aug 17, 2016 at 04:08:29AM +, Alexander Hill wrote:

Hi all,

I like the plan to include PEP 484 type hinting in Django, outlined in the
PyCharm promotion blog post. [1]

Has this proposal been fleshed out much? Is there any extra information
available anywhere that I've missed? I think this will be great for Django,
and I'd happily contribute to the effort.

Cheers,
Alex

[1]
https://www.djangoproject.com/weblog/2016/jun/30/pycharm-and-django-fundraiser/

--
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/CA%2BKBOKzHPhsqeZGF4ebcc2eCuMjpSsN4MfWFAMxzFXjU%3D2-isw%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/20160817051224.GE1856%40inel.local.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: status of 1.10 release blockers

[Markus Holtermann]

Thank you for the update, Tim.

#26888 will be taken care of by tomorrow. Either Marten or I are pushing
a PR.

Cheers,

/Markus

On Thu, Jul 14, 2016 at 06:41:51AM -0700, Tim Graham wrote:

I'm planning for the release candidate on Monday.

The one blocker is #26888  -
RegexURLResolver doesn't work in threaded environments.

On Tuesday, June 21, 2016 at 4:29:47 PM UTC-4, Tim Graham wrote:


The blocker is merged so I'll release the beta in a couple hours if no one
stops me.

On Monday, June 20, 2016 at 9:10:12 PM UTC-4, Tim Graham wrote:


The remaining blocker:

UserCreationForm doesn't call normalize_email and normalize_username
https://code.djangoproject.com/ticket/26719
Status: I sent some final edits to the PR and it should be ready for
commit tomorrow.

Other possible blockers:

Different manager for _base_manager and related descriptors
https://code.djangoproject.com/ticket/26749
django-hvad is broken by the manager inheritance refactor and it's
unclear if it can be adapted for the new behavior.

Update decorator_from_middleware() to work with DEP5 style middleware.
https://code.djangoproject.com/ticket/26626
Design decision needed, see
https://groups.google.com/d/topic/django-developers/hNQIaYcN3xM/discussion

As long as no new issues pop up by tomorrow, I'm thinking to do the beta
release then. We might consider a "beta 2" release around 2 weeks later if
we decide to push fixes for the other two issues.

On Saturday, June 18, 2016 at 8:05:32 PM UTC-4, Tim Graham wrote:


I'm postponing the release until next week as some release blockers
remain:


https://code.djangoproject.com/query?status=!closed=Release%20blocker

On Friday, June 17, 2016 at 5:33:04 PM UTC-4, Claude Paroz wrote:


Le vendredi 17 juin 2016 16:52:50 UTC+2, Tim Graham a écrit :


There are a few small issues to finish up, but if all goes well, the
beta release will happen sometime tomorrow (at least 24 hours from now).



I'm a bit worried about https://code.djangoproject.com/ticket/26719
which could have security implications for 1.10. To be investigated...

Claude





--
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/94dd42e9-6940-4377-bd8e-7b285d0a63bc%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/20160714140527.GC5382%40inel.local.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Possible Bug in RegexURLResolver

[Markus Holtermann]

Thanks everybody!

While Aymeric's sounded great, your reasoning sounds even better,
Marten. Thanks!

Do you want to provide a PR for that, Marten?

Cheers,

/Markus

On Thu, Jul 14, 2016 at 06:47:15AM -0700, Marten Kenbeek wrote:

Using a singleton means that everything is cached for the lifetime of the
process after the resolver has been populated. The thread-local is so that
concurrent calls to _populate() can correctly determine if it is a
recursive call within the current thread. _populate() is called *at most*
once per thread for each language. If one thread finishes populating before
another thread starts, that second thread can access the thread-independent
cache and won't have to populate the resolver again.

On Thursday, July 14, 2016 at 3:15:43 PM UTC+2, Cristiano Coelho wrote:


If you are using locals it means each thread will always end up calling
the actual populate code? Is there any point for the RegexURLResolver class
to be a singleton then?


El jueves, 14 de julio de 2016, 9:12:54 (UTC-3), Marten Kenbeek escribió:


It's not quite as simple. Concurrency is actually not the main issue
here. The issue is that self._populate() only populates the app_dict, 
namespace_dict
and reverse_dict for the currently active language. By short-circuiting
if the resolver is populating, you have the chance to short-circuit while
the populating thread has a different active language. The short-circuiting
thread's language won't have been populated, and that will result in the
above KeyError.

The issue that self._populating is solving is that a RegexURLResolver can
recursively include itself if a namespace is used. Namespaces are loaded
lazily on first access, so this would generally not result in infinite
recursion. But, to include all namespaced views in self._callback_strs,
you need to load them immediately. self._populating prevents infinite
recursion in that specific case.

On a side note: recursively including the same resolver is possible under
some limited circumstances, but so far I've only seen it happen in the
Django test suite, and it doesn't even work if you don't include at least
one namespace between each recursive include. It's an edge-case scenario
that can be solved better by using a repeating pattern in your regex. I
don't think that it provides any value, but it does significantly
complicate the code. Removing this accidental "feature" would solve the
issue as well, without complicating the code any further.

Now, to solve the issue within the constraints of the current test suite,
you only need to prevent that self._populate() is called twice on the
same object within the same thread. A simple thread-local object should do
the trick:

class RegexURLResolver(LocaleRegexProvider):
def __init__(self, regex, urlconf_name, default_kwargs=None,
app_name=None, namespace=None):

...

self._local = threading.local()
self._local.populating = False
...

   def _populate(self):
if self._local.populating:
return
self._local.populating = True
...
self._local.populating = False


This will work concurrently, because all lists (lookups, namespaces, apps)
are built up in local variables, and then set in
self._namespace_dict[language_code] etc. as an atomic operation. The
worst that can happen is that the list is overwritten atomically with an
identical list. self._callback_strs is a set, so updating it with values
that are already present is not a problem either.


Marten


On Wednesday, July 13, 2016 at 12:22:36 AM UTC+2, Cristiano Coelho wrote:


Keep in mind your code guys is semantically different from the one of
the first post.

In the first post, the _populate method can be called more than once,
and if the time window is long enough, the two or more calls will
eventually run the # ... populate code again, but on your code, the
populate code will only be called once doesn't matter how many times you
call _populate, unless the populated variable is restarted somewhere else.
So I don't know how is this exactly used but make sure to check it

El martes, 12 de julio de 2016, 14:58:12 (UTC-3), Aymeric Augustin
escribió:


On 12 Jul 2016, at 19:46, Florian Apolloner  wrote:


On Tuesday, July 12, 2016 at 9:25:37 AM UTC+2, Aymeric Augustin wrote:


Can you check the condition inside the lock? The following pattern
seems simpler to me:



The standard pattern in such cases is to check inside and outside.
Outside to avoid the lock if you already populated (the majority of
requests) and inside to see if another thread populated it in the time you
waited to get the lock…


Yes, actually that’s what I did the last time I implemented this
pattern, in Apps.populate.

--
Aymeric.





--
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 

Re: Possible Bug in RegexURLResolver

[Markus Holtermann]

Hey,

thanks for posting this here. I opened
https://code.djangoproject.com/ticket/26888 to keep track of this. Can I
get somebody with threading experience in Python tell me if your
proposed patch makes sense?

Also, I marked this as a release blocker for 1.10 as I introduced this
during a patch for another issue
https://code.djangoproject.com/ticket/24931

/Markus

On Sun, Jul 10, 2016 at 11:47:35PM -0700, a.bra...@rataran.com wrote:

Hello everyone.

As suggested by Markus on django-users group, I'm posting this here too.

---

I'm using django (1, 10, 0, u'beta', 1).

When I try to reverse url in shell everything goes fine.

When under nginx/uwsgi with many concurrent request I get

... /local/lib/python2.7/site-packages/django/urls/resolvers.py", line 241,
in reverse_dict
   return self._reverse_dict[language_code]
KeyError: 'it'

After a wile I figured out that RegexURLResolver is memoized by
get_resolver and so it acts like a singleton for a certain number of
requests.

Analyzing the code of  RegexURLResolver I found that the method _poupulate
will return directly if it has been called before and not yet finished.

   ...
   def _populate(self):
   if self._populating:
   return
   self._populating = True
   ...

if used for recursive call in a single thread this will not hurt, but in my
case in uwsgi multi thread mode I got the error.

here is my quick and dirty fix:

class RegexURLResolver(LocaleRegexProvider):
   def __init__(self, regex, urlconf_name, default_kwargs=None,
app_name=None, namespace=None):

   ...

   self._populating = False
   self.RLock = threading.RLock()

   ...

  def _populate(self):
   if self._populating:
   self.RLock.acquire()
   self.RLock.release()
   return
   self._populating = True
   self.RLock.acquire()

   ...

   self._populating = False
   self.RLock.release()


Does anyone know if there is a better solution?

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/308c7d89-27e5-4841-85b1-55b0584cef3b%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/20160711204150.GE11144%40inel.local.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Discussion related to ticket #26822 (new migrations, --keepdb and --parallel option)

[Markus Holtermann]

Hi,

it might be a shot in the dark, but can't we check if Django's
testrunner applied new migrations in which case we drop the cloned
databases and recreate them. If all migrations already existed we keep
the clones the way they are?

/Markus

On Tue, Jul 05, 2016 at 09:00:25AM +0200, Aymeric Augustin wrote:

Hello,

I’ll try to clarify what I said in the PR below..

The main reason for the `--parallel` option was to make Django’s own test suite 
faster. A full run went down from ~8m to ~1m30 when I committed that patch, 
which really helps the development cycle on invasive patches.

Since Django’s own test runner bypasses migrations, whenever you make changes 
to a model in Django’s test suite, you need a run without `--keepdb`. So the 
problem you’re describing doesn’t exist for the primary use case.

Now let’s talk about models and migrations in users’ projects, which is the 
logical next step and the use case you’re trying to improve.

Note that the `--parallel` option is experimental and often non-functional in 
this context: as soon as two tests hit a resource other than the database — 
say, the cache — they can stomp upon one another.


On 05 Jul 2016, at 00:22, Romain Garrigues  
wrote:

We could have just documented this limitation, but I don't think that my 
situation is a really rare edge case in terms of process, so I was suggesting 
to add a new option to be able to reset the cloned databases if needed (let's 
name it --parallel-clone-reset).


When I make changes to models, usually I keep removing and recreating a single 
migration, which is incompatible with using the `--keepdb` option. Whenever I 
make changes, I run without `--keepdb` once.


I don't really like the idea of adding a new option, as it impacts the test 
runner, the clone_test_db function signature, ... but I have not found a better 
idea to at the same time keep the performances with --keepdb and --parallel, 
and handle these newly added migrations to a project.


I’m not a fan of a new option either…


To summarize my proposal, this option (--parallel-clone-reset, or any other 
name) should be used only if you are using --keepdb and --parallel options at 
the same time, and when you have added a new migration between 2 test run.


IIRC this will more than double the run time of Django’s own test suite on 
MySQL: it will increase from ~2m to ~4m (give or take 30s) because cloning 
databases is slow on MySQL.

I’m quoting all these figures from memory and I may mix them up. As I said on 
the ticket it would be useful to redo the benchmark on a first run and 
subsequent run of `./runtests.py` on PostgreSQL and MySQL.

You could argue that it’s best to degrade the experience of a few Django 
contributors (original use case, Django’s test suite) for the benefits of the 
wider community (new use case, projects’ test suites). However the original use 
case is known to work and I don’t believe that the new use case works well 
enough in general, at least not without some engineering to isolate tests from 
one another. For this reason I’m not convinced by this argument.

I hope this clarifies the context of the trade-off we’re discussing.

Best regards,

--
Aymeric.

--
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/BD5FB0D4-C9E1-4681-A5A1-CCD6D6BB84B7%40polytechnique.org.
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/20160705114828.GA3506%40inel.local.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: change commit message format to present tense?

[Markus Holtermann]

I don't mind either way. If everybody seems to use present tense these
days, yeah, let's do that as well. As long as the general style of the
commit messages stays: Fixes|Refs #12345 -- Make it work

My 2¢

/Markus

On Fri, Jun 24, 2016 at 11:04:39AM -0600, Jacob Kaplan-Moss wrote:

I'm not entirely sure because my memory sucks, but odds are that I started
the current standard of using past-tense.

FWIW I no longer care even at all, I think as long as commit messages are
clear we I don't care what tense they are. Following the standard git way
seems totally OK to me.

Jacob

On Fri, Jun 24, 2016 at 10:59 AM, Carl Meyer  wrote:


On 06/24/2016 10:55 AM, Tim Graham wrote:
> A few contributors indicated in #django-dev that it could be beneficial
> to change our commit message format to match git's guidelines of present
> tense (instead of our current past tense convention) as it would be one
> less thing to remember when contributing to Django. Besides consistency
> with the current history, do you feel there are any benefits in
> continuing to use past tense instead of present tense?

I was one of those contributors in #django-dev. Not only are past-tense
commit messages non-standard for git (meaning they are one more thing a
new contributor is likely to trip over), I also personally find them
harder to write and make clear. Sometimes in a commit message you need
to reference past (pre-commit) behavior and make it clear how the commit
changes that behavior. I occasionally find that harder to do clearly
when the entire commit message is supposed to worded in the past tense.

So I find all the advantages (except for consistency with past history)
in favor of switching to the imperative mood.

Carl

--
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/576D6702.3080501%40oddbird.net
.
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/CAK8PqJESDrr05-1jJeTbz8UQ%3D%2BJXYHU88w1iGBBnby5czwwVSA%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/20160624172521.GF12981%40inel.local.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Django Integration

[Markus Holtermann]

What about having asgiref and daphne as optional dependencies instead of
hard once and raising a proper exception "please install ..." when the
import fails?

```
try:
   from asgiref import ...
except ImportError:
   raise ImportError(
   "Please ensure you installed asgiref to use this feature. Do so "
"with `pip install Django[channels]"
   )
```

i.e. `pip install "Django[channels]"` ?

/Markus

On Wed, May 04, 2016 at 09:38:33AM -0700, Andrew Godwin wrote:

On Wed, May 4, 2016 at 8:26 AM, Mark Lavin  wrote:


As noted in the PR there is at least one new setting,
CHANNEL_SESSION_ENGINE, which is lacking documentation.



That's been added now.



The notes on deployment for "Running ASGI under WSGI" don't give any
motivation why you would want to do this given that it doesn't support
websockets in this case. Is there any advantages? Disadvantages?



It lets you still have background tasks and non-WebSocket interface servers
(or run websocket interfaces separately). I've expanded the docs to say
this.




There are tests for the routing and request handling but there are no
unittests that I can see for the auth/session handling,



Yes, these are missing.



Channel/Message/Group/ChannelLayerManager/custom JSON encoder classes and
their usage,



The ASGI conformance test suite takes care of this:
https://github.com/andrewgodwin/django/blob/channels/tests/channels_tests/test_database_layer.py#L3
(that's also used for the inmemory module and asgi_redis in their test
suites)



or the worker/runworker code.



What would you suggest these tests look like? They can't spin up a worker
and fire requests at it, and most of the worker code is interactive.



The changes to runserver aren't tested.



Runserver in Django only has a single test, presumably for the same reason;
I don't know how I can write a test for this considering the autoreload and
extra process mechanisms we'd want to cover.



The new test utilities aren't tested either (yes that's a thing).



I would say that the usage of those utilities in other tests means they are
tested sufficiently, given that they're used sufficiently; writing a test
for just the channel test case would look very similar to the basic tests
elsewhere.



All new code should have tests. Isn't that Django's current standard?



There's no clear standard, the docs just say the tests should "exercise all
of the new features". I admit that auth/session needs tests - I'll get
those done this week - but I don't see how we can reasonably test the
interactive commands in an automated fashion given the current test harness
(and lack of tests for things like runserver) in Django.




asgiref has one "basic" test around WSGI handling which the usage is
documented in this change. I don't think anyone would dare say that covers
potential edge cases in WSGI/HTTP handling. Not test related, the status
code map is also missing many HTTP status codes.



The WSGI handling part of asgiref is not considered complete, and I will
probably remove the section about using it in the main Django docs. Only
the inmemory backend should be considered used by Django.




I'm not in favor of on leeway for external dependencies for the reason you
note: they are in the install_requires. Django has avoided having required
dependencies and I don't think it sets a good precedent to have the first
set be those which don't meet the quality standards expected by the
community. That is they don't have sufficient docs/tests to be include in
Django itself. It isn't clear why these are required if you are claiming
that they aren't required to run. If these we're in the install_requires
then I would withdraw the objections about them with regard to this change
in Django.



With a change I'm going to make, Django will depend on these in
install_requires but not actually use them until you try and use a channels
feature; they're in install_requires out of user convenience (having a
traceback the first time you use the new built-in Django feature seems
bad). Considering we're launching Channels in 1.10 as a "provisional"
feature, my opinion would be that we can go slightly easier on these
dependencies (but of course I'm biased)

Andrew




On Wednesday, May 4, 2016 at 10:26:22 AM UTC-4, Andrew Godwin wrote:



On Wed, May 4, 2016 at 6:15 AM, Mark Lavin  wrote:


I had assumed this was still a work in progress because there are
missing tests and some documentation. The build is passing but the unittest
coverage for the new modules seems low or at least not up to the standards
I expect for Django contributions. The same for the daphne and asgiref
packages which are new requirements. In previous discussions there were
talks about performance benchmarks to track potential regressions before
this would be accepted similar to the template-based widget rendering
change. I don't see any references here or in this work. What is the status
of those?



- The 

Re: Django website ssl-certificate expired

[Markus Holtermann]

A post-mortem is at 
https://groups.google.com/forum/#!topic/django-developers/7qzh2n3ZDRc

Cheers,

/Markus

On Wednesday, May 4, 2016 at 11:51:08 AM UTC+2, Marc Tamlyn wrote:
>
> We are aware of the issue and are working on it.
>
> Thanks,
> Marc
>
> On 4 May 2016 at 10:30, Wim Feijen  
> wrote:
>
>> Hi guys,
>>
>> Apologies if I am posting in the wrong group, but the certificate of 
>> djangoproject.com expired today (4 May).
>>
>> Wim
>>
>> -- 
>> 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-develop...@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/e44c883b-41fc-4afb-8717-15c0f0f5dae2%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/09961b5c-429b-4949-8287-50c1e4b68ec3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: is_authenticated as property

[Markus Holtermann]

I haven't read the entire thread, did you account for custom user models
that don't inherit from AbstractBaseUser? Do the system checks stil
work? A Metaclass certainly would not, would it?

Cheers,

/Markus

On Thu, Apr 28, 2016 at 10:56:37AM -0700, Florian Apolloner wrote:

Are errors silence able via SILENCED_SYSTEM_CHECKS? If yes, I am against it
-- this has to be an hard unrecoverable error for security reasons or fully
backwards compatible (I am leaning towards the latter if possible in any
way).

On Thursday, April 28, 2016 at 5:01:04 PM UTC+2, Tim Graham wrote:


Do you think my suggestion of a system check to flag this is unacceptable?

diff --git a/django/contrib/auth/checks.py b/django/contrib/auth/checks.py
index d1b0a44..347ad75 100644
--- a/django/contrib/auth/checks.py
+++ b/django/contrib/auth/checks.py
@@ -73,6 +73,14 @@ def check_user_model(app_configs=None, **kwargs):
 )
 )

+if not isinstance(cls.is_anonymous, property):
+errors.append(
+checks.Error('%s.is_anonymous must be a property.' % cls)
+)
+if not isinstance(cls.is_authenticated, property):
+errors.append(
+checks.Error('%s.is_authenticated must be a property.' % cls)
+)
 return errors


On Thursday, April 28, 2016 at 10:25:01 AM UTC-4, Shai Berger wrote:


On Monday 11 April 2016 20:13:02 Florian Apolloner wrote:
> On Monday, April 11, 2016 at 6:57:46 PM UTC+2, Tim Graham wrote:
> > I cannot think of much we could do besides monkey-patching the
> > custom-user model.
>
> I would not call checking and rewriting the class in __new__
> monkey-patching, but…

I think this is what we must do in order to keep backwards-compatibility
while
resolving the issue.

If we don't resolve the issue, people will just keep using the method as
if it
were a property, opening themselves up in various ways;

If we just make it a property in the builtin classes, custom user classes
will
re-introduce the issue.

We can handle it in two ways, as far as I can see:

A) What Florian alluded to above -- give AbstractBaseUser a metaclass
which
replaces the methods with Aymeric's "CallableBool"s

B) Implement in AbstractBaseUser a __getattribute__ which, essentially,
does
the same thing when asked for the methods.

When idea which I discarded was to "force" the attributes to be used as
methods -- to use a callable which raises an exception when evaluated as
boolean. But this replacement suffers exactly the same problems as the
CallableBool replacement, unless also supported by "monkey patching"
techniques, and a CallableBool is much more user-friendly.

Have fun,
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/aa589a27-cb1d-4233-b942-9f40d8416185%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/20160428180722.GB20356%40inel.local.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Value of tightening URLValidator/EmailValidator regular expressions?

[Markus Holtermann]

On Mon, Mar 14, 2016 at 12:34:40PM -0700, Florian Apolloner wrote:



On Monday, March 14, 2016 at 8:08:09 PM UTC+1, Michael Manfre wrote:


Simple is better. Anyone who needs/wants something more complex is not
prevented by Django from doing so.



+1 to that and what the rest said ;)


+1

As mentioned already on the PR, I'd go with the HTML5 validator. That
way we at least don't invent another standard.

WRT the backwards compatibility issues:

1) You might be able to submit an email address that passes the new
regex but not the old one. --> not an issue from my perspective

2) You're not able to submit an email address that does not pass the new
validator but the old one. --> Unlikely, but when the new field is of
type="email" your rather modern browser will tell you before Django
anyway

/Markus





Regards,
Michael Manfre

On Mon, Mar 14, 2016 at 2:31 PM, Aymeric Augustin <
aymeric@polytechnique.org > wrote:


Indeed, for some reason, the URL and email validators get anywhere from 2
to 8 changes in every Django version, and there’s no end in sight. (I
contributed to this. Sorry.)

Like James, I’m in favor of making the validation much more simple and
documenting it. This seems better than perpetually modifying it at the risk
of introducing regressions.

--
Aymeric.

On 14 Mar 2016, at 19:17, James Bennett 
wrote:

Personally I've long been in favor of drastically simplifying the email
regex and essentially telling people that if they want to support
triply-nested comments in a bang-path address they can write their own :)

Is there an actual compelling reason to not just pare it down to "word
characters and/or some punctuation, followed by an @, followed by some more
word characters and/or punctuation"?

On Mon, Mar 14, 2016 at 11:09 AM, Tim Graham  wrote:


On a pull request that proposes to tighten the validation of
EmailValidator [0], Ned Batchelder questioned the usefulness of this:

"Can I respectfully suggest that continuing to tweak this complex regex
to get asymptotically closer to perfection is not worth it? Especially to
fix false positives. What real-world problem is happening because
"gmail.-com" is accepted? "gmail.ccomm" is also accepted, but is just as
useless as an email address."

Collin Anderson proposed:

"I think we should try to just match the standard html  validation. I'd imagine that most uses cases would want to
match that. We might be able to use the regex verbatim from the standard
itself:

​
https://html.spec.whatwg.org/multipage/forms.html#e-mail-state-(type=email
)
If people want to allow things outside of that they could use a custom
regex.
Though it gets more complicated when considering Unicode. Unicode needs
to get normalized to ascii before running through the official regex."

(Of course, this may be somewhat backwards-incompatible.)

What are your thoughts on this? I don't mind putting a halt to
enhancements to the validation as long as we can articulate a sensible
policy in the documentation.

[0] https://github.com/django/django/pull/5612

--
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-develop...@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/eb04034e-ea07-489f-aaf9-a08a5d241c4b%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-develop...@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/CAL13Cg8L6Gduwv4n%2BD68YqjEOmE1KWCKPPGnXjQr%2BR6a1HSSsA%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-develop...@googlegroups.com .
To post to this group, send email to django-d...@googlegroups.com
.
Visit this group at 

Re: Choosing migration with relative syntax

[Markus Holtermann]

Hi Joakim,

thank you for your proposal.

I don't think this is a good idea because you can easily accidentally undo 
too many migrations which would inevitably will result in data loss. You 
don't have the data loss problem in Git as you can always recover by using 
`git reflog` to go back and e.g. undo an incorrect rebase. However, when 
you remove a field from a database table the data is pretty much lost.

Cheers,

/Markus

On Friday, March 11, 2016 at 11:39:53 PM UTC+11, Joakim Saario wrote:
>
> Hello!
>
> Today if you just need to unmigrate the *n* migrations before the last 
> one you would
> typically run `migrate  --list` and then `migrate  
> ` where 
> `migration_name` is the migration you want to roll back to.
>
> To reduce the steps of this procedure i think it would be nice to introduce
> a syntax similar to how commits in for example git works. I.e `git show 
> HEAD^`
> for the previous commit and `git show HEAD~2` for the one before that.
> It would also be good to support the `git show (^+)|(~\d)` 
> variant
> of this to be able to choose the origin.
>
> For this to work good for the normal case, there need to be a magic word
> that maps to the latest migration available and/or the latest applied 
> migration.
>
> I can clearly see a use case for this as I can imagine that the most common
> operation besides applying all unmigrated migrations is to roll back *n* 
> migrations.
>
> Does this sounds like a good idea?
>

-- 
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/a096ca85-b9f1-42bb-a606-42d1d2978a66%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal on Custom Indexes - Google Summer of Code

[Markus Holtermann]

Hi Akshesh,

thank you for your proposal! Sounds like a good plan.

On Thursday, March 10, 2016 at 8:16:10 AM UTC+11, akki wrote:

Once the index is added to a model, the model can inject itself into the 
>> index, or the schema editor can use the originating model to get data it 
>> needs. No need to pass the model into the index type I think. Regarding the 
>> name, I'm unsure if I prefer a name=Index() or an Index(name='') approach. 
>> It'd be good to see that choice in your proposal with a couple of pros and 
>> cons.
>>
>
> Well, since we are defining these indexes in a list (to be stored in 
> Meta.indexes) I would go with the Index(name='') approach.
>

I'd prefer the Index(name='') approach

class MyModel(models.Model):
field1 = models.CharField()
field2 = models.CharField()

class Meta:
indexes = [
Index('field1', 'field2', name='some_index_across_two_columns'),
'field2',  # Would be the same as Index('field2'), an index on 
this one column -- name derived from field name: field2_index
Index(ToLower('field1')),  # A functional index on field1 -- 
name derived from field name and functions: field1_tolower_index
]

That way you should also be able to check for duplicate index names.
 

> 1) I don't think it's necessary to have an IndexTogether type. 
>> Index('field_a', 'field_b') should be sufficient I think. If it's not 
>> sufficient, call out why. I'm also in favour of translating any 
>> index_together definitions into appropriate Index types. Then SchemaEditor 
>> only needs to work with Index expressions and things remain simpler at the 
>> boundary between model definition and migrations.
>>
>
> My major concern was about the syntax. Would Index(['f1', 'f2']) mean two 
> indexes (for each field) or one multi-column index. Here we can do 
> something like Index(['f1', 'f2', ['f3', 'f4']]), each element of the list 
> corresponding to a new index.
>
Index(...) would create one index from my perspective. Thus 
Index('field_a', 'field_b') would do the same as 
index_together=(('field_a', 'field_b'),) these days.
Index(['f1', 'f2', ['f3', 'f4']]) looks way to confusing to me. That would 
probably be better Index('f1'), Index('f2'), Index('f3', 'f4')

Since we're talking about index_together, please keep unique_together in 
mind ;)

Cheers

/Markus
 

>
>
>> Of course, this is a great thing to have. But I wonder if we can do 
>> something to prevent pushing non-indexes to the indexes attribute of 
>> Meta. Having Meta.indexes = [CheckTypeConstraint(foo__in=['foo', 
>> 'bar'])] doesn't read correctly. 
>>
>
> Perhaps it would be best not to mix constraints and indexes. I would like 
> to know your thoughts on stopping to create indexes explicitly for unique 
> constraints because all database do that automatically because that only 
> gives a performance degradation as far as I know.
>
>
> On Wednesday, 9 March 2016 12:44:43 UTC+5:30, Anssi Kääriäinen wrote:
>>
>> If the CREATE INDEX part of the generated SQL isn't hard-coded 
>> somewhere outside the Index class, the exact same mechanism can be 
>> used to run other DDL commands, like ALTER TABLE  ADD 
>> CONSTRAINT check_type_choices CHECK (type IN ('foo', 'bar')); 
>>
>> Of course, this is a great thing to have. But I wonder if we can do 
>> something to prevent pushing non-indexes to the indexes attribute of 
>> Meta. Having Meta.indexes = [CheckTypeConstraint(foo__in=['foo', 
>> 'bar'])] doesn't read correctly. 
>>
>>  - Anssi 
>>
>> On Wed, Mar 9, 2016 at 4:20 AM, Josh Smeaton  
>> wrote: 
>> > Hi Akshesh, 
>> > 
>> > The proposal looks really good so far. I haven't gone through it in 
>> depth 
>> > though, but I'll set aside some time to try and do so. A few comments: 
>> > 
>> > - Using the schema editor rather than sqlcompiler is the right choice. 
>> > 
>> > - The earlier part of your proposal seems to focus on allowing postgres 
>> > users to define more complex indexes that they previously haven't been 
>> able 
>> > to use. Oracle is then highlighted also for allowing functional 
>> indexes. I 
>> > think one of the biggest "why's" of this project is to allow users to 
>> define 
>> > custom indexes. It doesn't matter what kind of index. They get access 
>> to the 
>> > stuff that creates them. That should be highlighted before all else. 
>> > 
>> > - Should the type of index (BTree, Spatial, etc) be an index type in 
>> and of 
>> > itself, or should it be a property of a specific index? My knowledge 
>> here is 
>> > limited, so I'm not sure if there are certain constraints on which kind 
>> of 
>> > indexes can use spatial/btree/partial storage types. If certain index 
>> types 
>> > are very heavily restricted, then it probably makes sense to highlight 
>> them 
>> > (as you've done) as a top level class rather than an attribute of 
>> indexes in 
>> > general. If most indexes can be arranged with different storage types 
>> > though, it'd 

Re: Making max_length argument optional

[Markus Holtermann]

>From what I understand you will have a hard time doing that at all:

On PG could go with a 'max_length=None' in a 3rd party app. But that 
wouldn't be supported on any other database backend. Which means you're 
limiting your app to PG. On the other hand you could make your app database 
independent by using a TextField which has pretty much the same performance 
on PG as a VARCHAR() and is available on other backends. But may perform 
bad on other backends. But there's no way to have a text of unlimited 
length on MySQL other than a TEXT column.

TL;DR: you can't achieve both ways anyway. Neither now nor if we change the 
behavior of Django's max_length attribute on CharFields.

/Markus

On Tuesday, March 1, 2016 at 11:00:29 AM UTC+11, Cristiano Coelho wrote:
>
> I find that using TextField rather than CharField just to make postgres 
> use varchar() is a terrible idea, if you are implementing an reusable app 
> and it is used on a backend like MySQL where TextFields are created as text 
> columns which are horribly inneficient and should be avoided at any cost 
> you will have a really bad time.
> I'm not sure about postgres but I want to believe that using varchar 
> without limits has also some performance considerations that should be 
> taken care of.
>
> El lunes, 29 de febrero de 2016, 17:58:33 (UTC-3), Shai Berger escribió:
>>
>> Hi, 
>>
>> Thank you, Aymeric, for summing up the discussion this way. The division 
>> into 
>> two separate problems is indeed required, and I fully support the idea of 
>> setting max_length's default to 100 or 120. 
>>
>> There seem to be just two points worth adding to your summary: 
>>
>> On Monday 29 February 2016 11:19:02 Aymeric Augustin wrote: 
>> > 
>> > 2) How can we make it easy for PostgreSQL users to just use VARCHAR()? 
>> > 
>> > Since this is a PostgreSQL-specific feature, having a variant of 
>> CharField 
>> > in django.contrib.postgres that supports and perhaps even defaults to 
>> > unlimited length shouldn’t be controversial. 
>> > 
>>
>> The first -- I believe it was raised very early on by Christophe Pettus 
>> -- is 
>> that Django already has a field that manifests on PG as VARCHAR(), and 
>> that is 
>> TextField. However, I don't like the idea that PG users should be using 
>> TextField(widget=TextInput) as a replacement for CharField; I find that 
>> counter-intuitive -- even if just because it is a "bad name". Names are 
>> important. 
>>
>> The second -- in response to a comment made by Josh Smeaton -- is that 
>> having 
>> django.db.models.CharField with default max_lenth=N (for some finite N) 
>> and 
>> django.contrib.postgres.CharField with default max_length=None (meaning 
>> infinity) sounds like a bad idea. 
>>
>> > 
>> > I hope this helps! 
>>
>> I'm certain it did! 
>>
>> 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/71e5e743-29bb-4dba-9bf4-6948ab2d1fa9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: remove old SVN branches from git repository?

[Markus Holtermann]

I'd like to keep them around somewhere. Even if it's just a wiki page
which links to the last commits of each branch.

When you have a local checkout of a brach that checkout is staying even
if the branch is removed on a remote. Also your local references to
remote branches are kept unless you call `git remote prune upstream`.
The branches in the remotes should still be available.

/Markus

On Wed, Feb 24, 2016 at 12:46:38PM -0800, Tim Graham wrote:

They're already in everyone's forks too unless you delete them. Not sure if
deleting them from the main repo would delete them for all forks too.

On Wednesday, February 24, 2016 at 3:36:53 PM UTC-5, Florian Apolloner
wrote:




On Wednesday, February 24, 2016 at 9:12:19 PM UTC+1, Shai Berger wrote:


If they're a nuisance, I suggest that we clone the Django repo into
another
one under the django organization -- say,  "django-historical-branches"
--
before removing them from the main repo.



I was about to suggest the same :D



--
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/ffceaa3b-ae34-4d2f-8ea2-7fa382b94a30%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/20160225001335.GA3849%40pyler.local.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: remove support for unsalted password hashers?

[Markus Holtermann]

Cheers Tim,

looks good to me, assuming the migration actually works :-], haven't tried 
it out. We probably should advice people that running that migration 
potentially takes a while, depending on how many passwords they need to 
update.

/Markus

On Friday, February 19, 2016 at 3:52:53 AM UTC+11, Tim Graham wrote:
>
> Feedback is welcome on the draft blog post. The links to the pull requests 
> will be replaced with links to the docs once those PRs are reviewed and 
> merged.
>
> Security advisory: Strengthening the password hashes in your database
>
> Summary: If you have MD5 or SHA1 password hashes in your database, here's 
> a way to update them without requiring all your users to login again.
>
> Body:
>
> Are the password hashes in your database strong enough to prevent them 
> from being cracked if your database is compromised?
>
> Django 0.90 stored passwords as unsalted MD5. Django 0.91 added support 
> for salted SHA1 with automatic upgrade of passwords when a user logs in. 
> Django 1.4 added PBKDF2 as the default password hasher.
>
> If you have an old Django project with MD5 or SHA1 (even salted) encoded 
> passwords, be aware that these can be cracked fairly easily with today's 
> hardware. Consider using a `wrapped password hasher <
> https://github.com/django/django/pull/6114>`_ to strengthen the hashes in 
> your database. Django 1.10 will `remove the MD5 and SHA1 hashers <
> https://github.com/django/django/pull/6103>`_ from the default 
> ``PASSWORD_HASHERS`` setting to force projects to acknowledge continued use 
> of a weak hasher.
>
> On Wednesday, February 17, 2016 at 1:24:04 PM UTC-5, Tim Graham wrote:
>>
>> To answer my own question, I did a little experiment and cracked about 
>> 10% of the SHA1 password hashes in the djangoproject.com database in 
>> minutes on my several year old PC.
>>
>> I think that's sufficiently weak to:
>> 1. Make a blog post recommending that projects upgrade using the 
>> instructions in [1] 
>> 2. Remove SHA1PasswordHasher from the default PASSWORD_HASHERS in Django 
>> 1.10 to force projects to explicitly acknowledge use of an insecure hash if 
>> they require it.
>>
>> [1] https://github.com/django/django/pull/6114
>>
>> On Wednesday, February 10, 2016 at 5:16:11 PM UTC-5, Tim Graham wrote:
>>>
>>> Is salted SHA1 sufficiently insecure to remove it from the default 
>>> PASSWORD_HASHERS or should we leave it for now? Any project created before 
>>> pbkdf2 was introduced in Django 1.4 (March 2012) will likely have some SHA1 
>>> hashes unless all their users have logged in since. I've written 
>>> instructions on how to upgrade such passwords without requiring all your 
>>> users to login [1]. If it's warranted, we could make a blog post advising 
>>> this. 
>>>
>>> [1] https://github.com/django/django/pull/6114 
>>> 
>>>
>>> On Monday, February 8, 2016 at 3:12:28 PM UTC-5, Tim Graham wrote:

 Thanks for the feedback everyone. I've created a few action items:

 https://code.djangoproject.com/ticket/26187 - Remove weak password 
 hashers from the default PASSWORD_HASHERS setting
 https://code.djangoproject.com/ticket/26188 - Document how to wrap 
 password hashers
 https://github.com/django/djangoproject.com/issues/632 - Use a wrapped 
 password hasher to upgrade SHA1 passwords

 On Saturday, February 6, 2016 at 3:56:00 AM UTC-5, Curtis Maloney wrote:
>
> I kept meaning to weigh in on this... but all my points have been 
> made. 
>
> It sounds like the middle ground is to: 
>
> 1) remove them from the default list 
> 2) keep them in the codebase 
> 3) make them noisy (raise warnings) 
> 4) provide docs/tools on how to upgrade 
>
> Then we get "secure by default" (1), as well as "encouraging upgrades" 
> (3), whilst also "supporting slow-to-update installs" (4), and 
> "encouraging best practices" (3). 
>
>
> -- 
> C 
>
>
> On 06/02/16 19:51, Aymeric Augustin wrote: 
> > Yes, that would be good from the “security by default” standpoint. 
> This 
> > would also allow us to trim the full list of hashers which is 
> repeated 
> > several times in the docs. 
> > 
> > -- 
> > Aymeric. 
> > 
> >> On 6 févr. 2016, at 00:03, Tim Graham  >> > wrote: 
> >> 
> >> I would guess most users aren't customizing the default list of 
> >> hashers, so I'd rather remove weak hashers from the 
> PASSWORD_HASHERS 
> >> setting and let anyone who needs to use a weak hasher define their 
> own 
> >> setting (at which point a warning probably isn't needed). Does that 
> >> seem okay? 
> >> 
> >> On Friday, February 5, 2016 at 3:20:41 PM UTC-5, Aymeric Augustin 
> wrote: 
> >> 
> >> 

Re: Migration Errors (fields.E300)

[Markus Holtermann]

Hi,

Can you please paste the migrations you created that refer to the Channel 
model. Make sure that those migrations depend on the redis_pubsub.0001_initial 
migration.

/Markus

On February 16, 2016 3:41:27 PM GMT+11:00, ayo...@thewulf.org wrote:
>I'm having an issue with migrating my Django application. 
>
>I encounter the following errors when trying to migrate:
>ERRORS:
>accounts.Availability.channel: (fields.E300) Field defines a relation
>with 
>model 'Channel', which is either not installed, or is abstract.
>accounts.Correspondence.channel: (fields.E300) Field defines a relation
>with 
>model 'Channel', which is either not installed, or is abstract.
>accounts.Todo.channel: (fields.E300) Field defines a relation with
>model 
>'Channel', which is either not installed, or is abstract.
>marketplace.Deliverable.channel: (fields.E300) Field defines a relation
>with 
>model 'Channel', which is either not installed, or is abstract.
>marketplace.OfflineServiceRequest.channel: (fields.E300) Field defines
>a 
>relation with model 'Channel', which is either not installed, or is
>abstract
>.
>marketplace.OperatorReview.channel: (fields.E300) Field defines a
>relation 
>with model 'Channel', which is either not installed, or is abstract.
>marketplace.Service.channel: (fields.E300) Field defines a relation
>with 
>model 'Channel', which is either not installed, or is abstract.
>marketplace.ServiceDelivery.channel: (fields.E300) Field defines a
>relation 
>with model 'Channel', which is either not installed, or is abstract.
>
>
>My installed apps definition:
>DJANGO_APPS = [
>'suit',
>'django.contrib.admin',
>'django.contrib.auth',
>'django.contrib.contenttypes',
>'django.contrib.sessions',
>'django.contrib.messages',
>'django.contrib.staticfiles', 
>'django.contrib.sites',
>]
>
>
>LOCAL_APPS = [ 
>'thriive_api.accounts',
>'thriive_api.utils',   
>'thriive_api.marketplace', 
>'thriive_api.conversations',  
>'thriive_api.transactions' 
>
>]
>
>
>THIRDPARTY_APPS = [
>'rest_framework_jwt',  
>'rest_framework',  
>'charity_check',   
>'restframework_stripe',
>'redis_pubsub',
>]
>
>
>INSTALLED_APPS = DJANGO_APPS + THIRDPARTY_APPS + LOCAL_APPS
>
>and I'm referring to the model directly in the FK relation in my model 
>definitions:
>from redis_pubsub.models import Channel
>
>class Availability(models.Model):
>   channel = models.ForeignKey(Channel)
>
>It seems like the migrations can't find the `redis_pubsub.Channel`
>model, 
>which is installed in `THIRDPARTY_APPS` and is not abstract. The
>migration 
>files themselves also refer to the correct model path (e.g. 
>`redis_pubsub.Channel`), so what gives? Does anyone know what's going
>on 
>here?

-- 
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/F9CD8805-EC31-407F-9AEC-CD8C42726CEF%40markusholtermann.eu.
For more options, visit https://groups.google.com/d/optout.

Re: Links from django docs to djangopackages.com should be 'officially endorsed' or not?

[Markus Holtermann]

I think that links to 3rd party pages with grids, comparisons, pros'n'cons, 
scattered all over Django's documentation aren't too helpful. I'd probably 
prefer a separate page in the docs that links to those 3rd party pages. The 
general problem with those sites though, they are not audited for their 
accuracy or correctness, less for being up to date.

/Markus

On Monday, February 1, 2016 at 10:06:23 PM UTC+11, Federico Capoano wrote:
>
> It seems like a good proposal, It would be good to know why Sergei doesn't 
> think it is appropiate for Django to add links to third party package 
> comparison grids.
>
> django-rest-framework links to third party extensions in its documentation 
> and this had a positive effect on the whole DRF ecosystem.
>
> Federico
>
>
> On Monday, February 1, 2016 at 10:39:44 AM UTC+1, guettli wrote:
>>
>> This ticket was closed as invalid: 
>> https://code.djangoproject.com/ticket/26159
>>
>> {{{
>>
>> Here comes a pull request to add a link to the djangopackages comparison 
>> grid "Pagination".
>> Background: The pagination in django core is only very basic. Most people 
>> want more. I think re-use helps more then re-inventing :-)
>> }}}
>>
>>
>> {{{
>> sergei-maertens
>>
>> Resolution set to invalid
>> Status changed from new to closed
>>
>> I don't think the docs are the appropriate place to point out 
>> alternatives. I feel if Django starts going down that road, then you should 
>> do the same not only for pagination, but for forms, views, other db 
>> adapters, other template engines... I think it's a slippery slope.
>>
>> While I think that djangopackages.com is a great resource, I'm not sure 
>> if it (and no other resources) should be 'officially endorsed' by Django in 
>> the docs.
>> }}}
>>
>> I think a lot of time gets wasted by re-inventing stuff. Yes, programmers 
>> love to program. But time have
>> changed. There are a lot of great re-usable apps and libraries and 
>> programmers who wants to
>> get things done use them.
>>
>> What do you think for *this* issue: the docs for pagination should point 
>> to the comparison grid or not?
>>
>> Regards,
>>   Thomas Güttler
>>
>>

-- 
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/acce712f-38d8-4813-ac86-bb7c00b85876%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[#26151] Refactor MigrationWriter.serialize() to use a factory pattern

[Markus Holtermann]

Hi all,

Ticket: https://code.djangoproject.com/ticket/26151
PR: https://github.com/django/django/pull/6059

This pull request suggests to rewrite the serialization in the 
MigrationWriter to dedicated classes which are then used by a factory 
function. The reasoning behind this is to reduce the complexity of the 
current serialize() function (according to the reporter McCabe Cyclomatic 
Complexity of 50).

The benefit that comes with the new approach -- yet not implemented and 
would be part of a separate issue -- is a dynamic way to introduce new 
serialization options for data types the current MigrationWriter does not 
support. While neither Simon nor Marten nor I could think of any such case, 
we'd like to get other peoples input.

In case we don't come up with cases where the current MigrationWriter 
fails, the discussion should be made if the added overhead is worth it. 
While I find the new code easier to grasp if I'd see it the first time, I'm 
happy to stick to the current implementation.

Cheers,

/Markus

-- 
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/b0626c9e-e21f-48aa-bbf1-4a05a39726f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: View permissions to admin

[Markus Holtermann]

Hi Petr, all,

I managed to find some time to look into your PR (updated 
link: https://github.com/django/django/pull/5297) and the related 
issue: https://code.djangoproject.com/ticket/8936 .
Also, related 
discussion: 
https://groups.google.com/d/topic/django-developers/rZ5Pt9R94d4/discussion 
and issues: https://code.djangoproject.com/ticket/820 
and https://code.djangoproject.com/ticket/17295

First of all, thank you for your your contribution and persistence.

I think Django should provide an easy way to get a read-only view of your 
data in the database. However, I don't really like the integration into 
contrib.admin . As it stands now, people commonly use the admin as a front 
end for their employees instead of building a proper process-oriented 
interface. This may work to some degree but it's not uncommon that 
developers need to fiddle with the internals of the admin to make specific 
things work. Adding a read-only view to the admin would encourage people 
even more to use the admin for reasons where they shouldn't.

I'd prefer an approach on a different level where Django gains a proper 
(de)serialization implementation. The implementation would e.g. leverage 
content negotiation to define the output, e.g. JSON, XML, HTML, etc.

What I'm pretty much saying is, I'd rather see a proper django.rest (or 
whatever we wanna call it) instead of a feature on top of the convoluted 
admin which provides only half of what people probably want and use.

Cheers,

/Markus

On Wednesday, August 26, 2015 at 9:49:58 PM UTC+10, Petr Dlouhý wrote:
>
> Hello all,
>
> I am still waiting for some information about what should I do next to get 
> this pulled into Django. Isn't here somebody willing to take a look at this?
>
> PR is at https://github.com/django/django/pull/5108
>

-- 
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/ef3d364c-3e80-4883-b4ac-378661582e07%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: does anyone use contrib.auth's "test models"? (CustomUser and ExtensionUser)

[Markus Holtermann]

Thanks Simon and Tim,

I'd be ok with moving them into the tests in 1.10, but would give people a 
bit more time to see and respond to this discussion. Maybe until Feb 4th, 
that would be 2 weeks.

I haven't seen anybody actually using the models nor do I use them myself.

/Markus

On Thursday, January 21, 2016 at 1:38:44 PM UTC+11, Tim Graham wrote:
>
> As Simon noted in a ticket [1], "Since the introduction of contrib 
> application migrations in 1.8 (#22170 
> ) the ​documented custom 
> user test models 
> 
>  
> table are not created anymore because they are registered to the 'auth' 
> labeled application but are not part of its shipped migrations. Based on 
> the fact this was not reported before and that the only uses of 
> ExtensionUser I can find is ​either from a vendored version of Django or 
> a copy-pasta of the documentation suggested usage 
> 
>  
> I think we can safely assume it's not commonly used among third-party 
> application who claim to support custom user models."
>
>
> Any objection to removing those models from documentation in 1.8 and 1.9 
> and removing the models themselves in 1.10? (Actually, the models would be 
> moved into the test suite instead of shipped in 
> django/contrib/auth/tests/custom_user.py -- this is done in [2].)
>
>
> [1] https://code.djangoproject.com/ticket/26089
>
> [2] https://github.com/django/django/pull/5975
>

-- 
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/8cb33a52-bf56-4cd1-88d3-effafe06e335%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Lazy operations refactor regression with abstract models #25858

[Markus Holtermann]

That's a nice one, Simon.

tl;dr: I favor 2; am OK with 1 but against 3.

I was favoring 1) as well. But then thought that app relative relationships 
actually make sense and the current behavior adds a nice new API feature. This 
way a 3rd party app can provide an abstract model and require you to implement 
2 models: the inheriting and the referred with a specific name.

Furthermore, if you want a specific model to be used, be explicit about it. Use 
the full app.Model name. I think we should emphasize that in our docs and 
suggest to use the full name at all times.

The problem we'll be running into with 2 would be a sensible migration path. I 
can't think of one right now.

Cheers

/Markus

On January 9, 2016 8:16:32 AM GMT+11:00, charettes  wrote:
>During the refactor of lazy operations[1] abstract models stopped
>resolving
>their related field model reference by themselves[2][3] in order to
>prevent
>pending lookup pollution. This was necessary in order to warn the users
>
>about
>unresolved relationships in a reliable way.
>
>This change introduced a subtle regression[4] when an abstract model
>with a
>lazy app relative (missing an app_label suffix) relationship is derived
>as
>a concrete model in another application:
>
># app1/models.py
>
>class Refered(models.Model):
>pass
>
>class AbstractReferent(models.Model):
>refered = models.ForeignKey('Refered')
>
>class Meta:
>abtract = True
>
># app2/models.py
>
>from app1.models import AbstractReferent
>
>class Refered(models.Model):
>pass
>
>class Referent(AbstractReferent):
>pass
>
>Now that relationships defined on abstract models are only resolved on
>definition of concrete subclasses the `app2.Referent.refered` points to
>`app2.Refered` when it used to point to `app1.Refered`.
>
>Here are the solutions I had in mind:
>
>1) Refuse the temptation to guess; raise an exception on
>`app2.Referent`
>definition about the ambigous relationship and point to resolution
>options.
>
>2) As abstract models should really just be considered "placeholders
>for 
>fields"
>consider this new behavior the correct one. This could be considered a
>new
>feature and a deprecation path would have to be thought of.
>
>3) Revert to the previous behavior by converting app relative lazy 
>relationships
>to the "app_label.Model" form on `RelatedField.contribute_to_class`.
>
>I'd favor the first option over the others because I feel like this is 
>really
>an edge case where both behaviors have merit (and a bad pratice i'd
>like to
>prevent) but the third one is definitely the safest option.
>
>Thanks for your feedback,
>Simon
>
>[1] https://code.djangoproject.com/ticket/24215
>[2] 
>https://groups.google.com/d/msg/django-developers/U5pdY-WVTes/lqfv9cm9bPAJ
>[3] https://github.com/django/django/pull/4115
>[4] https://code.djangoproject.com/ticket/25858

-- 
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/333AF605-822B-46BD-BB2B-CF9040692236%40markusholtermann.eu.
For more options, visit https://groups.google.com/d/optout.

Re: re-thinking middleware

[Markus Holtermann]

Thank you Florian and Carl for continuing the work on that topic. I like both 
the DEP as well as the example.

I would, however, include the exception handling in the examples provided in 
section "Specification" as that is an integral part of middlewares, too.

Nitpicking, I would also name the settings variable MIDDLEWARES (i.e. plural) 
as it is a list of middlewares, not just one.

/Markus

On January 8, 2016 10:31:49 PM GMT+11:00, Curtis Maloney  
wrote:
>In general, I love it.
>
>It's MUCH simpler for people to write and comprehend... requires no 
>classes [but IMHO the callable class is "cleaner"] and allows for 
>configurable middlewares easily...
>
>I do wonder, though... how the anti-import-strings factions will 
>react... I'm sure it can, at least, support direct callables being in 
>the MIDDLEWARE list, not just strings?
>
>--
>Curtis
>
>
>On 08/01/16 13:50, Carl Meyer wrote:
>> Hi all,
>>
>> Back at the Django Under the Hood sprints in November, Florian and I
>> started batting around some ideas for fixing some of the problems
>with
>> the existing middleware abstraction. Florian put together an initial
>> pull request with a POC for some of those ideas. I've now updated the
>> proposal (incorporating some implementation ideas from Pyramid's
>> middleware equivalent) and written it up in the form of a DEP. You
>can
>> find the DEP at
>>
>>
>https://github.com/django/deps/blob/master/draft/0005-rethinking-middleware.rst
>>
>> and I'm also pasting the full 

-- 
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/24BD0937-9FB1-4D4F-9984-01B603A19B74%40markusholtermann.eu.
For more options, visit https://groups.google.com/d/optout.