Re: Google Summer of Code 2019

[akki]

Hi

One of the most difficult things for me while preparing my GSoC proposal 
was getting myself acquainted to Django's humungous code base.
To prepare a proposal one should know what modules they would need to 
modify & what part of the code they will need to work with. To do that one 
should *at least* know what is the role of a particular module/file in the 
big picture of Django's code. For me, even though I had drilled down that I 
had to work just with django/db, I still had the task of figuring out the 
working of *so* many modules. There were *models.options, models.sql.query, 
models.sql.compiler, migrations.autodetector, migrations.loader, 
migrations.optimizer*, *backends.features*, *backends.introspection*, 
*backends.operations*, *backends.schema* and many more which were somehow 
connected to each other & doing something but I had no easy way to know 
what.
I think putting an individual README to places like django/core/ 
, django/db/models 
/, etc. with 
even a 1-2 line description of what purpose each of the folder/file (or at 
least the convoluted ones) in that folder serve might be great help to 
newbie programmers - just not for GSoC but any new contributor.
I understand that the work required to make this happen might be quite big 
and complex (maybe big enough to make it a GSoC project in itself, but 
Google doesn't accept purely documentation projects for GSoC IIRC) but 
might be achievable if merged in parts.


@Parth I am Django's GSoC fellow for 2016. If there is any way I could help 
you, feel free to reach me out 
. For other 
fellows, you can search for Django in the archives of GSoC's website 
.
Also, a quick way to ask questions about contributing to Django from the 
community is the IRC channel #django-dev


On Wednesday, 16 January 2019 21:33:55 UTC+7, Tim Graham wrote:
>
> Org applications for Google's Summer of Code are now open (deadline 
> February 6). Do you think the Django Software Foundation should participate?
>
> We haven't had any high quality student applications that we could accept 
> for the past two years.
>
> Perhaps it's partly a function of a poor ideas page (
> https://code.djangoproject.com/wiki/SummerOfCode2018). Perhaps we don't 
> do a great job of publicizing our involvement and attracting high quality 
> students. Perhaps it's because the student payment isn't all that much 
> (+/-$6000 USD, depending on student's country)* for the amount of work 
> involved (also, students have to put in a lot of work up front in their 
> application, with no guarantee of being accepted into the program).
>
> If you have any ideas about mentoring or suggesting a project, or if 
> you're serious about being a student (you should start contributing to 
> Django now if you don't already), please share.
>
> * https://developers.google.com/open-source/gsoc/help/student-stipends
>

-- 
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/94246e44-0a18-492e-bae9-5c340c5734a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Messages without text in the messages framework

[Sebastian Lechner]

Dear Django developer community,

often I would like to trigger a message to the user with the message 
rendered dynamically in the client-side JS code. I use the message 
framework's tags to differentiate between the different messages in JS.


Usually, I will define the message's text on the client side as well, 
making it unnecessary to define the message text in the Django backend. 
My first idea was to set the message text parameter to "None" or the 
empty string when calling add_message.


Unfortunately, it seems that this will lead to the message beging 
discarded. Is there are another way to send a message without text (but 
a number of tags) with the messages framework?


Best regards
Sebastian

--
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/044afeb0-8ad5-82f4-7b9f-75ea6c5db44b%40seble.info.
For more options, visit https://groups.google.com/d/optout.

Re: Add support for filter arguments in queryset.exists() and queryset.count()

[Robert Marsanyi]

I agree, -1, for composability.  I must also say, I find the current idiom 
easier to read than the proposed version, but by far the more important factor 
to me is the violation of composability by bundling different kinds of 
functionality into one call.  One of the nice features of querysets.

-- 
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/a9537686-b5dd-4337-a791-31d9f2e7fbf0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Potential suspension of Channels development

[Carlton Gibson]

Hey Andrew. 

I've been thinking a lot about this. You clearly shouldn't be maintaining 
Channels single-handedly indefinitely. 

On Thursday, 17 January 2019 19:07:06 UTC+1, Andrew Godwin wrote:
>
> Given that, if nobody else can step forward to take over, I'll have to put 
> those three projects (Channels, channels-redis, and Daphne) into an 
> explicit maintenance mode where they only accept security requests via the 
> normal security@ route, and start the process of retiring them as active 
> Django projects, as I don't want to give the impression they're still 
> maintained if they're not.
>
> (note: the asgiref project is still fine and should probably move out of 
> Django to its own effort at some point giving the growing set of ASGI tools)
>
 
I know Channels started out separately, but, it's time to think about what, 
if anything of channels, is to be brought into core, or become THE WAY we 
do things or... Yes, we need more hands, but there's a bunch of people who 
can help out, and at least part of the problem is your out there in the 
wings by yourself (with not much visibility.) 

Q: How does Channels fit into the "Django Async Roadmap"? 

To the extent that it does, I think there's a case for asking the board and 
the DSF more widely to throw everything we've got behind making sure it's 
properly resourced. 

Once I recover a bit from the burnout I'll be able to come back and help 
> with the really complex bugs; the main thing I need out of is the seemingly 
> endless support requests and weird WebSocket client bugs.
>

I presume you DON'T offer support on the issue tracker, and point people to 
other channels? I'd be happy to "straight-bat" obvious tickets away. 
(Michael's offer to recieve is valuable there.) 

"...and weird WebSocket client bugs."

Can I ask you to explain what you mean there? (Point to a ticket maybe.) 
What kind of query do you get? Is there a particular knack to working out 
if it's a valid bug or not? (Or is it apparent?)

Thanks for all you work here. Legend.  

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/68626427-d97d-4053-8836-5382483f63af%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Translate Content From django-ckeditor

[Adam Johnson]

This mailing list is for the development of Django itself, not for support
using Django. Please use the. django-users mailing list for that, or IRC
#django on freenode, or a site like Stack Overflow.

On Sat, 19 Jan 2019 at 11:16, Anh Nguyen  wrote:

> Hi everyone,
> I’m using RichTextUploadField() for my content’s post.
> So now i need to translate this content to other languages.
>
> Im gonna using model-translate’s package. But the content are the HTML
> tags from RichTextUploadField
> So now. what thing i need to do.
> Please give me some solutions. 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/760e3961-e0dc-4fe0-990b-cbf8a51b837a%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Adam

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

Re: What do you think about unify templates feature?

[J . Pablo Martín Cobos]

Bonus track: If you have a template with complete HTML (without blocks).
You can add to this command another features like compress HTML or use line
styles (using pyliner[1]) and win more time yet :-) Because this feature
does not consume run time, but this feature waste preprocessing time, like
compilemessage command.

Best,


REF's
1. https://pypi.org/project/Pyliner/

El sáb., 19 ene. 2019 a las 19:34, J. Pablo Martín Cobos ()
escribió:

> I reply between lines,
>
> El sáb., 19 ene. 2019 a las 12:31, Adam Johnson () escribió:
>
>> I agree, I'd like to see a third party package too.
>>
>
>
> If I have any time I will do it. And I will say something in this thread.
>
>
>>
>> I'm all up for seeing improvements in template rendering speed but
>> working code in a third party package is way more valuable than more
>> discussion. Many of Django's major features in the past (e.g.
>> SecurityMiddleware, Migrations) were third party packages for a long time
>> before being merged in due to community consensus that they were a good
>> idea.
>>
>
> Yes, With this email I see it is a nice feature. If I have any time I will
> work in this feature. I don't need more discussion :-)
>
>
>>
>> Nice to see that it is an improvement over the cached loader, but it does
>> seem like it would complicate things for users quite a bit as it stands -
>> having to run another command on deployments, maybe modifying view code to
>> load a different template name in production, and creating more files that
>> increase the size of a deployment or use more memory.
>>
>
> It will be like collecstatic command. Also, it would be a optional
> feature. You want to win several miliseconds per request, run this command.
> If you don't want win these miliseconds... you don't have do anything.
>
>
>>
>> Also I think there might be a number of edge cases that would make
>> "unification" very hard - IIRC you can have an {% if %} around a {%
>> block %} or at least around {{ block.super }}.
>>
>>
> It is not a problem. I complicate my previous example, it now works:
>
> 1. news.html
>
> {% extends "base.html" %}
>
> {% block title %}
> {% include "inc.news.title.html" %}
> {% endblock %}
>
> {% block content %}
> {% if news %}
> {% for news_item in news %}
> {{ news_item.title }}
> {{ news_item.subtitle }}
> {% endfor %}
> {% else %}
> {{ block.super }}
> {% endif %}
> {% endblock %}
>
> 2. base.html
>
>  http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
> http://www.w3.org/1999/xhtml; lang="{{
> LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
> %}>
> 
> {% block title %}{% endblock %}
> 
> 
> {% block content %}
> Sorry no results
> {% endblock %}
> 
> 
>
> 3. inc.news.title.html
> News
>
> With this command I preproces every template of a settings variable and I
> get something like this:
>
> news.unify.html
>
>  http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
> http://www.w3.org/1999/xhtml; lang="{{
> LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
> %}>
> 
> News
> 
> 
> {% if news %}
> {% for news_item in news %}
> {{ news_item.title }}
> {{ news_item.subtitle }}
> {% endfor %}
> {% else %}
> Sorry no results
> {% endif %}
> 
> 
>
> Best,
>
>
>
>> On Sat, 19 Jan 2019 at 10:00, Jani Tiainen  wrote:
>>
>>> Hi.
>>>
>>> Unfortunately Django is already big. Every new feature requires careful
>>> consideration since it adds maintenance burden to already loaded
>>> maintainers.
>>>
>>> So best and pretty much only way to make your feature appear in Django
>>> itself is to prove that your solution is widely adopted in everyday use and
>>> it's "winning" technology.
>>>
>>> That would practically mean that code is well written, constantly
>>> maintained and documented.
>>>
>>> You can keep showing speed test results but they really won't get you
>>> anywhere. Let the people decide is your feature good or not. Get more
>>> contributors to your feature to resolve edge cases that doesn't work yet.
>>>
>>>
>>> J. Pablo Martín Cobos  kirjoitti la 19. tammik. 2019
>>> klo 10.22:
>>>





 El sáb., 19 ene. 2019 7:08, Jani Tiainen  escribió:

