Re: Conditions DEP

[Connor Boyle]

Hi Carl,

Should I stop working on the DEP then? Also, would it be at all appropriate 
to continue using this mailing list (for say, updates on the project and 
requests for review)?

Thanks,
Connor

On Monday, June 6, 2016 at 9:34:45 AM UTC-7, Carl Meyer wrote:
>
> Hi Connor, 
>
> On 06/05/2016 07:52 PM, Connor Boyle wrote: 
> > I'd like to make a proposal for the addition of a major new feature to 
> > Django. Back in late March of this year, I wrote an original Google 
> > Summer of Code proposal 
> >  that 
> > received some interest from several members of the community, but 
> > neither I nor this proposal were selected for GSoC. A community member 
> > (iirc it was Florian Apolloner) told me to put the proposal in the form 
> > of a DEP. 
>
> I read through the DEP - it's an interesting idea. I'm not seeing 
> anything in the proposal that inherently needs to be part of Django core 
> in order to be useful; it seems that it could just as well be 
> implemented as an installable library. When there's a new feature idea 
> that _can_ live external to Django core, we generally prefer that it 
> _does_ live external to core, at least for a while to prove the design 
> and demonstrate its practical advantage over similar alternatives. 
> Living outside core allows you to iterate much more rapidly on the 
> design, with new releases as often as you need them. 
>
> If in the future it becomes the clear winning implementation of a 
> pattern that is important enough that it should be available to all 
> Django users by default, we may decide to bring it into core. 
>
> Note that this isn't just a theory or something we tell people, it's 
> something that actually happens regularly, including with proposals from 
> core team members. See for example South, django-security, 
> django-transaction-hooks, django-channels... 
>
> So my recommendation is that you implement your proposal as a 
> pip-installable library and advertise it, see whether it gains traction 
> that way, and see what you learn about the design from having it 
> exercised by real users. 
>
> 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/81043deb-ec70-4edc-9fa9-0f7e9861bc65%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Conditions DEP

[Connor Boyle]

Thanks Tim,

A pull request would be great, though I think it would be best for 
posterity to post a link to it on this thread.

Posting directly on this thread (with quotes of relevant sections of the 
proposal) I think would also work fine.

On Monday, June 6, 2016 at 6:29:48 AM UTC-7, Tim Allen wrote:
>
> Hi Connor,
>
> How would you prefer suggested tweaks to your proposal? Since it is on 
> GitHub, would you prefer pull requests? Thank you for taking the initiative!
>
> Regards,
>
> Tim
>
> On Sunday, June 5, 2016 at 10:52:57 PM UTC-4, Connor Boyle wrote:
>>
>> I'd like to make a proposal for the addition of a major new feature to 
>> Django. Back in late March of this year, I wrote an original Google 
>> Summer of Code proposal 
>>  that 
>> received some interest from several members of the community, but neither I 
>> nor this proposal were selected for GSoC. A community member (iirc it was 
>> Florian Apolloner) told me to put the proposal in the form of a DEP.
>>
>> For those not previously introduced (or who need a reminder), this 
>> proposal is for a standardized system of "conditions"–dynamic rules written 
>> in plain Python–which would be used primarily to evaluate whether an action 
>> (in most cases, the execution of a view) should be allowed. Comparable 
>> features include Django-Rules and the permissions system in Django Rest 
>> Framework.
>>
>> The current version of the DEP is attached here 
>> .
>>  
>> I am currently seeking at least a shepherd and hopefully other 
>> implementors. Any and all thoughtful critique would be highly appreciated.
>>
>> Thanks,
>> Connor
>>
>

-- 
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/d8bc600d-ade6-41c3-b105-c50060476383%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Conditions DEP

[Carl Meyer]

Hi Connor,

On 06/05/2016 07:52 PM, Connor Boyle wrote:
> I'd like to make a proposal for the addition of a major new feature to
> Django. Back in late March of this year, I wrote an original Google
> Summer of Code proposal
>  that
> received some interest from several members of the community, but
> neither I nor this proposal were selected for GSoC. A community member
> (iirc it was Florian Apolloner) told me to put the proposal in the form
> of a DEP.

