Feature Idea for overwrite_default_connection context manager

[Alexander Lyabah]

In some of the previous version on Django I had a very useful context 
manager.

from contextlib import ContextDecorator
from django.db import connections

class overwrite_default_connection(ContextDecorator):
prev_default = None
write_connection = None

def __init__(self, write_connection):
self.write_connection = write_connection 

def __enter__(self):
self.prev_default = connections['default']
connections['default'] = connections[self.write_connection]
return self

def __exit__(self, *exc):
connections['default'] = self.prev_default
return False

Which allows me to overwrite default connection. It is very useful when you 
use a jupyter notebook and you need to switch between db connections that 
have different data but the same structure (django models)

But the shared implementation of that context manager stops working recently

ValueError: Subqueries aren't allowed across different databases. Force the 
inner query to be evaluated using `list(inner_query)`.

But I'm wondering wouldn't it be useful to have that kind of manager in the 
core Django functionality, or it is a stupid idea?

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ad453105-2116-40c9-a1ff-9571bfb080d1n%40googlegroups.com.

Re: Feature Idea for overwrite_default_connection context manager

[Alexander Lyabah]

That's a great idea, actually. Thank you

On Wednesday, June 1, 2022 at 4:56:31 PM UTC+3 Adam Johnson wrote:

> Modifying the connections object seems like the wrong way to approach 
> this, as it's not intended for mutation. Did you consider writing a 
> database router and then having a context manager that affects the router's 
> state? 
> https://docs.djangoproject.com/en/4.0/topics/db/multi-db/#topics-db-multi-db-routing
>  
> . That is the API Django supports for moving queries to different databases.
>
> On Wed, Jun 1, 2022 at 2:21 PM Alexander Lyabah  
> wrote:
>
>> In some of the previous version on Django I had a very useful context 
>> manager.
>>
>> from contextlib import ContextDecorator
>> from django.db import connections
>>
>> class overwrite_default_connection(ContextDecorator):
>> prev_default = None
>> write_connection = None
>> 
>> def __init__(self, write_connection):
>> self.write_connection = write_connection 
>> 
>> def __enter__(self):
>> self.prev_default = connections['default']
>> connections['default'] = connections[self.write_connection]
>> return self
>>
>> def __exit__(self, *exc):
>> connections['default'] = self.prev_default
>> return False
>>
>> Which allows me to overwrite default connection. It is very useful when 
>> you use a jupyter notebook and you need to switch between db connections 
>> that have different data but the same structure (django models)
>>
>> But the shared implementation of that context manager stops working 
>> recently
>>
>> ValueError: Subqueries aren't allowed across different databases. Force 
>> the inner query to be evaluated using `list(inner_query)`.
>>
>> But I'm wondering wouldn't it be useful to have that kind of manager in 
>> the core Django functionality, or it is a stupid idea?
>>
>> 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-develop...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/ad453105-2116-40c9-a1ff-9571bfb080d1n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/ad453105-2116-40c9-a1ff-9571bfb080d1n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
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/cbe7f3b8-0f8b-49c3-b3e8-7c58fe612c90n%40googlegroups.com.

New Patterns Idea

[Alexander Lyabah]

I am already posted it on Django Snippets 
http://www.djangosnippets.org/snippets/1218/

I want to introduce my idea about url resolving in Django.

It can be useful for using object-oriented includes in common patter.

It can be useful for created function which will be running only
before functions inside his include object.

I am using it now and it is very helpful for me.

What do you think about it?

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: The blacklist / master issue

[Alexander Lyabah]

Django in international framework, not US-framework. You should not change 
variable names just because meaning of some words have been changed in US 
recently. Those words have been used in source-code for years, and nobody 
put racism in those word when this framework was founded and nobody puts 
any racism in when one is using for creation something big and meaningful.

What I'm encourage you to do, is to thing farther than what is going on 
right now.

If Django Foundation really want to help in this revolution - add a banner 
on that landing page. Feel free to choose

https://eji.org/
https://org2.salsalabs.com/o/6857/p/salsa/donation/common/public/

And this kind of contribution will work much better.

Thank you, for this opportunity to share my opinion.

On Monday, June 15, 2020 at 7:28:23 PM UTC+3, Tom Carrick wrote:
>
> This ticket was closed wontfix 
>  as requiring a 
> discussion here.
>
> David Smith mentioned this Tox issue 
>  stating it had been closed, 
> but to me it seems like it hasn't been closed (maybe there's something I 
> can't see) and apparently a PR would be accepted to add aliases at the 
> least (this is more recent than the comment on the Django ticket).
>
> My impetus to bring this up mostly comes from reading this ZDNet article 
> 
>  
> - it seems like Google have already made moves in this direction and GitHub 
> is also planning to. Usually Django is somewhere near the front for these 
> types of changes.
>
> I'm leaning towards renaming the master branch and wherever else we use 
> that terminology, but I'm less sure about black/whitelist, though right now 
> it seems more positive than negative. Most arguments against use some kind 
> of etymological argument, but I don't think debates about historical terms 
> are as interesting as how they affect people in the here and now.
>
> 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.
>

-- 
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/1c9178a3-cb80-428c-bacb-e8904695f6b6o%40googlegroups.com.

Re: The blacklist / master issue

[Alexander Lyabah]

Ahmad, 

> we should strive to set an international standard

No, we shouldn't we are here for creating framework, just treat your child 
well and it is enough to changing the world for the best.

> If a certain word is off-putting or problematic to individuals in our 
community

We can always find words that "off-putting or problematic to individuals in 
our community", the only difference between those words is that not all of 
them are on news-channel, but it should be a reason for changing anything.

> if it does not convey an accurate and least astonishing meaning to a 
non-native English speaker

Well, bases on this very week statement, we can change a lot of words in 
django source code. And it will not make Django community better, as well 
the world better.