> Hi,
>
> You said that this doesn't require any change in Django at all.
>
> So this doesn't need to be in Django at all, it can survive as its own
> and that way it should be.
>
> So make your enhancement as reusable app and release it to public. Get
> people to use it. Fix the bugs that appears. Write a good documentation.
> Give the support.
>
>
 Yes, it is an option, or another option 

Re: What do you think about unify templates feature?

[J . Pablo Martín Cobos]

I reply between lines,

El sáb., 19 ene. 2019 a las 12:31, Adam Johnson () escribió:

> I agree, I'd like to see a third party package too.
>


If I have any time I will do it. And I will say something in this thread.


>
> I'm all up for seeing improvements in template rendering speed but working
> code in a third party package is way more valuable than more discussion.
> Many of Django's major features in the past (e.g. SecurityMiddleware,
> Migrations) were third party packages for a long time before being merged
> in due to community consensus that they were a good idea.
>

Yes, With this email I see it is a nice feature. If I have any time I will
work in this feature. I don't need more discussion :-)


>
> Nice to see that it is an improvement over the cached loader, but it does
> seem like it would complicate things for users quite a bit as it stands -
> having to run another command on deployments, maybe modifying view code to
> load a different template name in production, and creating more files that
> increase the size of a deployment or use more memory.
>