I read through the DEP - it's an interesting idea. I'm not seeing
anything in the proposal that inherently needs to be part of Django core
in order to be useful; it seems that it could just as well be
implemented as an installable library. When there's a new feature idea
that _can_ live external to Django core, we generally prefer that it
_does_ live external to core, at least for a while to prove the design
and demonstrate its practical advantage over similar alternatives.
Living outside core allows you to iterate much more rapidly on the
design, with new releases as often as you need them.

If in the future it becomes the clear winning implementation of a
pattern that is important enough that it should be available to all
Django users by default, we may decide to bring it into core.

Note that this isn't just a theory or something we tell people, it's
something that actually happens regularly, including with proposals from
core team members. See for example South, django-security,
django-transaction-hooks, django-channels...

So my recommendation is that you implement your proposal as a
pip-installable library and advertise it, see whether it gains traction
that way, and see what you learn about the design from having it
exercised by real users.

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/5755A614.7090404%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Conditions DEP

[Tim Allen]

Hi Connor,

How would you prefer suggested tweaks to your proposal? Since it is on 
GitHub, would you prefer pull requests? Thank you for taking the initiative!

Regards,

Tim

On Sunday, June 5, 2016 at 10:52:57 PM UTC-4, Connor Boyle wrote:
>
> I'd like to make a proposal for the addition of a major new feature to 
> Django. Back in late March of this year, I wrote an original Google 
> Summer of Code proposal 
>  that 
> received some interest from several members of the community, but neither I 
> nor this proposal were selected for GSoC. A community member (iirc it was 
> Florian Apolloner) told me to put the proposal in the form of a DEP.
>
> For those not previously introduced (or who need a reminder), this 
> proposal is for a standardized system of "conditions"–dynamic rules written 
> in plain Python–which would be used primarily to evaluate whether an action 
> (in most cases, the execution of a view) should be allowed. Comparable 
> features include Django-Rules and the permissions system in Django Rest 
> Framework.
>
> The current version of the DEP is attached here 
> .
>  
> I am currently seeking at least a shepherd and hopefully other 
> implementors. Any and all thoughtful critique would be highly appreciated.
>
> Thanks,
> Connor
>

-- 
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/1d1e07c4-7995-46d8-9296-741f8760ce75%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Some thoughts on upgrade pain & deprecations.

[Tom Christie]

Picking this up in trac: https://code.djangoproject.com/ticket/26713
And github: https://github.com/django/django/pull/6732

On Thursday, 2 June 2016 16:00:26 UTC+1, Tom Christie wrote:
>
> > I'm against adding custom behavior in Django
>
> That's entirely reasonable, yes.
>
> In which case, what do folks think of the following suggestions:
>
> * Linking prominently to the 'upgrading django 
> ' section 
> from at the begining of every new version's release notes.
> * Tweaking the upgrading django section so that it recommends *first* 
> running your existing test case with warnings enabled and resolving those 
> at that point, *before* upgrading django, and *then* upgrading and running 
> the tests again, at which point you don't necessarily need warnings 
> enabled. (As it currently stands it's rather the wrong way around)
> * Tweaking the upgrading django section so that it also mentions making 
> sure that your test runner isn't silencing the warning output. (eg "Using 
> the py.test runner, you probably want to use something like 
> `PYTHONWARNINGS=default py.test tests -s`")
>
> Cheers,
>
>   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/e4a231d6-32ee-4902-9059-69af87cc5b3b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Should we require pytz for timezone support in Django?

[Aymeric Augustin]

> On 06 Jun 2016, at 03:46, Carl Meyer  wrote:
> 
>> django-admin.py startproject defaults to USE_TZ = True which means that new 
>> projects that install django, start the project, and then run the internal 
>> web server are going to get missing dependency problems.
> 
> That's an excellent point. I agree, we should just add pytz to 
> install_requires if we require it for USE_TZ=True, otherwise the default 
> new-project experience is unpleasant. 

I agree as well.

One of these days we should reverse the “actual default value” so we don’t have 
to override it in the “default project template” (and then people obviously 
have no idea what the “default” is…)

-- 
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/2149BDA6-2122-476B-900D-223C92AC869E%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.