On Friday, June 19, 2020 at 4:18:52 PM UTC+3, Ahmad A. Hussein wrote:
>
> I'd argue that since Django is an international framework, we should 
> strive to set an international standard. If a certain word is off-putting 
> or problematic to individuals in our community, and if it does not convey 
> an accurate and least astonishing meaning to a non-native English speaker, 
> then we should definitely change it.
>
> On Fri, Jun 19, 2020 at 2:54 PM Alexander Lyabah  > wrote:
>
>>
>> Django in international framework, not US-framework. You should not 
>> change variable names just because meaning of some words have been changed 
>> in US recently. Those words have been used in source-code for years, and 
>> nobody put racism in those word when this framework was founded and nobody 
>> puts any racism in when one is using for creation something big and 
>> meaningful.
>>
>> What I'm encourage you to do, is to thing farther than what is going on 
>> right now.
>>
>> If Django Foundation really want to help in this revolution - add a 
>> banner on that landing page. Feel free to choose
>>
>> https://eji.org/
>> https://org2.salsalabs.com/o/6857/p/salsa/donation/common/public/
>>
>> And this kind of contribution will work much better.
>>
>> Thank you, for this opportunity to share my opinion.
>>
>> On Monday, June 15, 2020 at 7:28:23 PM UTC+3, Tom Carrick wrote:
>>>
>>> This ticket was closed wontfix 
>>> <https://code.djangoproject.com/ticket/31670#ticket> as requiring a 
>>> discussion here.
>>>
>>> David Smith mentioned this Tox issue 
>>> <https://github.com/tox-dev/tox/issues/1491> stating it had been 
>>> closed, but to me it seems like it hasn't been closed (maybe there's 
>>> something I can't see) and apparently a PR would be accepted to add aliases 
>>> at the least (this is more recent than the comment on the Django ticket).
>>>
>>> My impetus to bring this up mostly comes from reading this ZDNet article 
>>> <https://www.zdnet.com/article/github-to-replace-master-with-alternative-term-to-avoid-slavery-references/>
>>>  
>>> - it seems like Google have already made moves in this direction and GitHub 
>>> is also planning to. Usually Django is somewhere near the front for these 
>>> types of changes.
>>>
>>> I'm leaning towards renaming the master branch and wherever else we use 
>>> that terminology, but I'm less sure about black/whitelist, though right now 
>>> it seems more positive than negative. Most arguments against use some kind 
>>> of etymological argument, but I don't think debates about historical terms 
>>> are as interesting as how they affect people in the here and now.
>>>
>>> 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.
>>>
>> -- 
>> 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/1c9178a3-cb80-428c-bacb-e8904695f6b6o%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/1c9178a3-cb80-428c-bacb-e8904695f6b6o%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
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/169bc6b4-5027-48f1-b4f9-a5ccc87dea14o%40googlegroups.com.

Re: The blacklist / master issue

[Alexander Lyabah]

let's not change the subject

we are not talking about black and white, we are talking about whitelist / 
blacklist and master / slave. Those statements have a big history in 
programming, which has nothing to do with slavery at all. 

Don't mix words with meaning and senses.

... It is important to understand when you make changes like this. ... 
words and meaning

I've never seen anyone who is by doing 'git checkout master', think about 
white race superior. - It is because master has a different meaning, 
different sense, which is nothing to do with slavery, and fight for freedom.

I've never seen anyone who is by playing white in Go-game, think about 
white race superior. (Even though by Go-rules white gets +7.5 points 
against Black at the beginning of the game) - it is because white has 
different meaning and different sense, and it is nothing to do with 
slavery, and fight for freedom (it is because blacks move first).

You have power here to do what ever you want to do in this framework. I 
what you to use common sense and don't follow the rules dictated by 
news-channels and big corporations. I want rules, you follow, being strong 
and independent from what is going on around. In that case you don't need 
to split community after next big news.

Thank you, with all respect.

On Friday, June 19, 2020 at 4:18:04 PM UTC+3, Tom Forbes wrote:
>
> As an international framework I think we should make our interface as 
> language and culturally agnostic as possible. ‘Allow’ and ‘Deny’ are simply 
> semantically clearer than ‘white’ and ‘black’. That alone is a convincing 
> argument for me.
>
> On 19 Jun 2020, at 13:55, Alexander Lyabah  > wrote:
>
> 
>
> Django in international framework, not US-framework. You should not change 
> variable names just because meaning of some words have been changed in US 
> recently. Those words have been used in source-code for years, and nobody 
> put racism in those word when this framework was founded and nobody puts 
> any racism in when one is using for creation something big and meaningful.
>
> What I'm encourage you to do, is to thing farther than what is going on 
> right now.
>
> If Django Foundation really want to help in this revolution - add a banner 
> on that landing page. Feel free to choose
>
> https://eji.org/
> https://org2.salsalabs.com/o/6857/p/salsa/donation/common/public/
>
> And this kind of contribution will work much better.
>
> Thank you, for this opportunity to share my opinion.
>
> On Monday, June 15, 2020 at 7:28:23 PM UTC+3, Tom Carrick wrote:
>>
>> This ticket was closed wontfix 
>> <https://code.djangoproject.com/ticket/31670#ticket> as requiring a 
>> discussion here.
>>
>> David Smith mentioned this Tox issue 
>> <https://github.com/tox-dev/tox/issues/1491> stating it had been closed, 
>> but to me it seems like it hasn't been closed (maybe there's something I 
>> can't see) and apparently a PR would be accepted to add aliases at the 
>> least (this is more recent than the comment on the Django ticket).
>>
>> My impetus to bring this up mostly comes from reading this ZDNet article 
>> <https://www.zdnet.com/article/github-to-replace-master-with-alternative-term-to-avoid-slavery-references/>
>>  
>> - it seems like Google have already made moves in this direction and GitHub 
>> is also planning to. Usually Django is somewhere near the front for these 
>> types of changes.
>>
>> I'm leaning towards renaming the master branch and wherever else we use 
>> that terminology, but I'm less sure about black/whitelist, though right now 
>> it seems more positive than negative. Most arguments against use some kind 
>> of etymological argument, but I don't think debates about historical terms 
>> are as interesting as how they affect people in the here and now.
>>
>> 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.
>>
> -- 
> 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/1c9178a3-cb80-428c-bacb-e8904695f6b6o%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/django-developers/1c9178a3-cb80-428c-bacb-e8904695f6b6o%40g

Re: The blacklist / master issue

[Alexander Lyabah]

I'm not debating, since nobody has something to say. I'm explaining, why 
things that you are doing are embarrassing.

I hoping that wikipedia will be not that populistic 
https://en.wikipedia.org/wiki/Whitelisting