It will be like collecstatic command. Also, it would be a optional feature.
You want to win several miliseconds per request, run this command. If you
don't want win these miliseconds... you don't have do anything.


>
> Also I think there might be a number of edge cases that would make
> "unification" very hard - IIRC you can have an {% if %} around a {% block
> %} or at least around {{ block.super }}.
>
>
It is not a problem. I complicate my previous example, it now works:

1. news.html

{% extends "base.html" %}

{% block title %}
{% include "inc.news.title.html" %}
{% endblock %}

{% block content %}
{% if news %}
{% for news_item in news %}
{{ news_item.title }}
{{ news_item.subtitle }}
{% endfor %}
{% else %}
{{ block.super }}
{% endif %}
{% endblock %}

2. base.html

http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
http://www.w3.org/1999/xhtml; lang="{{
LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
%}>

{% block title %}{% endblock %}


{% block content %}
Sorry no results
{% endblock %}



3. inc.news.title.html
News

With this command I preproces every template of a settings variable and I
get something like this:

news.unify.html

http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
http://www.w3.org/1999/xhtml; lang="{{
LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
%}>

News


{% if news %}
{% for news_item in news %}
{{ news_item.title }}
{{ news_item.subtitle }}
{% endfor %}
{% else %}
Sorry no results
{% endif %}



Best,



> On Sat, 19 Jan 2019 at 10:00, Jani Tiainen  wrote:
>
>> Hi.
>>
>> Unfortunately Django is already big. Every new feature requires careful
>> consideration since it adds maintenance burden to already loaded
>> maintainers.
>>
>> So best and pretty much only way to make your feature appear in Django
>> itself is to prove that your solution is widely adopted in everyday use and
>> it's "winning" technology.
>>
>> That would practically mean that code is well written, constantly
>> maintained and documented.
>>
>> You can keep showing speed test results but they really won't get you
>> anywhere. Let the people decide is your feature good or not. Get more
>> contributors to your feature to resolve edge cases that doesn't work yet.
>>
>>
>> J. Pablo Martín Cobos  kirjoitti la 19. tammik. 2019
>> klo 10.22:
>>
>>>
>>>
>>>
>>>
>>>
>>> El sáb., 19 ene. 2019 7:08, Jani Tiainen  escribió:
>>>
 Hi,

 You said that this doesn't require any change in Django at all.

 So this doesn't need to be in Django at all, it can survive as its own
 and that way it should be.

 So make your enhancement as reusable app and release it to public. Get
 people to use it. Fix the bugs that appears. Write a good documentation.
 Give the support.


>>> Yes, it is an option, or another option is convince for this feature is
>>> in Django.
>>>
>>> This doesn't need to be in Django, but I think, it is convenient, like
>>> any improve.
>>>
>>> Thanks!
>>>
>>>
>>>
>>>

 On Sat, Jan 19, 2019 at 12:18 AM J. Pablo Martín Cobos <
 goi...@gmail.com> wrote:

> I reply beetween lines,
>
> El vie., 18 ene. 2019 a las 21:25, Jani Tiainen ()
> escribió:
>
>> Hi,
>>
>> Lets try this again.
>>
>> Your system could be nice if it really helps rendering speed.
>>
>
> Yes we get several miliseconds per request.
>
>
>>
>> But does it require changes in Django core itself, or is it

Re: What do you think about unify templates feature?

[J . Pablo Martín Cobos]

I reply between lines,

El sáb., 19 ene. 2019 a las 11:00, Jani Tiainen ()
escribió:

> Hi.
>
> Unfortunately Django is already big. Every new feature requires careful
> consideration since it adds maintenance burden to already loaded
> maintainers.
>

Yes, I know it.


>
> So best and pretty much only way to make your feature appear in Django
> itself is to prove that your solution is widely adopted in everyday use and
> it's "winning" technology.
>
> That would practically mean that code is well written, constantly
> maintained and documented.
>
> You can keep showing speed test results but they really won't get you
> anywhere. Let the people decide is your feature good or not. Get more
> contributors to your feature to resolve edge cases that doesn't work yet.
>

