Re: Django template 'if ... is' feature design

[Sven R. Kunze]

Am Donnerstag, 14. April 2016 21:04:04 UTC+2 schrieb Stephen:
>
>
> As far as I understand from 
>
>  https://github.com/django/django/pull/6442 
>
> it it deliberate that the if tag exposes the entire implementation detail. 
>
>
Thanks for clarifying.

I didn't know that exactly this was a deliberate choice. I always got the 
impression that Django tries to boil down the feature set of its template 
engine for very good reasons (which I agree with).

Sven
 

-- 
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/89ae41f3-8be7-4b83-8e66-4b2aa26a3809%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django template 'if ... is' feature design

[Sven R. Kunze]

Hi Tim,

due to Stephen's response, my concerns are not valid. :)

Still, my comments among your lines:

Am Freitag, 15. April 2016 02:30:46 UTC+2 schrieb Tim Graham:
>
> Here are some examples of when the "is" operator isn't equivalent to "==".
>
> http://stackoverflow.com/questions/3647692/when-is-the-operator-not-equivalent-to-the-is-operator-python
>

It's true that "==" is not the same as "is". I just wanted to say that most 
sane cases are probably YAGNI. Especially in the light of the increased 
complexity for template users.
 

> Preston (author of the patch to add the "is" operator [0]) indicated 
> support for "is" was necessary for template-based widget rendering [1]. I 
> haven't studied that patch closely, but maybe if you take a look you'll 
> understand why it's needed.
>

Mmm, I couldn't see a good use-case, though. :(
 

> I don't see much benefit to your proposal of limiting its usage to 
> comparing boolean/None values.
>

Neither do I, given that "== True", "== False" and  "== None" will do the 
trick.

Sven

-- 
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/dbf49a98-1080-45a6-b7d9-c9f406cd39f0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Scaling Django for Multiple Teams

[bliyanage]

Hey,

I have two issues I'm looking at solving at work, and I'm looking for a 
couple suggestions as to how other people have solved this.  The two things 
are:

* scale out their django installation to allow for smaller releases (I'm 
thinking microservices, but it could also be internal django apps or who 
knows what else)
* minimizing the impact of migrations during releases (aka we want to be 
able to release in the middle of the afternoon

Currently we put up a maintenance page whenever we are doing database 
operations (aka migrations).  This seems like a recommended best practice.

One way I was thinking about addressing this issue was to break all of our 
models out into a separate repo.  That way we'd only need to deploy 
migrations when the models themselves have deployed.  For code that needs 
the models, we could pip install the repo as an app and away we go.  
Likewise it seems like I could break up different parts of our app via a 
similar strategy.

Does this seem viable?  How have other people solved this kind of problem?

Thanks,

-Ben

-- 
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/d3e0e2f2-3322-462a-a02e-d776c40bc07a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Scaling Django for Multiple Teams

[Tim Graham]

This mailing list is for the development of Django itself. Please use 
django-users for usage questions. Is there some place we could improve that 
would have helped you identify the correct list?

On Monday, April 18, 2016 at 8:11:38 PM UTC-4, bliy...@rentlytics.com wrote:
>
> Hey,
>
> I have two issues I'm looking at solving at work, and I'm looking for a 
> couple suggestions as to how other people have solved this.  The two things 
> are:
>
> * scale out their django installation to allow for smaller releases (I'm 
> thinking microservices, but it could also be internal django apps or who 
> knows what else)
> * minimizing the impact of migrations during releases (aka we want to be 
> able to release in the middle of the afternoon
>
> Currently we put up a maintenance page whenever we are doing database 
> operations (aka migrations).  This seems like a recommended best practice.
>
> One way I was thinking about addressing this issue was to break all of our 
> models out into a separate repo.  That way we'd only need to deploy 
> migrations when the models themselves have deployed.  For code that needs 
> the models, we could pip install the repo as an app and away we go.  
> Likewise it seems like I could break up different parts of our app via a 
> similar strategy.
>
> Does this seem viable?  How have other people solved this kind of problem?
>
> Thanks,
>
> -Ben
>

-- 
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/80d98b66-4c80-4b45-af68-a24bbaa7a6bd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Scaling Django for Multiple Teams

[Ben Liyanage]

My bad--see you guys on the other side.

-Ben

On Mon, Apr 18, 2016 at 5:31 PM, Tim Graham  wrote:

> This mailing list is for the development of Django itself. Please use
> django-users for usage questions. Is there some place we could improve that
> would have helped you identify the correct list?
>
> On Monday, April 18, 2016 at 8:11:38 PM UTC-4, bliy...@rentlytics.com
> wrote:
>>
>> Hey,
>>
>> I have two issues I'm looking at solving at work, and I'm looking for a
>> couple suggestions as to how other people have solved this.  The two things
>> are:
>>
>> * scale out their django installation to allow for smaller releases (I'm
>> thinking microservices, but it could also be internal django apps or who
>> knows what else)
>> * minimizing the impact of migrations during releases (aka we want to be
>> able to release in the middle of the afternoon
>>
>> Currently we put up a maintenance page whenever we are doing database
>> operations (aka migrations).  This seems like a recommended best practice.
>>
>> One way I was thinking about addressing this issue was to break all of
>> our models out into a separate repo.  That way we'd only need to deploy
>> migrations when the models themselves have deployed.  For code that needs
>> the models, we could pip install the repo as an app and away we go.
>> Likewise it seems like I could break up different parts of our app via a
>> similar strategy.
>>
>> Does this seem viable?  How have other people solved this kind of problem?
>>
>> Thanks,
>>
>> -Ben
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/dTTtiSXgiz0/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/80d98b66-4c80-4b45-af68-a24bbaa7a6bd%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
*Ben Liyanage *|* Software Engineer *|* Rentlytics, Inc.*
Phone: (410) 336-2464 | Email: bliyan...@rentlytics.com
1132 Howard Street, San Francisco CA 94107
Visit our Website  | Watch our Video


-- 
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/CADgLBUPcg0%2BO-_2tGe%3D%2BXrE_qZqtWeSEniCmFrg%2BaTZuNnnRWg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.