On Saturday, June 20, 2020 at 5:32:58 PM UTC+3, Adam Johnson wrote:
>
> Alexander, it's not really up for debate any more. We've already merged 
> the PR's to Django.
>
> On Sat, 20 Jun 2020 at 13:51, Alexander Lyabah  > wrote:
>
>> let's not change the subject
>>
>> we are not talking about black and white, we are talking about whitelist 
>> / blacklist and master / slave. Those statements have a big history in 
>> programming, which has nothing to do with slavery at all. 
>>
>> Don't mix words with meaning and senses.
>>
>> ... It is important to understand when you make changes like this. ... 
>> words and meaning
>>
>> I've never seen anyone who is by doing 'git checkout master', think about 
>> white race superior. - It is because master has a different meaning, 
>> different sense, which is nothing to do with slavery, and fight for freedom.
>>
>> I've never seen anyone who is by playing white in Go-game, think about 
>> white race superior. (Even though by Go-rules white gets +7.5 points 
>> against Black at the beginning of the game) - it is because white has 
>> different meaning and different sense, and it is nothing to do with 
>> slavery, and fight for freedom (it is because blacks move first).
>>
>> You have power here to do what ever you want to do in this framework. I 
>> what you to use common sense and don't follow the rules dictated by 
>> news-channels and big corporations. I want rules, you follow, being strong 
>> and independent from what is going on around. In that case you don't need 
>> to split community after next big news.
>>
>> Thank you, with all respect.
>>
>> On Friday, June 19, 2020 at 4:18:04 PM UTC+3, Tom Forbes wrote:
>>>
>>> As an international framework I think we should make our interface as 
>>> language and culturally agnostic as possible. ‘Allow’ and ‘Deny’ are simply 
>>> semantically clearer than ‘white’ and ‘black’. That alone is a convincing 
>>> argument for me.
>>>
>>> On 19 Jun 2020, at 13:55, Alexander Lyabah  wrote:
>>>
>>> 
>>>
>>> Django in international framework, not US-framework. You should not 
>>> change variable names just because meaning of some words have been changed 
>>> in US recently. Those words have been used in source-code for years, and 
>>> nobody put racism in those word when this framework was founded and nobody 
>>> puts any racism in when one is using for creation something big and 
>>> meaningful.
>>>
>>> What I'm encourage you to do, is to thing farther than what is going on 
>>> right now.
>>>
>>> If Django Foundation really want to help in this revolution - add a 
>>> banner on that landing page. Feel free to choose
>>>
>>> https://eji.org/
>>> https://org2.salsalabs.com/o/6857/p/salsa/donation/common/public/
>>>
>>> And this kind of contribution will work much better.
>>>
>>> Thank you, for this opportunity to share my opinion.
>>>
>>> On Monday, June 15, 2020 at 7:28:23 PM UTC+3, Tom Carrick wrote:
>>>>
>>>> This ticket was closed wontfix 
>>>> <https://code.djangoproject.com/ticket/31670#ticket> as requiring a 
>>>> discussion here.
>>>>
>>>> David Smith mentioned this Tox issue 
>>>> <https://github.com/tox-dev/tox/issues/1491> stating it had been 
>>>> closed, but to me it seems like it hasn't been closed (maybe there's 
>>>> something I can't see) and apparently a PR would be accepted to add 
>>>> aliases 
>>>> at the least (this is more recent than the comment on the Django ticket).
>>>>
>>>> My impetus to bring this up mostly comes from reading this ZDNet 
>>>> article 
>>>> <https://www.zdnet.com/article/github-to-replace-master-with-alternative-term-to-avoid-slavery-references/>
>>>>  
>>>> - it seems like Google have already made moves in this direction and 
>>>> GitHub 
>>>> is also planning to. Usually Django is somewhere near the front for these 
>>>> types of changes.
>>>>
>>>> I'm leaning towards renaming the master branch and wherever else we use 
>>

Re: The blacklist / master issue

[Alexander Lyabah]

Btw, PR-author has now a privilege to create an article 
https://en.wikipedia.org/wiki/Allowlistening

On Sunday, June 21, 2020 at 11:11:02 AM UTC+3, Alexander Lyabah wrote:
>
> I'm not debating, since nobody has something to say. I'm explaining, why 
> things that you are doing are embarrassing.
>
> I hoping that wikipedia will be not that populistic 
> https://en.wikipedia.org/wiki/Whitelisting
>
> On Saturday, June 20, 2020 at 5:32:58 PM UTC+3, Adam Johnson wrote:
>>
>> Alexander, it's not really up for debate any more. We've already merged 
>> the PR's to Django.
>>
>> On Sat, 20 Jun 2020 at 13:51, Alexander Lyabah  
>> wrote:
>>
>>> let's not change the subject
>>>
>>> we are not talking about black and white, we are talking about whitelist 
>>> / blacklist and master / slave. Those statements have a big history in 
>>> programming, which has nothing to do with slavery at all. 
>>>
>>> Don't mix words with meaning and senses.
>>>
>>> ... It is important to understand when you make changes like this. ... 
>>> words and meaning
>>>
>>> I've never seen anyone who is by doing 'git checkout master', think 
>>> about white race superior. - It is because master has a different meaning, 
>>> different sense, which is nothing to do with slavery, and fight for freedom.
>>>
>>> I've never seen anyone who is by playing white in Go-game, think about 
>>> white race superior. (Even though by Go-rules white gets +7.5 points 
>>> against Black at the beginning of the game) - it is because white has 
>>> different meaning and different sense, and it is nothing to do with 
>>> slavery, and fight for freedom (it is because blacks move first).
>>>
>>> You have power here to do what ever you want to do in this framework. I 
>>> what you to use common sense and don't follow the rules dictated by 
>>> news-channels and big corporations. I want rules, you follow, being strong 
>>> and independent from what is going on around. In that case you don't need 
>>> to split community after next big news.
>>>
>>> Thank you, with all respect.
>>>
>>> On Friday, June 19, 2020 at 4:18:04 PM UTC+3, Tom Forbes wrote:
>>>>
>>>> As an international framework I think we should make our interface as 
>>>> language and culturally agnostic as possible. ‘Allow’ and ‘Deny’ are 
>>>> simply 
>>>> semantically clearer than ‘white’ and ‘black’. That alone is a convincing 
>>>> argument for me.
>>>>
>>>> On 19 Jun 2020, at 13:55, Alexander Lyabah  wrote:
>>>>
>>>> 
>>>>
>>>> Django in international framework, not US-framework. You should not 
>>>> change variable names just because meaning of some words have been changed 
>>>> in US recently. Those words have been used in source-code for years, and 
>>>> nobody put racism in those word when this framework was founded and nobody 
>>>> puts any racism in when one is using for creation something big and 
>>>> meaningful.
>>>>
>>>> What I'm encourage you to do, is to thing farther than what is going on 
>>>> right now.
>>>>
>>>> If Django Foundation really want to help in this revolution - add a 
>>>> banner on that landing page. Feel free to choose
>>>>
>>>> https://eji.org/
>>>> https://org2.salsalabs.com/o/6857/p/salsa/donation/common/public/
>>>>
>>>> And this kind of contribution will work much better.
>>>>
>>>> Thank you, for this opportunity to share my opinion.
>>>>
>>>> On Monday, June 15, 2020 at 7:28:23 PM UTC+3, Tom Carrick wrote:
>>>>>
>>>>> This ticket was closed wontfix 
>>>>> <https://code.djangoproject.com/ticket/31670#ticket> as requiring a 
>>>>> discussion here.
>>>>>
>>>>> David Smith mentioned this Tox issue 
>>>>> <https://github.com/tox-dev/tox/issues/1491> stating it had been 
>>>>> closed, but to me it seems like it hasn't been closed (maybe there's 
>>>>> something I can't see) and apparently a PR would be accepted to add 
>>>>> aliases 
>>>>> at the least (this is more recent than the comment on the Django ticket).
>>>>>
>>>>> My impetus to bring this up mostly comes from reading 