My experience: I proposed a new feature (much more complicated to be
accepted) 8 years ago [1] (when Django was already a big project). I did a
reusable Django app with this feature and I did 3 pull requests (8 years
ago, 7 years ago and 5 years ago), but these never were accepted. The
feature was implemented 4 years ago.  Currently, I think if I only had
create that ticket had been the same.

I don't need nobody use my code, I don't need maintain code... I only need
a good idea, and somebody (I or another person) implements it. You have
your opinion to contribute, and I had the same opinion, but my experience
is other with Django. You can see in my github profile [2] I have
colaborate with other projects without problems.

Anyway if I have any time to do a code that works in every cases and I have
any time to do a reusable app, and I will do it. In short time, I will
create a ticket in Django.

Thanks for your opinion :-)

Best,


REF's

1. https://code.djangoproject.com/ticket/15053
2. https://github.com/goinnn



>
> J. Pablo Martín Cobos  kirjoitti la 19. tammik. 2019
> klo 10.22:
>
>>
>>
>>
>>
>>
>> El sáb., 19 ene. 2019 7:08, Jani Tiainen  escribió:
>>
>>> Hi,
>>>
>>> You said that this doesn't require any change in Django at all.
>>>
>>> So this doesn't need to be in Django at all, it can survive as its own
>>> and that way it should be.
>>>
>>> So make your enhancement as reusable app and release it to public. Get
>>> people to use it. Fix the bugs that appears. Write a good documentation.
>>> Give the support.
>>>
>>>
>> Yes, it is an option, or another option is convince for this feature is
>> in Django.
>>
>> This doesn't need to be in Django, but I think, it is convenient, like
>> any improve.
>>
>> Thanks!
>>
>>
>>
>>
>>>
>>> On Sat, Jan 19, 2019 at 12:18 AM J. Pablo Martín Cobos 
>>> wrote:
>>>
 I reply beetween lines,

 El vie., 18 ene. 2019 a las 21:25, Jani Tiainen ()
 escribió:

> Hi,
>
> Lets try this again.
>
> Your system could be nice if it really helps rendering speed.
>

 Yes we get several miliseconds per request.


>
> But does it require changes in Django core itself, or is it completely
> standalone package that doesn't require changing Django itself to operate?
> If it requires changes in Django itself, it would be useful to describe
> what changes are needed and why.
>
>
 You don't need any change in Django. This command generates a new
 template. I paste another time my first example:

 1. news.html

 {% extends "base.html" %}

 {% block title %}
 {% include "inc.news.title.html" %}
 {% endblock %}

 {% block content %}
 {% for news_item in news %}
 {{ news_item.title }}
 {{ news_item.subtitle }}
 {% endfor %}
 {% endblock %}

 2. base.html

 >>> http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
 http://www.w3.org/1999/xhtml; lang="{{
 LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
 %}>
 
 {% block title %}{% endblock %}
 
 
 {% block content %}{% endblock %}
 
 

 3. inc.news.title.html
 News

 With this command I preprocess every template of a settings variable
 and I get something like this:

 news.unify.html (or if you want the command can overwrite news.html)

 >>> http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
 http://www.w3.org/1999/xhtml; lang="{{
 LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
 %}>
 
 News
 
 
 {% for news_item in news %}
 {{ news_item.title }}
 {{ news_item.subtitle }}
 {% endfor %}
 
 

 It is only a preprocess to get time for each request.

 Note that you can even no build custom rendering engines since Django
> supports those now (with default implementations 

Re: Potential suspension of Channels development

[Dipankar]

Hi, I am also interested to contribute on this topic. Please guide.

On Thu, Jan 17, 2019 at 11:37 PM Andrew Godwin  wrote:

> Hi all,
>
> I'm writing to you all to update you on the current situation of Channels
> and related libraries (channels-redis and Daphne) and potentially ask for
> help.
>
> I've been the sole maintainer of these projects for quite a while and it
> has become unsustainable - all of my energy is taken up fielding issues and
> support requests and I haven't been able to even get myself to start
> looking at Django async stuff because of it.
>
> Given that, if nobody else can step forward to take over, I'll have to put
> those three projects (Channels, channels-redis, and Daphne) into an
> explicit maintenance mode where they only accept security requests via the
> normal security@ route, and start the process of retiring them as active
> Django projects, as I don't want to give the impression they're still
> maintained if they're not.
>
> (note: the asgiref project is still fine and should probably move out of
> Django to its own effort at some point giving the growing set of ASGI tools)
>
> If people are willing to take over maintenance, I'm happy to help explain
> some things but I don't have the bandwidth to bring someone completely up
> from scratch, so I can't help mentor someone who is totally new to
> maintaining open-source Python (sorry!).
>
> Once I recover a bit from the burnout I'll be able to come back and help
> with the really complex bugs; the main thing I need out of is the seemingly
> endless support requests and weird WebSocket client bugs.
>
> My personal deadline for this is two weeks, on February 1st. If you want
> to help out, please feel free to reply either here or get in touch with me
> personally to chat about what's involved.
>
> 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 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/CAFwN1uonedcUeLz8zD%2BK5Ma82gLyAX8g0s58HeT%3Dq-dMgcLxfw%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Warm Regards,
Dipankar B.

-- 
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/CAFdBwp9D1FiMsph1R3dVPTR4GC%2BWJc03FzF-j%2BM6qpwedTLmYA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Translate Content From django-ckeditor

[Anh Nguyen]

Hi everyone,
I’m using RichTextUploadField() for my content’s post.
So now i need to translate this content to other languages.

Im gonna using model-translate’s package. But the content are the HTML tags 
from RichTextUploadField
So now. what thing i need to do.
Please give me some solutions. 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/760e3961-e0dc-4fe0-990b-cbf8a51b837a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: What do you think about unify templates feature?

[Adam Johnson]

I agree, I'd like to see a third party package too.

I'm all up for seeing improvements in template rendering speed but working
code in a third party package is way more valuable than more discussion.
Many of Django's major features in the past (e.g. SecurityMiddleware,
Migrations) were third party packages for a long time before being merged
in due to community consensus that they were a good idea.

