Re: The blacklist / master issue

[John Obelenus]

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 1:14:13 AM UTC+3, Daryl wrote:
>>
>> The focus while reading the Django pages should be on the differences 
>> between Django's governance approach (long term goal settings, a board of 
>> technical experts, meritocratic decision making) vs the many frameworks and 
>> projects that have flashed in the pan (please excuse me for using a phrase 
>> that some languages might not understand). 
>> Typically flash-in-the-pan projects have fewer experts, and control and 
>> decision making is *usually* meritocratic but sometimes egocentric. 
>> Eventually, no matter how bright the initial flash is, decisions by the 
>> self-chosen few are made that result in the failure of the project.
>>
>> This isn't to say that a failed project is not of value - many of the 
>> learnings from failed projects are rolled into even better proje

Re: Django Channels doesn’t conform to Django middleware specifications

[John Obelenus]

Can I ask a dumb question? Why did you only discover this with adding 
Whitenoise, and not the default/common middleware stack that comes in 
django? Asking that question in another way: What is specific to whitenoise 
that this constant loading of middleware causes such a perf hit? This 
question in no way implies this should not be fixed, its just my curiosity 
(I'm in the exact same situation of running channels and whitenoise)

On Monday, August 27, 2018 at 12:46:15 PM UTC-4, Carl-Philip Majgaard wrote:
>
> After some digging, I was able to find the reason for why adding the 
> Whitenoise middleware to my Channels-enabled project was causing a massive 
> performance drop. 
>
>
> It appears that for every inbound HTTP request, Channels initializes a new 
> AsgiHandler. In turn, this means that the entire middleware stack is being 
> loaded for every HTTP request. See below:
>
> https://github.com/django/channels/blob/master/channels/routing.py#L45-L62
>
> https://github.com/django/channels/blob/master/channels/http.py#L157-L183
>
>
> This has two consequences:
>
>1. Channels is causing middleware to fall out of conformity with 
>Django documentation, which states that middleware’s __init__() is only 
>called *once*, on server startup.  
>2. Any middleware which performs more-than-trivial work in its 
>__init__() causes massive latency on any incoming request. 
>
>
> The issue was diagnosed in:
>
> https://github.com/django/channels/issues/1099
>
> https://github.com/django/channels/issues/1121
>
>
> In response to the diagnosis in django/channels #1121, Andrew Godwin says:
>
> Hmm, ASGI middleware is loaded every request (#1099 
> ) so it's quite possible 
> I made the same mistake with the Django middleware as the handler is loaded 
> every request too. If so, someone should be able to patch that quite easily.
>
>
> However, I feel that a patch to this issue would be non-trivial to create.
>  
>
>
> If the AsgiHandler is refactored such that it receives *scope* upon 
> __call__() rather than on __init__() (and is only initialized once)*, *it 
> no longer conforms to the tests defined in 
> https://github.com/django/asgiref/blob/master/asgiref/testing.py#L17, as 
> they require passing scope for initialization. Thus, the AsgiHandler would 
> no longer fit the shape of an Asgi Application. 
>
>
> I would attempt a fix for this, but I am unsure of how to approach it 
> given the constraints of the problem. 
>
> Perhaps someone more knowledgeable about Channels could chime in with 
> their $0.02? I would love to devote some time to fixing this, but need some 
> input before I do.
>
>
>
>

-- 
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/5c483259-6759-45cc-a8fd-e90ace9e6bdf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Channels doesn’t conform to Django middleware specifications

[John Obelenus]

Just finished reading both bug reports and I see the file loader lookup in 
whitenoise. This explains a lot actually. We are still on Channels 1, and 
when we tried an upgrade to Channels 2, but encountered terrible 
performance at load and had to undo it.

On Tuesday, August 28, 2018 at 8:00:17 AM UTC-4, John Obelenus wrote:
>
> Can I ask a dumb question? Why did you only discover this with adding 
> Whitenoise, and not the default/common middleware stack that comes in 
> django? Asking that question in another way: What is specific to whitenoise 
> that this constant loading of middleware causes such a perf hit? This 
> question in no way implies this should not be fixed, its just my curiosity 
> (I'm in the exact same situation of running channels and whitenoise)
>
> On Monday, August 27, 2018 at 12:46:15 PM UTC-4, Carl-Philip Majgaard 
> wrote:
>>
>> After some digging, I was able to find the reason for why adding the 
>> Whitenoise middleware to my Channels-enabled project was causing a massive 
>> performance drop. 
>>
>>
>> It appears that for every inbound HTTP request, Channels initializes a 
>> new AsgiHandler. In turn, this means that the entire middleware stack is 
>> being loaded for every HTTP request. See below:
>>
>> https://github.com/django/channels/blob/master/channels/routing.py#L45-L62
>>
>> https://github.com/django/channels/blob/master/channels/http.py#L157-L183
>>
>>
>> This has two consequences:
>>
>>1. Channels is causing middleware to fall out of conformity with 
>>Django documentation, which states that middleware’s __init__() is only 
>>called *once*, on server startup.  
>>2. Any middleware which performs more-than-trivial work in its 
>>__init__() causes massive latency on any incoming request. 
>>
>>
>> The issue was diagnosed in:
>>
>> https://github.com/django/channels/issues/1099
>>
>> https://github.com/django/channels/issues/1121
>>
>>
>> In response to the diagnosis in django/channels #1121, Andrew Godwin says:
>>
>> Hmm, ASGI middleware is loaded every request (#1099 
>> <https://github.com/django/channels/issues/1099>) so it's quite possible 
>> I made the same mistake with the Django middleware as the handler is loaded 
>> every request too. If so, someone should be able to patch that quite easily.
>>
>>
>> However, I feel that a patch to this issue would be non-trivial to create.
>>  
>>
>>
>> If the AsgiHandler is refactored such that it receives *scope* upon 
>> __call__() rather than on __init__() (and is only initialized once)*, *it 
>> no longer conforms to the tests defined in 
>> https://github.com/django/asgiref/blob/master/asgiref/testing.py#L17, as 
>> they require passing scope for initialization. Thus, the AsgiHandler would 
>> no longer fit the shape of an Asgi Application. 
>>
>>
>> I would attempt a fix for this, but I am unsure of how to approach it 
>> given the constraints of the problem. 
>>
>> Perhaps someone more knowledgeable about Channels could chime in with 
>> their $0.02? I would love to devote some time to fixing this, but need some 
>> input before I do.
>>
>>
>>
>>

-- 
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/998d7855-152e-4bc1-b2f2-8fd0f80099b4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Potential suspension of Channels development

[John Obelenus]

Chiming in. As a long-time django user (nearly a decade), websockets is an 
area that the project on the whole is very, very, far behind the leading 
edge of the web industry. It's great, often desirable, to not be *on* the 
leading edge, but in my opinion, the project is too far behind it.

There are numerous projects where I would, now, not consider using django 
(or at least, using it only for the admin to save time/effort). That is the 
first issue that I see for the django project as a whole.

Secondly, and probably something Andrew expects to be helped (if not 
outright solved), is the general speed of serving requests. Async can 
absolutely help here (How much it helps is up for debate). As a developer 
who is using a lot more NodeJS now the inherent speed in that platform's 
request lifecycle can often be a game-changer in terms of performance and 
resources needed.

On Monday, January 21, 2019 at 2:57:18 PM UTC-5, Andrew Godwin wrote:
>
>
>
> On Mon, Jan 21, 2019 at 4:34 AM Michael Martinez  > wrote:
>
>> Hi Andrew
>>
>> To me, Websockets is the defining use case for using Django Channels. 
>> From a user POV, saying that Channels is focused on the wrong problem 
>> (websockets) is like saying Django is too focused on HTTP.
>>
>> When I have selected Channels (vs other tools), my rationale was not:
>>
>> "*I need a general purpose async platform and it would be great if it 
>> worked with Websockets, ZeromQ and played nice with Django...*" 
>> (therefore Django Channels vs Tornado vs ...)
>>
>>
>> rather my rationale is more like: 
>>
>> "*I need to build real time features with Websockets using Django..*" 
>> (therefore Django Channels).
>>
>>  
>>
>
> Oh, I totally get that, and Channels does well at providing WebSockets - 
> the problem is that it's still an area with a lot less interest and also 
> one I personally have no use for at the moment. Those things combined mean 
> that WebSockets is not something I'm really interested in supporting for 
> free right now; I'd have to be paid to work on it (as I was with the 
> Mozilla grant for a lot of Channels' development).
>
> 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/b357add7-cd44-4c12-b29b-0d28150417a2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Async DEP

[John Obelenus]

I wonder about the end-result payoff of this approach. In general, 
Django/Python code is not going to be I/O bound, which is where 
asynchronous approaches are going to get the bang for your buck. Even when 
it comes to DB access—the DB is a lot faster than the python and django 
code running against the result set. And too much context-switching (as you 
noted) has painful ramifications for performance.

I can absolutely see why creating a layer that handles asgi, websockets, 
and http requests asynchronously is going to pay off. Bit time. But I'm 
less certain that the ORM access will benefit from an asyncio approach. Do 
we have anything that approaches a hard number that would tell us re-doing 
the ORM layer in asyncio would get us X% performance benefit?

I'm basing my thoughts off this well-reasoned look at performance: 
https://techspot.zzzeek.org/2015/02/15/asynchronous-python-and-databases/

On Thursday, May 9, 2019 at 12:11:19 PM UTC-4, Andrew Godwin wrote:
>
> Hello everyone,
>
> While the ASGI patch (https://github.com/django/django/pull/11209) is 
> maybe the first small step in a long road to async, it's the only real one 
> we could do without a DEP as it purely pulls on existing specs and bugs.
>
> To that end, I have drafted a DEP (provisionally #0009), "Async-capable 
> Django". It is a summary - and I use that word very lightly - of the rest 
> of the work to be done to make a version of Django that one could call 
> "async capable".
>
> You can view it here: 
> https://github.com/andrewgodwin/deps/blob/async/draft/0009-async.rst
>
> It is approximately 7,000 words long - while it could probably do with 
> some editing, the subject matter means it has to be quite in-depth. Even 
> then, it does not propose an exact plan to follow; instead, it proposes the 
> overall strategy and the high-level ideas about what needs to be done.
>
> If you are short on time, please read the Foreword and the High-Level 
> Summary, and then jump around using the table of contents to the sections 
> that interest you.
>
> Feedback on this is very much appreciated; you can either reply here or, 
> if you have comments that would benefit from precise location on the diff, 
> use the pull request here: https://github.com/django/deps/pull/56
>
> This is a very complex topic, and I appreciate feedback might take a 
> while; at least a couple of weeks to get everyone's thoughts. If you want a 
> more private channel to discuss concerns or design questions you're not 
> happy to talk about publicly, feel free to email me directly.
>
> This proposal does not quite fit the DEP template - we never really 
> planned for something of this scale - but I have done my best to make it 
> work; I think we still benefit from discussing and voting on it in the DEP 
> format, but suggestions on how to make it work better are welcome, provided 
> they fit within how Django operates as a community now.
>
> Finally, if there is positive feedback on this, we have the separate 
> question of funding it that I will discuss separately, if and when we get 
> that far. The DEP covers some of the topics, but it's notable that the 
> implementation speed of this varies considerably; if we could get, say, me 
> and someone else on it full-time (which is not a cheap or likely prospect), 
> we can probably be done inside of a single release. If we rely just on 
> volunteer time, it may take years. There is hopefully somewhere between 
> those two that works.
>
> Thanks for taking the time to read through!
>
> 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/a51fac9e-5632-432c-adb1-74e9335c8264%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.