Re: The blacklist / master issue

[Alexander Lyabah]

Robert, thank you for your response.

For me, as an experience developer, blacklist is more descriptive, since I 
saw this word in so many other places, languages, frameworks. But it is 
just me, I'm here not to say that my opinion is more important than anyone 
else's.

What is more important here, Django doesn't have a strong rules for making 
decision about how framework is building and changing. Next week US-news 
will have a new subject for discussion, new words will be claimed to be 
abusive, new django community member will find an abusive word in source 
code (or sounds like it or very close to it), and community will be happy 
to claim this word to be not that descriptive, and find a better, more 
description replacement for it.

with big respect

On Sunday, June 21, 2020 at 6:54:57 PM UTC+3, Robert Roskam wrote:
>
> Hey All,
>
> I see this opportunity to rename these things to be what they in plain, 
> descriptive language. Since we will rarely have as many people together 
> considering this change, I find it useful to think what we would have named 
> these things from the beginning and then consider if our naming could be 
> more clear.
>
> I also found the term master odd when I first started using git. It didn't 
> map to anything or have an analogy that I found useful. If we switched to 
> main/trunk or whatever Github decides on, I don't much care what the new 
> name scheme is. 
>
> Further, I find the allow/deny, accept/block for lists of things as far 
> more descriptive.
>
> Some elaboration: when I first came into professional technical circles, I 
> found the tendency to use color as a short-cut for culturally accepted 
> meaning to be potentially confusing to those from other cultures.  
> White/black, red/green/yellow may have received _technical_ meanings from 
> the last 50-60 years or so from the American-centric culture, and I speak 
> ignorantly, since I'm an American, but I don't know if I can assume that 
> other cultures do the same. 
>
> Robert Roskam
>
>
>
> On Monday, June 15, 2020 at 12:28:23 PM UTC-4, Tom Carrick wrote:
>>
>> This ticket was closed wontfix 
>>  as requiring a 
>> discussion here.
>>
>> David Smith mentioned this Tox issue 
>>  stating it had been closed, 
>> but to me it seems like it hasn't been closed (maybe there's something I 
>> can't see) and apparently a PR would be accepted to add aliases at the 
>> least (this is more recent than the comment on the Django ticket).
>>
>> My impetus to bring this up mostly comes from reading this ZDNet article 
>> 
>>  
>> - it seems like Google have already made moves in this direction and GitHub 
>> is also planning to. Usually Django is somewhere near the front for these 
>> types of changes.
>>
>> I'm leaning towards renaming the master branch and wherever else we use 
>> that terminology, but I'm less sure about black/whitelist, though right now 
>> it seems more positive than negative. Most arguments against use some kind 
>> of etymological argument, but I don't think debates about historical terms 
>> are as interesting as how they affect people in the here and now.
>>
>> 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.
>>
>

-- 
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/e6311154-ecfc-4117-a1c4-da669dfa6523o%40googlegroups.com.

Re: The blacklist / master issue

[Alexander Lyabah]

 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.

Re: The blacklist / master issue

[Alexander Lyabah]