Nice to see that it is an improvement over the cached loader, but it does
seem like it would complicate things for users quite a bit as it stands -
having to run another command on deployments, maybe modifying view code to
load a different template name in production, and creating more files that
increase the size of a deployment or use more memory.

Also I think there might be a number of edge cases that would make
"unification" very hard - IIRC you can have an {% if %} around a {% block %}
or at least around {{ block.super }}.

On Sat, 19 Jan 2019 at 10:00, Jani Tiainen  wrote:

> Hi.
>
> Unfortunately Django is already big. Every new feature requires careful
> consideration since it adds maintenance burden to already loaded
> maintainers.
>
> So best and pretty much only way to make your feature appear in Django
> itself is to prove that your solution is widely adopted in everyday use and
> it's "winning" technology.
>
> That would practically mean that code is well written, constantly
> maintained and documented.
>
> You can keep showing speed test results but they really won't get you
> anywhere. Let the people decide is your feature good or not. Get more
> contributors to your feature to resolve edge cases that doesn't work yet.
>
>
> J. Pablo Martín Cobos  kirjoitti la 19. tammik. 2019
> klo 10.22:
>
>>
>>
>>
>>
>>
>> El sáb., 19 ene. 2019 7:08, Jani Tiainen  escribió:
>>
>>> Hi,
>>>
>>> You said that this doesn't require any change in Django at all.
>>>
>>> So this doesn't need to be in Django at all, it can survive as its own
>>> and that way it should be.
>>>
>>> So make your enhancement as reusable app and release it to public. Get
>>> people to use it. Fix the bugs that appears. Write a good documentation.
>>> Give the support.
>>>
>>>
>> Yes, it is an option, or another option is convince for this feature is
>> in Django.
>>
>> This doesn't need to be in Django, but I think, it is convenient, like
>> any improve.
>>
>> Thanks!
>>
>>
>>
>>
>>>
>>> On Sat, Jan 19, 2019 at 12:18 AM J. Pablo Martín Cobos 
>>> wrote:
>>>
 I reply beetween lines,

 El vie., 18 ene. 2019 a las 21:25, Jani Tiainen ()
 escribió:

> Hi,
>
> Lets try this again.
>
> Your system could be nice if it really helps rendering speed.
>

 Yes we get several miliseconds per request.


>
> But does it require changes in Django core itself, or is it completely
> standalone package that doesn't require changing Django itself to operate?
> If it requires changes in Django itself, it would be useful to describe
> what changes are needed and why.
>
>
 You don't need any change in Django. This command generates a new
 template. I paste another time my first example:

 1. news.html

 {% extends "base.html" %}

 {% block title %}
 {% include "inc.news.title.html" %}
 {% endblock %}

 {% block content %}
 {% for news_item in news %}
 {{ news_item.title }}
 {{ news_item.subtitle }}
 {% endfor %}
 {% endblock %}

 2. base.html

 >>> http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
 http://www.w3.org/1999/xhtml; lang="{{
 LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
 %}>
 
 {% block title %}{% endblock %}
 
 
 {% block content %}{% endblock %}
 
 

 3. inc.news.title.html
 News

 With this command I preprocess every template of a settings variable
 and I get something like this:

 news.unify.html (or if you want the command can overwrite news.html)

 >>> http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
 http://www.w3.org/1999/xhtml; lang="{{
 LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
 %}>
 
 News
 
 
 {% for news_item in news %}
 {{ news_item.title }}
 {{ news_item.subtitle }}
 {% endfor %}
 
 

 It is only a preprocess to get time for each request.

 Note that you can even no build custom rendering engines since Django
> supports those now (with default implementations for Django Templating
> Language and Jinja2) your system actually might fall in this category.
>
>
 No, It is not a new render 

Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable

[Carlton Gibson]

> On 19 Jan 2019, at 11:48, Santiago Basulto  wrote:
> 
> Haha, sorry, got overly excited. What's the usual process to make these sort 
> of decisions in these cases? Should we ask the users list?

No problem. :)

We make decisions here. Say you’d have opened a Trac ticket for this, I’d have 
probably said `needsinfo`. So same as I’m saying here, we need to pin down 
what’s being proposed. 

> The setting proposal is purely from my perspective as a user. For *my* 
> (completely unilateral) point of view, this is very important and I'd love to 
> have a place to just flip a switch and change them all; well, I'd even prefer 
> for it to be the default behavior, but I know selects look cool too.
> 
> Now, from a "development" perspective, I do understand that it might be a big 
> change.

Adding a setting may not be any harder than creating a subclass: the underlying 
implementation may look virtually identical. But in that case it’d be likely 
we’d favour the subclass, since a setting is a bit like a sledge-hammer — it’s 
probably overkill when you could just change an import and a superclass 
declaration. 

But, again, what does it look like? Is it better than (i.e. simple enough) 
providing a better example and letting people implement their own? 

FWIW, I think the default select is right for the vast majority of cases and is 
more useable by an order of magnitude. For me, it’s never really been an issue 
declaring raw_id_fields. (But yes, it does come up, so very happy to see 
suggestions.)

As Adam says, something like this could be put on PyPI, even if not in Django 
itself. Is there not something already I wonder? 

Don’t be discouraged. Please pursue the thought if you want it: implement 
something, open a PR, let’s discuss! 

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/541532A8-32DB-4760-B82B-1F63FE16CC07%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add support for filter arguments in queryset.exists() and queryset.count()

[Adam Johnson]

-1 on this suggestion from me too.