tabases no longer 
> follows the original meaning of master / slave, so a new or different name 
> is required. This might not suit people of my age who grew up with 
> master/slave databases and understand the non-racist use of the words, but 
> why should the current nomenclature suit just me?
> Master / slave patterns still exist in some databases, but generally the 
> idea of one node being a master is getting rare. This is somewhat poetic, 
> as it mirrors the real world where in most countries, where the trend is 
> (hopefully) away from master / slave relationships.
>
> My personal opinion for the 2nd topic (blacklist / whitelist / allow / 
> deny) is that this is a good time to pick a more descriptive name, and 
> allow/deny would mirror the linux hosts.allow and hosts.deny logic that has 
> been perfectly apt for 4 decades or more, and AFAIK is a better description 
> in most spoken languages in use today. You (Alexander) may prefer 
> "blacklist", and some of the technical board may also prefer "blacklist" (i 
> don't know) but you can rest assured that the decision would have been made 
> without significant weight being applied to the technical board member's 
> *personal* experiences, but the experiences of every *future* user of the 
> framework.
>
> Finally,  in order to argue against changing these names (which has been 
> pointed out has already been merged) you would have to come up with an 
> argument to show reputational or technical harm would be done by changing. 
> Of all the users who have posted on the list who *disagree* with the 
> changes, none have written an argument with substantial merit in my opinion.
>
> Remember, it's all about the future users of Django, not just the current 
> users.
>
> D
>
>
>
>
> On Mon, 22 Jun 2020 at 08:10, 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-d...@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
>>  
>> <https://groups.google.com/d/msgid/django-developers/267f6649-a434-47fb-93c9-880b594d213ao%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>
>
> -- 
> -- 
> ==
> Daryl Egarr,  Director
> Kawhai Consultants Ltd
> Cell   021 521 353
> da...@kawhai.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/ed2feff6-f54d-4461-920f-be74306821e7o%40googlegroups.com.

Re: The blacklist / master issue

[Alexander Lyabah]

I'm sorry for my bad English

On Monday, June 22, 2020 at 4:40:07 PM UTC+3, John Obelenus wrote:
>
> Alex I find the notion that you think changing terms that have bad racial 
> connotations to be "embarrassing" to be entirely without merit. It is not 
> embarrassing to consider the feelings of Black and other minority people 
> when using language. Moreover, racism is not simply a US only phenomenon. 
> It is a world wide phenomenon.
>
> +1 to making these changes and removing racial undertones from this 
> project. To stand against this change is to refuse to hear the opinions of 
> those who are hurt. That is exclusionary and lacks empathy.
>
> On Monday, June 22, 2020 at 6:20:28 AM UTC-4, Alexander Lyabah wrote:
>>
>> Daryl,
>>
>> I've never called anyone egocentric here, maybe thinking in a very 
>> short-term - yes (like a person, who is making decision just by current 
>> needs and not thinking about future at all)
>>
>> > With regard to the current "hot" topics (master/slave and blacklist / 
>> deny), these may be viewed as trend-following, but a deeper study of both 
>> nomenclature will inform you that current technology in databases no longer 
>> follows the original meaning of master / slave, so a new or different name 
>> is required.
>>
>> Well, this is exactly what trend-following means, I don't know how to 
>> argue here. Please feel free to explain what is trend following means in 
>> your opinion.
>>
>> > Remember, it's all about the future users of Django, not just the 
>> current users.
>>
>> Oh, I'm sure about it, but it doesn't mean those changes as smart, right?
>>
>> Again, as I spend a lot of time explaining why renaming now is a bad 
>> thing, and I'm keep hearing again and again racism is bad and everybody are 
>> doing it, and for some reason renaming terms is a good thing again and again
>>
>> As a final though here (and I promise I'm not going you tire you any 
>> longer) I want to tell you a story that happens in parallel universe.
>>
>> Again, sorry for my English, I spend a lot of time explaining technical 
>> things in English, and study philosophy in Russian, but have being involved 
>> in English discussion like this before, which I'm obviously failed.
>>
>> So, this universe looks exactly the same, fight for freedom, US-news, 
>> BLM, Django etc...
>>
>> In this word developers said "We 100% support BLM, we against any racism. 
>> Some of community members have sent proposal for renaming blacklist, but we 
>> 100% sure, that this term has nothing to do with racism. Moreover, terms 
>> can't explain things 100% clear, we just use those terms to explain things 
>> faster. Because we are here is not for inventing and reinventing new terms, 
>> we are here for building new things. Let me explain in example. When one 
>> dev from US said to another dev from France - "don't forget to add 
>> blacklist functionality here", that explains a lot, because term blacklist 
>> is commonly known term. Someone, from community have an idea to rename all 
>> blacklist in source code to allowlist, and don't use term "blacklist" at 
>> all. Well in that case when dev from France will ask "allowlist is a list 
>> which is allowed to be expended? Or allowlist is a list that is allowed to 
>> be used by other lists?", the US-dev will answer "No, don't use read 
>> US-newspapers? allowlist is the same as blacklist but without racism", 
>> thats why we don't want to reinvent terms for what ever reason. Thank you 
>> for understanding"
>>
>> But in the same world astrophysicists haven't been that wise, so they 
>> claimed: "We 100% support BLM, we against any racism. Thats why we decide 
>> not to use term "black hole" instead we will use term "heavy thing", we've 
>> asked a lot of other astrophysicists and they all agree that "heavy thing" 
>> explains thing better, of course, we are not following for renaming trend, 
>> we are here for science, it is just a good time to rename something that we 
>> have planed to rename long time ago. Remember, this all is for future 
>> generation of astrophysicists not for current generation, because we think, 
>> that the next generation will be much dumber and we should help them to 
>> understand new terms"
>>
>> Thank you, and again, with all respect and with hope for the better 
>> future.
>>
>> On Monday, June 22, 2020 at 

What the purpose of having function that is not working correctly?

[Alexander Lyabah]

What the purpose of having function that is not working correctly, when you 
may not have this function at all and thing is changed.

I'm talking here about function Query.__str__

Bellow I show you an example:

In [19]: str(TimelineEvent.objects.filter(id__gt=100).query)
Out[19]: 'SELECT "timeline_timelineevent"."id", 
"timeline_timelineevent"."created_on", 
"timeline_timelineevent"."modified_on", 
"timeline_timelineevent"."action_on", 
"timeline_timelineevent"."timeline_id", 
"timeline_timelineevent"."content_type_id", 
"timeline_timelineevent"."object_id", "timeline_timelineevent"."action", 
"timeline_timelineevent"."meta" FROM "timeline_timelineevent" WHERE 
"timeline_timelineevent"."id" > 100 ORDER BY 
"timeline_timelineevent"."action_on" DESC, "timeline_timelineevent"."id" 
DESC'
In [20]: Timeline.objects.raw(str(TimelineEvent.objects.filter(id__gt=100).
query))
Out[20]:  100 ORDER BY 
"timeline_timelineevent"."action_on" DESC, "timeline_timelineevent"."id" 
DESC>
In [21]: len(Timeline.objects.raw(str(TimelineEvent.objects.filter(id__gt=
100).query)))
Out[21]: 89827
In [23]: str(TimelineEvent.objects.filter(id__gt=100, created_on__gt=
datetime(2020, 1,1)).query)
Out[23]: 'SELECT "timeline_timelineevent"."id", 
"timeline_timelineevent"."created_on", 
"timeline_timelineevent"."modified_on", 
"timeline_timelineevent"."action_on", 
"timeline_timelineevent"."timeline_id", 
"timeline_timelineevent"."content_type_id", 
"timeline_timelineevent"."object_id", "timeline_timelineevent"."action", 
"timeline_timelineevent"."meta" FROM "timeline_timelineevent" WHERE 
("timeline_timelineevent"."created_on" > 2020-01-01 00:00:00+00:00 AND 
"timeline_timelineevent"."id" > 100) ORDER BY 
"timeline_timelineevent"."action_on" DESC, "timeline_timelineevent"."id" 
DESC'
In [24]: len(Timeline.objects.raw(str(TimelineEvent.objects.filter(id__gt=
100, created_on__gt=datetime(2020, 1, 1)).query)))
---
ProgrammingError Traceback (most recent call last)
/usr/local/lib/python3.5/dist-packages/django/db/backends/utils.py in 
_execute(self, sql, params, *ignored_wrapper_args)
83 else:
---> 84 return self.cursor.execute(sql, params)
85 
ProgrammingError: syntax error at or near "00"
LINE 1: ...timeline_timelineevent"."created_on" > 2020-01-01 00:00:00+0...
^

And this function is recommended on stackoverflow all other the place.

What would change if instead of 

def __str__(self):
sql, params = self.sql_with_params()
return sql % params

We will have

def __str__(self):
return '{} | {}'.format(sql, params)

In that case nobody will ever want to use it as argument for raw function.

Thank you. And please, let me know what you think about it

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/44595903-f679-4d08-abb8-80d2c8dec6e9n%40googlegroups.com.

Re: What the purpose of having function that is not working correctly?

[Alexander Lyabah]

I'm sorry for not being polite. Believe my I love what you have built 
already and what to support in any way I can.

My question is exactly what is in the subject is, it is not some kind of 
clickbait. I've done some research before, and I understand the complexity 
of the task you want to accomplish in the linked ticket.

My question and concerns are more about - why we have it in the first 
place. If the intention is to debug rather than using in production - we 
can change the function in a way I suggested above, and no need to close 
the linked ticket at all.

The problem with the function is that it is actually working, but not 
always, and because of that, other people are suggesting it on 
StackOverflow, using it in prod, and may, eventually catch weird 
exceptions, which leads to a bad experience with Django in general.

Also, want to say it again, English is not my first language, and some 
words may sound not polite at all. It is not my intention, I respect all 
the work you have done with Django, and very thankful for continue working 
on it.



On Thursday, September 10, 2020 at 11:36:04 AM UTC+3 Adam Johnson wrote:

> What the purpose of having function that is not working correctly?
>>
>
> You'll go further in life if you use more descriptive, less inflammatory 
> subjects.
>
> Also it's polite to search the ticket tracker for related issues before 
> posting on the list. This is the relevant ticket: 
> https://code.djangoproject.com/ticket/25705
>
> Query.__str__ has never been intended as more than a debugging aid. Part 
> of the reason it's hard to compute the *actual* SQL is because Django 
> doesn't do it - it's done by the database library on cursor.execute(). This 
> is more than string quoting - some objects have special adapters, for 
> example JSON values. On top of this, there's no standard method in the 
> database libraries for SQL interpolation - it was never specified in DB API 
> ( https://www.python.org/dev/peps/pep-0249/ ).
>
> psycopg2 has a mogrify() function, but the other libarries don't - it may 
> require calling some internal/undocumented methods. Solving this ticket 
> needs some research and work. Your contributions would be welcome.
>
> On Thu, 10 Sep 2020 at 09:15, Alexander Lyabah  
> wrote:
>
>>
>> What the purpose of having function that is not working correctly, when 
>> you may not have this function at all and thing is changed.
>>
>> I'm talking here about function Query.__str__
>>
>> Bellow I show you an example:
>>
>> In [19]: str(TimelineEvent.objects.filter(id__gt=100).query)
>> Out[19]: 'SELECT "timeline_timelineevent"."id", 
>> "timeline_timelineevent"."created_on", 
>> "timeline_timelineevent"."modified_on", 
>> "timeline_timelineevent"."action_on", 
>> "timeline_timelineevent"."timeline_id", 
>> "timeline_timelineevent"."content_type_id", 
>> "timeline_timelineevent"."object_id", "timeline_timelineevent"."action", 
>> "timeline_timelineevent"."meta" FROM "timeline_timelineevent" WHERE 
>> "timeline_timelineevent"."id" > 100 ORDER BY 
>> "timeline_timelineevent"."action_on" DESC, "timeline_timelineevent"."id" 
>> DESC'
>> In [20]: Timeline.objects.raw(str(TimelineEvent.objects.filter(id__gt=100
>> ).query))
>> Out[20]: > "timeline_timelineevent"."created_on", "timeline_timelineevent".
>> "modified_on", "timeline_timelineevent"."action_on", 
>> "timeline_timelineevent"."timeline_id", "timeline_timelineevent".
>> "content_type_id", "timeline_timelineevent"."object_id", 
>> "timeline_timelineevent"."action", "timeline_timelineevent"."meta" FROM 
>> "timeline_timelineevent" WHERE "timeline_timelineevent"."id" > 100 ORDER 
>> BY "timeline_timelineevent"."action_on" DESC, "timeline_timelineevent".
>> "id" DESC>
>> In [21]: len(Timeline.objects.raw(str(TimelineEvent.objects.filter(id__gt
>> =100).query)))
>> Out[21]: 89827
>> In [23]: str(TimelineEvent.objects.filter(id__gt=100, created_on__gt=
>> datetime(2020, 1,1)).query)
>> Out[23]: 'SELECT "timeline_timelineevent"."id", 
>> "timeline_timelineevent"."created_on", 
>> "timeline_timelineevent".&quo

Re: What the purpose of having function that is not working correctly?

[Alexander Lyabah]

I'm sorry. Now things sound even more confusing for me.

>From one side you've said that "No, this function is never working in a 
useful way." (but my example from the post shows, how it works in the 
beginning and then stops working for datatime, which means it was pretty 
much useful for some very common cases)

>From another side, you have accepted tickets, to make this function works 
in a useful way.

So it very looks like you've made a function, that returns something, that 
very looks like SQL, but shouldn't be used as SQL, it is just for debug, 
and you have a bunch of tickets to make SQL-like debug text to be working 
as real SQL.

So, my humble suggestion here is very simple. If you don't want something 
to be used in an appropriate way, don't make it looks like it can be used 
this way. 

 

On Thursday, September 10, 2020 at 1:40:33 PM UTC+3 f.apo...@gmail.com 
wrote:

> On Thursday, September 10, 2020 at 11:16:56 AM UTC+2 Alexander Lyabah 
> wrote:
>
>> The problem with the function is that it is actually working, but not 
>> always, and because of that, other people are suggesting it on 
>> StackOverflow, using it in prod, and may, eventually catch weird 
>> exceptions, which leads to a bad experience with Django in general.
>>
>
> No, this function is never working in a useful way. It does client side 
> interpolation of query params which should be done by the drivers instead, 
> even when it works it is potentially dangerous. The actual problem is that 
> people on StackOverflow recommend to use it. FWIW Since it is solely a 
> debugging aid I'd actually break any usage of it by adding "--" to the 
> start of it (or similar)
>  
>

-- 
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/487cadce-51db-418f-aca4-ebe14aa16bb9n%40googlegroups.com.

Re: Use of HTML autofocus attribute in admin (#27692)

[Alexander Lyabah]

> If there were a way to autofocus on first page load only that would be 
the best, it might be possible with JS.

Yes, It should be possible by parsing document.referrer in JS.

On Monday, January 9, 2017 at 10:21:15 AM UTC+2, Adam Johnson wrote:
>
> I just found out that's it not new behavior in Django 1.9. The javascript 
>> autofocus that existed previously has the same effect.
>
>
> Oh yeah, so it does. Yes it's still annoying but changing the default 
> could be more confusing. If there were a way to autofocus on first page 
> load only that would be the best, it might be possible with JS.
>
> On 8 January 2017 at 20:33, Ciske Boekelo 
> > wrote:
>
>> I just found out that's it not new behavior in Django 1.9. The javascript 
>> autofocus that existed previously has the same effect. This doesn't change 
>> my request though, I'd still like the autofocus to be either removed or 
>> optional.
>>
>> Op vrijdag 6 januari 2017 18:54:54 UTC+1 schreef Adam Johnson:
>>>
>>> I think we should remove it and maybe add the Javascript back, this is 
>>> going to affect many peoples' workflows, some of whom are in my 
>>> organization.
>>>
>>> On Friday, January 6, 2017 at 5:48:12 PM UTC, Tim Graham wrote:

 As part of removing inline JavaScript in the admin [0], snippets such 
 as document.getElementById("id_old_password").focus() were replaced 
 with the HTML5 autofocus attribute.

 This attribute has a possibly undesired behavior [1]: "*Warning*: this 
 attribute will force a page scroll to the field with the autofocus 
 attribute 
 set, even within an iframe. So: know your audience, know the position of 
 the form."

 This attribute could be problematic on the change list's admin's search 
 box: "When coming back to the list screen from the edit screen, the 
 browser normally remembers your scroll position and restores it. This is 
 desirable behavior if you want to work through a long lists of objects. 
 However, when you include a search field in the list screen, it has 
 autofocus enabled, which prevents the scroll position from being restored. 
 This is annoying and unhelpful." [2]

 Do you think we should remove autofocus from the search box to remedy 
 this complaint (and possibly go back to using JavaScript for that) or are 
 there any better solutions here?

 [0] 
 https://github.com/django/django/commit/d638cdc42acec608c1967f44af6be32a477c239f
 [1] http://www.wufoo.com/html5/attributes/02-autofocus.html
 [2] https://code.djangoproject.com/ticket/27692

>>> -- 
>> 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/d02bfbaa-be99-46da-9a11-a8fad7fac7cc%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/0790d6ba-8107-4c75-8fbe-f8997ea26a58%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Easy pickings are not that easy for a new contributor

[Alexander Lyabah]

Hi guys,

A lot of articles that I've read say that I should start with ticket from 
Easy 
pickings 
https://code.djangoproject.com/query?status=assigned&status=new&easy=1&stage=Accepted&col=id&col=summary&col=status&col=owner&col=type&col=component&col=version&col=changetime&desc=1&order=id

The problem is that there are not that many tickets I can choose from. All 
of them are already assign.

Maybe I can start with writing tests?

What should be my next step after I read all the documentation about 
contribution?

Thank you, and sorry for, possibly, stupid question.

-- 
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/c89ff7f9-9544-4225-98f8-a152adcd8061%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Easy pickings are not that easy for a new contributor

[Alexander Lyabah]

> see if you can collaborate with someone who is already working on 
something, so that even if the issue is a larger one, there might be a more 
manageable part of it you can tackle. 

I like the idea of collaboration with someone, since it give me an 
opportunity to learn more. How can I find one?

On Tuesday, September 5, 2017 at 5:06:20 PM UTC+3, Daniele Procida wrote:
>
> On Tue, Sep 5, 2017, Alexander Lyabah > 
> wrote: 
>
> >A lot of articles that I've read say that I should start with ticket from 
> >Easy pickings. 
>
> >The problem is that there are not that many tickets I can choose from. 
> All 
> >of them are already assign. 
> > 
> >Maybe I can start with writing tests? 
> > 
> >What should be my next step after I read all the documentation about 
> >contribution? 
> > 
> >Thank you, and sorry for, possibly, stupid question. 
>
> It's not a stupid question at all. As Django has matured, the low-hanging 
> fruit has all but disappeared from the tree. 
>
> It's a shame as well as being a good thing. We don't want to have open 
> issues that could easily be remedied, but at the same time they are useful 
> ways for new contributors to start. 
>
> Until we find a solution to this dilemma, I would: 
>
> * look at tests, as you suggest 
> * find parts of the documentation that seem unsatisfactory or lacking 
> * see if you can collaborate with somone who is already working on 
> something, so that even if the issue is a larger one, there might be a more 
> manageable part of it you can tackle. 
>
> 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 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/fb7d86f2-93ad-47b4-90c7-fd17f64f98c0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Easy pickings are not that easy for a new contributor

[Alexander Lyabah]

> look at tests, as you suggest 

A quick question around this one.

If someone accept the ticket and working on it, what is the best way to 
join and start working on tickets? Should I ask directly on github?

On Tuesday, September 5, 2017 at 5:06:20 PM UTC+3, Daniele Procida wrote:
>
> On Tue, Sep 5, 2017, Alexander Lyabah > 
> wrote: 
>
> >A lot of articles that I've read say that I should start with ticket from 
> >Easy pickings. 
>
> >The problem is that there are not that many tickets I can choose from. 
> All 
> >of them are already assign. 
> > 
> >Maybe I can start with writing tests? 
> > 
> >What should be my next step after I read all the documentation about 
> >contribution? 
> > 
> >Thank you, and sorry for, possibly, stupid question. 
>
> It's not a stupid question at all. As Django has matured, the low-hanging 
> fruit has all but disappeared from the tree. 
>
> It's a shame as well as being a good thing. We don't want to have open 
> issues that could easily be remedied, but at the same time they are useful 
> ways for new contributors to start. 
>
> Until we find a solution to this dilemma, I would: 
>
> * look at tests, as you suggest 
> * find parts of the documentation that seem unsatisfactory or lacking 
> * see if you can collaborate with somone who is already working on 
> something, so that even if the issue is a larger one, there might be a more 
> manageable part of it you can tackle. 
>
> 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 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/0fe62396-24a4-4bbb-b5c5-688f4ec16bb5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: CONTRIBUTION TO DJANGO

[Alexander Lyabah]

Django Doc has several pages about testing

https://docs.djangoproject.com/en/1.11/intro/tutorial05/
https://docs.djangoproject.com/en/1.11/topics/testing/tools/
https://docs.djangoproject.com/en/1.11/topics/testing/advanced/

On Thursday, September 21, 2017 at 8:55:59 PM UTC+3, Heba Khan wrote:
>
> Can you suggest a way of how to test Django projects ad third party 
> packages please?
>
> On Thursday, 21 September 2017 21:00:36 UTC+5:30, Adam Johnson wrote:
>>
>> There's a whole documentation page on this: 
>> https://docs.djangoproject.com/en/dev/internals/contributing/
>>
>> There aren't many easy pickings tickets, plus most of the effort right 
>> now is being put into features for the 2.0 feature freeze. I'd suggest the 
>> biggest contribution you can make right now is testing Django projects or 
>> third party packages with 2.0 and finding bugs or helping them become 
>> compatible.
>>
>> On 21 September 2017 at 15:17, Heba Khan  wrote:
>>
>>> Hello! 
>>>
>>> I'm an undergrad student of B.Tech. in Computer Science and we've been 
>>> assigned a project to contribute in an open source project. My team members 
>>> and I decided to pick Django since it is one of the most well known and 
>>> widely used open source projects. We need help in deciding what 
>>> contributions to make to the repository and how to go about it. Please keep 
>>> the following in mind:
>>>
>>> 1. We're students with Intermediate coding skills and intermediate 
>>> knowledge of Python along with a good hold on HTML, CSS, JavaScript and 
>>> JQuery.
>>> 2. We need some easy contribution ideas which can be executed in a short 
>>> span of time. 
>>> 3. We will be needing guidance and future help from the community as 
>>> well. 
>>>
>>> Thank you in advance. 
>>>
>>> -- 
>>> 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/236511d3-54de-441a-a423-57cc01143be0%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/c717589e-d276-4e73-93a3-3d1e1b662910%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extract LogEntry from django.contrib.admin

[Alexander Lyabah]

I'm doing it already through middleware

On Wednesday, November 8, 2017 at 2:28:01 AM UTC+2, Jamesie Pic wrote:
>
> Hello
>
> Have we considered extracting LogEntry from django.contrib.admin in its 
> own contrib module ?
>
> It would open doors for new features such as automatic request/response 
> trace & exceptions loggers and views in the admin perhaps ?
>
> <3
>
> -- 
> ∞
>

-- 
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/0c2e757c-3c47-4f23-bae4-d3d2c9fc6440%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: #django-dev IRC channel

[Alexander Lyabah]

If it requires any source code changing

On Friday, April 27, 2018 at 9:24:29 AM UTC+3, Kenneth wrote:
>
> Thank you for the reply, Josh.
>
> Should I post it as an issue in the djangoproject.com repository (
> https://github.com/django/djangoproject.com/issues) and not as a ticket 
> in the ticket tracker (https://code.djangoproject.com) because this is an 
> issue with the website?
>
> On Thursday, April 26, 2018 at 9:11:06 PM UTC-4, Josh Smeaton wrote:
>>
>> Yes - that's probably a good idea!
>>
>> On Thursday, 26 April 2018 05:11:33 UTC+10, Kenneth wrote:
>>>
>>> Hello,
>>>
>>> I was just curious about the #django-dev IRC Channel.
>>> Currently, the only mention for this channel is on the Code of Conduct 
>>> FAQ  page.
>>> Should it also be mentioned on the Contributing to Django 
>>>  page?
>>>
>>>

-- 
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/5b5a8930-cbab-4a37-aa2e-0fb88ddfdb01%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Official Django Docker Container Deprecated

[Alexander Lyabah]

but the image it self is only using runserver, which means it is only for 
dev-server.

The requirements.txt can be part of connected volume. So the image contains 
only django and configured server.

On Tuesday, February 26, 2019 at 5:28:14 PM UTC+2, Tom Forbes wrote:
>
> There never was an official Django image, it was an "official docker" 
> Django image that they maintained. The page image page explains why it was 
> deprecated: https://hub.docker.com/_/django
>
> For most usages of this image, it was already not bringing in django from 
>> this image, but actually from your project's requirements.txt, so the 
>> only "value" being added here was the pre-installing of mysql-client, 
>> postgresql-client, and sqlite3 for various uses of the django framework.
>>
>
> I fully agree with this, it made little sense as an image at all.
>
> On Tuesday, 26 February 2019 07:39:34 UTC, Alexander Lyabah wrote:
>>
>> Hi guys,
>>
>> I found out that official django container is deprecated. Why you don't 
>> want to support it?
>>
>> When you search "django" in Python subreddit 
>> https://monosnap.com/file/R3uAqdrcrtxjCyKgHhhe7B8lO3up5q
>>
>> you see "Flask has overtaken Django according to the 2018 JetBrains 
>> Developer Survey" 
>> https://www.reddit.com/r/Python/comments/ao5dml/flask_has_overtaken_django_according_to_the_2018/
>>
>> and the main point in this discussion that it is hard to start from 0 to 
>> real project.
>>
>> That why I was surprised that you don't have a simple docker container 
>> with configured django with apache or/and django with nginx . It can save 
>> so much time for people who just want to launch a simple pet project with 3 
>> visitors per week.
>>
>> Thank you, I love Django and wish you be better and bigger, have a great 
>> week.
>>
>

-- 
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/7a8e045b-b51f-467b-9474-e56c3fb20d1e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Official Django Docker Container Deprecated

[Alexander Lyabah]

I can make a version for production use (in a week or two), for your 
critics.

For example, based on Appache wsgi.

PS: maybe it is also worth to make a docker image for testing changes in 
Django source?

On Wednesday, February 27, 2019 at 4:31:17 PM UTC+2, Jamesie Pic wrote:
>
> > most people currently lean towards a microservice architecture and 
> therefore towards flask. 
> "according to the 2018 JetBrains Developer Survey" and some people. 
> Why start a project with flask in 2019 instead of Quart which or 
> Starlette is another question that I suppose is out of the scope of 
> this mailing list. 
>
> Anyway, the point of Docker is to build your own image that supports 
> both development and production given different runtime parameters. 
> The agile practice with docker is to build your immutable image in CI, 
> test it, deploy it to staging, have on-click deployment to production. 
>
> The security and best practice documentation from docker are indeed a 
> lot to grasp, and beginners will most of the time start making 
> insecure (running as root) and inefficient (fat) images. Therefore for 
> their security Django might want to document making a docker file, 
> perhaps based on the alpine image that's the most lightweight. 
>
> -- 
> ∞ 
>

-- 
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/f07ad32e-e74f-4cd3-945a-ed92692c2209%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

CheckiO Community is looking for more ways to contribute into Open Source

[Alexander Lyabah]

Hi Django developers.

My name is Alex I’m CEO and founder of CheckiO. I hope I found a right 
place to post this kind of message.

CheckiO is a game for python developers where players solving puzzles and 
improving their coding skills by sharing their solution and checking 
solutions of other user. Right now we have more than 200k python-coders who 
have tried a game at least once.

I know quite a lot CheckiO-players, who solved an impressive amount of 
puzzles, are looking for their next step. I want to help them. I’m sure 
that contributing into Open Source projects can be a great next step for 
them.

The problem here is that I don't have too much experience in Open Source 
contribution and I want to make sure I do it right from Open Source 
perspective, so maybe you can give me some advice here.

What can be the first step into Open Source? What can be the first 
contribution into Django?

Maybe you know some projects on GitHub that fits better for new 
contributors?

Thank you very much for your contribution into Open Source. I enjoy using 
Django in our projects.

-- 
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/47133ff4-206d-441a-9612-2992a05be293%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: CheckiO Community is looking for more ways to contribute into Open Source

[Alexander Lyabah]

Oh.. I don't know how did I missed "First steps" in this article.

Thank you. This is what I was looking for.

On Friday, August 12, 2016 at 2:19:06 PM UTC+3, ludovic coues wrote:
>
> There is a section in the django documentation about contributing :) 
>
> https://docs.djangoproject.com/en/dev/internals/contributing/ 
>
> 2016-08-12 11:23 GMT+02:00 Alexander Lyabah  >: 
> > Hi Django developers. 
> > 
> > My name is Alex I’m CEO and founder of CheckiO. I hope I found a right 
> place 
> > to post this kind of message. 
> > 
> > CheckiO is a game for python developers where players solving puzzles 
> and 
> > improving their coding skills by sharing their solution and checking 
> > solutions of other user. Right now we have more than 200k python-coders 
> who 
> > have tried a game at least once. 
> > 
> > I know quite a lot CheckiO-players, who solved an impressive amount of 
> > puzzles, are looking for their next step. I want to help them. I’m sure 
> that 
> > contributing into Open Source projects can be a great next step for 
> them. 
> > 
> > The problem here is that I don't have too much experience in Open Source 
> > contribution and I want to make sure I do it right from Open Source 
> > perspective, so maybe you can give me some advice here. 
> > 
> > What can be the first step into Open Source? What can be the first 
> > contribution into Django? 
> > 
> > Maybe you know some projects on GitHub that fits better for new 
> > contributors? 
> > 
> > Thank you very much for your contribution into Open Source. I enjoy 
> using 
> > Django in our projects. 
> > 
> > -- 
> > 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/47133ff4-206d-441a-9612-2992a05be293%40googlegroups.com.
>  
>
> > For more options, visit https://groups.google.com/d/optout. 
>
>
>
> -- 
>
> Cordialement, Coues Ludovic 
> +336 148 743 42 
>

-- 
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/56e2fa36-4b5e-4efb-bf61-a0c969cc859e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.