The current API is composable (
https://en.m.wikipedia.org/wiki/Composability ), the suggestion is to make
it less so, and make it harder to learn

On Sat, 19 Jan 2019 at 08:01, charettes  wrote:

> To echo my comments on the PR I don't like the idea of relaying args and
> kwargs to filter()
> as it I think it adds little value considering it paints us in a corner
> with regards to future
> count()/exists() API change.
>
> For example if we ever want to add `distinct` kwarg and fields arg passing
> to .count() in the
> future (like it's Count() analog) we wouldn't be able to do so. I would
> consider these additions
> way more in line and coherent with the current QuerySet's API.
>
> Considering this and Tim's point about Python's Zen I'm strongly -1 on
> this one.
>
> Cheers,
> Simon
>
> Le vendredi 18 janvier 2019 15:12:22 UTC-6, Sjoerd Job Postmus a écrit :
>>
>> Dear all,
>>
>>
>> This is probably a feature that has been proposed before, but I could
>> not find a discussion on it, so I proposed it on the tracker, and Tim
>> also couldn't find a discussion.
>>
>> (ticket: https://code.djangoproject.com/ticket/30118 )
>>
>> I would like to propose being able to write
>> `SomeModel.objects.exists(field=value)` over
>> `SomeModel.objects.filter(field=value).exists()` (and similar for
>> `.count(**kwargs)`.
>>
>>
>> As Tim rightfully commented: "There should be one-- and preferably only
>> one --obvious way to do it.".
>>
>>
>> I'm proposing this is a case where the obvious way would eventually be
>> more in line with my suggestion instead of what we currently use.
>>
>>
>> Consider the following code example (from
>>
>> https://github.com/django/django/blob/709a8b861de14204f0e13c9a0fbfd61c11b3565d/tests/auth_tests/test_management.py#L998):
>>
>>
>>
>>  Permission.objects.filter(
>>  content_type__model=opts.model_name,
>>  content_type__app_label=opts.app_label,
>>  codename=codename,
>>  ).exists()
>>
>> There is a weird (to me, your mileage might vary) ").exists()" as a
>> final line, and I would like to write this as
>>
>>  Permission.objects.exists(
>>  content_type__model=opts.model_name,
>>  content_type__app_label=opts.app_label,
>>  codename=codename,
>>  )
>>
>> This pattern seems to be quite rare in the Django codebase itself, but
>> in the codebase at work we have several cases of `queryset.filter(> of lines>).exists()` (and similar with count), and I am expecting this
>> to also be prevalent in other codebases out there.
>>
>>
>> Arguing against it however are the following lines of the Zen of Python:
>>
>> - "Explicit is better than implicit."
>>
>> - Maybe also "Special cases aren't special enough to break the rules.",
>> because `.filter().count()` and `.exclude().count()` are both the same
>> pattern, but this would only create an alternative for the first.
>>
>> - "There should be one-- and preferably only one --obvious way to do it."
>>
>>
>> Beyond these short quips, I was hoping there might also be an earlier
>> discussion covering this.
>>
>>
>> Kind regards,
>>
>> Sjoerd Job Postmus
>>
>> --
> 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/1c86bd0a--405b-b990-4f316bbec458%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Adam

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

Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable

[Adam Johnson]

>
> For *my* (completely unilateral) point of view, this is very important and
> I'd love to have a place to just flip a switch and change them all; well,
> I'd even prefer for it to be the default behavior, but I know selects look
> cool too.
>

How many projects do you need this on? I think the example snippet is good
enough for most cases, you could always wrap it up and put it on PyPI if
you find yourself doing it across many projects (and maybe there's other
stuff you do too)

On Sat, 19 Jan 2019 at 10:48, Santiago Basulto 
wrote:

> Haha, sorry, got overly excited. What's the usual process to make these
> sort of decisions in these cases? Should we ask the users list?
>
> The setting proposal is purely from my perspective as a user. For *my*
> (completely unilateral) point of view, this is very important and I'd love
> to have a place to just flip a switch and change them all; well, I'd even
> prefer for it to be the default behavior, but I know selects look cool too.
>
> Now, from a "development" perspective, I do understand that it might be a
> big change.
>
> On Saturday, January 19, 2019 at 4:57:21 AM UTC-3, Carlton Gibson wrote:
>>
>>
>>
>> On 18 Jan 2019, at 17:20, Santiago Basulto  wrote:
>>
>> Seems like everybody agrees that for large sites, it's necessary.
>>
>>
>> Hang on, slow down. 
>>
>> Personally, I’m not sure it’s too onerous as-is. I’ve not yet seen
>> exactly why subclassing ModelAdmin in one’s project isn’t good enough. It
>> really depends on with the “it” is “it’s necessary” is taken to mean…
>>
>> - Better examples in docs: Great, no problem.
>> - **More** API on ModelAdmin: OK, maybe, but what does that look like
>> exactly?
>> - A setting: Really? Do we have to? Can we explore other options first?
>>
>> Both the docs and adjustments to ModelAdmin options could be pushed
>> forward with a PR. “Better handling of FK widgets for fields with large
>> counts” — sounds great, but what does that involve?
>>
>> 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/e18c8811-35ae-4607-b9bb-7bb826e8389c%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Adam

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

Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable

[Santiago Basulto]

Haha, sorry, got overly excited. What's the usual process to make these 
sort of decisions in these cases? Should we ask the users list?

The setting proposal is purely from my perspective as a user. For *my* 
(completely unilateral) point of view, this is very important and I'd love 
to have a place to just flip a switch and change them all; well, I'd even 
prefer for it to be the default behavior, but I know selects look cool too.

Now, from a "development" perspective, I do understand that it might be a 
big change.

On Saturday, January 19, 2019 at 4:57:21 AM UTC-3, Carlton Gibson wrote:
>
>
>
> On 18 Jan 2019, at 17:20, Santiago Basulto  > wrote:
>
> Seems like everybody agrees that for large sites, it's necessary.
>
>
> Hang on, slow down. 
>
> Personally, I’m not sure it’s too onerous as-is. I’ve not yet seen exactly 
> why subclassing ModelAdmin in one’s project isn’t good enough. It really 
> depends on with the “it” is “it’s necessary” is taken to mean…
>
> - Better examples in docs: Great, no problem. 
> - **More** API on ModelAdmin: OK, maybe, but what does that look like 
> exactly? 
> - A setting: Really? Do we have to? Can we explore other options first?
>
> Both the docs and adjustments to ModelAdmin options could be pushed 
> forward with a PR. “Better handling of FK widgets for fields with large 
> counts” — sounds great, but what does that involve?
>
> 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/e18c8811-35ae-4607-b9bb-7bb826e8389c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: What do you think about unify templates feature?

[J . Pablo Martín Cobos]

El sáb., 19 ene. 2019 7:08, Jani Tiainen  escribió:

> Hi,
>
> You said that this doesn't require any change in Django at all.
>
> So this doesn't need to be in Django at all, it can survive as its own and
> that way it should be.
>
> So make your enhancement as reusable app and release it to public. Get
> people to use it. Fix the bugs that appears. Write a good documentation.
> Give the support.
>
>
Yes, it is an option, or another option is convince for this feature is in
Django.

This doesn't need to be in Django, but I think, it is convenient, like any
improve.

Thanks!




>
> On Sat, Jan 19, 2019 at 12:18 AM J. Pablo Martín Cobos 
> wrote:
>
>> I reply beetween lines,
>>
>> El vie., 18 ene. 2019 a las 21:25, Jani Tiainen ()
>> escribió:
>>
>>> Hi,
>>>
>>> Lets try this again.
>>>
>>> Your system could be nice if it really helps rendering speed.
>>>
>>
>> Yes we get several miliseconds per request.
>>
>>
>>>
>>> But does it require changes in Django core itself, or is it completely
>>> standalone package that doesn't require changing Django itself to operate?
>>> If it requires changes in Django itself, it would be useful to describe
>>> what changes are needed and why.
>>>
>>>
>> You don't need any change in Django. This command generates a new
>> template. I paste another time my first example:
>>
>> 1. news.html
>>
>> {% extends "base.html" %}
>>
>> {% block title %}
>> {% include "inc.news.title.html" %}
>> {% endblock %}
>>
>> {% block content %}
>> {% for news_item in news %}
>> {{ news_item.title }}
>> {{ news_item.subtitle }}
>> {% endfor %}
>> {% endblock %}
>>
>> 2. base.html
>>
>> > http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
>> http://www.w3.org/1999/xhtml; lang="{{
>> LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
>> %}>
>> 
>> {% block title %}{% endblock %}
>> 
>> 
>> {% block content %}{% endblock %}
>> 
>> 
>>
>> 3. inc.news.title.html
>> News
>>
>> With this command I preprocess every template of a settings variable and
>> I get something like this:
>>
>> news.unify.html (or if you want the command can overwrite news.html)
>>
>> > http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
>> http://www.w3.org/1999/xhtml; lang="{{
>> LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
>> %}>
>> 
>> News
>> 
>> 
>> {% for news_item in news %}
>> {{ news_item.title }}
>> {{ news_item.subtitle }}
>> {% endfor %}
>> 
>> 
>>
>> It is only a preprocess to get time for each request.
>>
>> Note that you can even no build custom rendering engines since Django
>>> supports those now (with default implementations for Django Templating
>>> Language and Jinja2) your system actually might fall in this category.
>>>
>>>
>> No, It is not a new render engine. It would be a pre render engine. It is
>> a new feature.
>>
>>
>>> Even code is bad you really need to start get some momentum for your
>>> system. Otherwise it's really hard to provide any feedback for example
>>> there might be some edgecases you might not have thought of.
>>>
>>
>> I want to know if this is a nice feature for Django community, then I
>> will create a ticket... and if nobody resolve it I will propose a change,
>> but I know ifor experience it is very hard collaborate with code in Django,
>> and more difficult with a new feature.
>>
>> To understand it, the best is to use the command with a simple template
>> such as admin/index.html.
>>
>> Best,
>>
>>
>>>
>>> On Fri, Jan 18, 2019 at 7:23 PM J. Pablo Martín Cobos 
>>> wrote:
>>>
 Sorry, I reply beetween lines

 El vie., 18 ene. 2019 16:32, J. Pablo Martín Cobos 
 escribió:

> Hi another time,
>
> I am tring to reply every people in this email:
>
> Josh
>
> I was not using django.template.loaders.cached.Loader, but the result
> are very similar i.e:
>
> App Template Num templates rendered before unify Num templates
> rendered after unify AVG Time render template before unify (ms) AVG
> Time render template after unify (ms)
> Django admin admin/index.html 3 1 80 70
> Django constance admin/constance/change_list.html 7 1 330 180
> Django su su/login.html 5 3 10 5
>
> Pavlos:
>
>1. Yes, I wrote this email to contribute another time. Actually I
>am already Django contributor[1][2]
>2. I didn't share my code, because it is not a nice code. *For me
>it is a teoric question. I don't want anybody have a bad opinion of 
> this
>proposal for the implementation*. But I am sharing [3] it without
>problems, but please I know this solution is incomplete for many 
> reason.
>3. About your question: "I am not sure I understood anything so
> 

Re: Add support for filter arguments in queryset.exists() and queryset.count()

[charettes]

To echo my comments on the PR I don't like the idea of relaying args and 
kwargs to filter()
as it I think it adds little value considering it paints us in a corner 
with regards to future
count()/exists() API change.

For example if we ever want to add `distinct` kwarg and fields arg passing 
to .count() in the
future (like it's Count() analog) we wouldn't be able to do so. I would 
consider these additions
way more in line and coherent with the current QuerySet's API.

Considering this and Tim's point about Python's Zen I'm strongly -1 on this 
one.

Cheers,
Simon

Le vendredi 18 janvier 2019 15:12:22 UTC-6, Sjoerd Job Postmus a écrit :
>
> Dear all, 
>
>
> This is probably a feature that has been proposed before, but I could 
> not find a discussion on it, so I proposed it on the tracker, and Tim 
> also couldn't find a discussion. 
>
> (ticket: https://code.djangoproject.com/ticket/30118 ) 
>
> I would like to propose being able to write 
> `SomeModel.objects.exists(field=value)` over 
> `SomeModel.objects.filter(field=value).exists()` (and similar for 
> `.count(**kwargs)`. 
>
>
> As Tim rightfully commented: "There should be one-- and preferably only 
> one --obvious way to do it.". 
>
>
> I'm proposing this is a case where the obvious way would eventually be 
> more in line with my suggestion instead of what we currently use. 
>
>
> Consider the following code example (from 
>
> https://github.com/django/django/blob/709a8b861de14204f0e13c9a0fbfd61c11b3565d/tests/auth_tests/test_management.py#L998):
>  
>
>
>
>  Permission.objects.filter( 
>  content_type__model=opts.model_name, 
>  content_type__app_label=opts.app_label, 
>  codename=codename, 
>  ).exists() 
>
> There is a weird (to me, your mileage might vary) ").exists()" as a 
> final line, and I would like to write this as 
>
>  Permission.objects.exists( 
>  content_type__model=opts.model_name, 
>  content_type__app_label=opts.app_label, 
>  codename=codename, 
>  ) 
>
> This pattern seems to be quite rare in the Django codebase itself, but 
> in the codebase at work we have several cases of `queryset.filter( of lines>).exists()` (and similar with count), and I am expecting this 
> to also be prevalent in other codebases out there. 
>
>
> Arguing against it however are the following lines of the Zen of Python: 
>
> - "Explicit is better than implicit." 
>
> - Maybe also "Special cases aren't special enough to break the rules.", 
> because `.filter().count()` and `.exclude().count()` are both the same 
> pattern, but this would only create an alternative for the first. 
>
> - "There should be one-- and preferably only one --obvious way to do it." 
>
>
> Beyond these short quips, I was hoping there might also be an earlier 
> discussion covering this. 
>
>
> Kind regards, 
>
> Sjoerd Job Postmus 
>
>

-- 
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/1c86bd0a--405b-b990-4f316bbec458%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.