Re: FYI: pip install django is failing

[Daniel Chimeno]

There was a issue with pypi from some locations, although the status page 
doesn't say anything about it.
https://status.python.org/  

El viernes, 25 de diciembre de 2015, 13:03:05 (UTC+1), john...@gmail.com 
escribió:
>
> >pip install django --upgrade
> Collecting django
> Could not find a version that satisfies the requirement django (from 
> versions: )
> No matching distribution found for django
>
> This seems to only be an issue with django as all other packages in 
> requirements file are installing fine this morning
>
> Looking at:  https://pypi.python.org/simple/django/
>
> I see no packages... 
>

-- 
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/06435b13-400b-4b88-8260-ec6dd0c76b0b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: structural & functional review of django documentation

[Doug Epling]

Thanks Carl --

Here is a good example:

I wanted to read-up on the Form class.  First thing I did was go here:

https://docs.djangoproject.com/en/1.9/search/?q=Form

yadda, yadda, yadda, recipe, recipe,   where is the simple list of 
attributes contained in this class?

So I go here:

https://docs.djangoproject.com/en/1.9/ref/forms/

This page is the Joy of Cooking with Django, I figure I am in the wrong 
place so follow a link to here:

https://docs.djangoproject.com/en/1.9/topics/forms/

No, this isn't what I am looking for, this is the intro; so I open a text 
editor and the forms.py module.  And I skim through the code and 
documentation.  Largely, I feel like the functions are addressing me 
because there are many, many sentence fragments composed of predicate 
portions of sentences in violation of PEP 0008.  It would be easy to pick 
out at least one run-on sentence as well.  Then I get to the bottom of this 
document in my text editor, and I find the Form class.  There is some 
mumbo-jumbo there that attempts to provide clarity by providing cute.  And 
I wonder WTF are these parameters?  So I scroll back to the top of this 
page in my text editor, and things become somewhat apparent.  But 
what-the-heck is this 'six' we import from django.util?  So I go here:

https://docs.djangoproject.com/en/1.9/search/?q=django.utils&release=1.9&page=1

Here I reach a dead end.  I could go farther, but this is all a 
side-track.  This isn't even relevant to what I am working on.  And it is 
entirely possible 'six' is something I should just know about and don't.

So is anyone convinced yet?  Like you said, Carl, I need to persuade at 
least one person.  So if there is anyone else in the community who was 
drawn to django because of its journalistic roots, like me, or who has 
degrees in both journalism and computer science, like me, or who just 
fancies his/her self as a wordsmith and has an affinity for python, like 
me, please feel free to join in this conversation.

Otherwise, everyone can just go on thinking I am just grousing over nothing 
important.

On Friday, December 18, 2015 at 7:02:56 PM UTC-5, Doug Epling wrote:
>
> I filed bug report 
> #25952 but apparently it was 
> in the wrong place.  And I referenced this post 
> ,
>  
> but I was thinking it was this group ... I wonder how that happened?
>
> So I am hereby suggesting that the road map for the v. 2.0 release include 
> revamped documentation.  
>
> It should begin as soon as possible with the somewhat standard best 
> practice of collecting "find what you were looking for" or "was this page 
> helpful" or "rate this page on its organization, clarity, brevity, etc." 
> data on every single existing page.  
>
> It might also be helpful to evaluate how different audiences access the 
> docs.  Tutorials are great -- module and class libraries, not so much.
>
> With resulting user feedback along with expert categorization of 
> documentation use cases, as with any writing exercise, there must be an 
> outline.  The existing outline might be a good place to start.
>
> Oh, and those pesky deadlines, when is v. 2.0 slated for release?
>
>
>

-- 
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/6e2c945f-524d-4504-802f-3df009c8244b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: structural & functional review of django documentation

[Shai Berger]

Hi Doug,

On Saturday 26 December 2015 21:08:58 Doug Epling wrote:
> Thanks Carl --
> 
> Here is a good example:
> 
> I wanted to read-up on the Form class.  First thing I did was go here:
> 
> https://docs.djangoproject.com/en/1.9/search/?q=Form
> 
> yadda, yadda, yadda, recipe, recipe,   where is the simple list of
> attributes contained in this class?
> 

So, this already seems odd. You want to read up on it, but you're not actually 
interested in what people wrote up on it?

It sounds like you're looking for a Javadoc-style reference. I always had the 
feelng that Django avoided these by design; a "simple list of attributes" is 
usually not helpful for a human who wants to get something done.

> [...]  But
> what-the-heck is this 'six' we import from django.util?  So I go here:
> 
> https://docs.djangoproject.com/en/1.9/search/?q=django.utils&release=1.9&pa
> ge=1
> 
> Here I reach a dead end.  I could go farther, but this is all a
> side-track.  This isn't even relevant to what I am working on.  And it is
> entirely possible 'six' is something I should just know about and don't.
> 

It is something you should either know about, or not care about. As far as 
forms are concerned, it is just an implementation detail. So if you're looking 
to use forms, you should probably not care about it. If you're looking to hack 
on forms, the issue of Python 2/3 compatibility (which six is a solution for) 
should be familiar to you; and if it isn't, and you're already reading source 
files, you just might open the six.py module, where you'll find a docstring 
which reads:

"""Utilities for writing code that runs on Python 2 and 3"""

> So is anyone convinced yet?

So, I'm not convinced. In particular, I don't understand the frame of mind 
that would lead you along the journey you described. You said you wanted to 
"read up on forms", but that sounds like a means, not a goal; I think it would 
help to clear up the difficulties you ran into and the improvements you wish to 
introduce, if you describe the goals you wish the documentation to serve.

I have seen "design games" based on "personas" -- where you want to write 
specs for a system, and you portray the prospective users. You give them 
names, ages, jobs, some basic life-story, and a main goal for using the 
system, and then when you consider design decision you can say "oh, that would 
please Ned to no end", or, "Catelyn wouldn't like that". I think such a game 
may be helpful for clarifying -- to yourself and to others -- what exactly are 
the problems you're trying to solve.

HTH,
Shai.

argon2 PasswordHasher

[Bas Westerbaan]

Hello,

This morning I submitted a Pull Request[1], which adds a PasswordHasher for 
argon2 – the winner of the Password Hashing Competition.[2]  Tim Graham 
mentioned I should send an e-mail to this list to discuss it.

The patch is mostly pretty straight-forward.  I would like to add a few 
remarks on some of the choices.

1. There are two Python packages that implement argon2.  Both bind 
libargon2[3].  The first is argon2_py[4], which uses ctypes.  The second is 
argon2-cffi[5], which uses... cffi.  Bindings using cffi are more portable, 
so I choose argon2-cffi.

2. argon2 has four parameters: (i) variety ("type"), (ii) time cost ("t"), 
(iii) memory cost ("m") and (iv) parallelism ("p").  There are two 
varieties: argon2i and argon2d.  The first (argon2i) is safest against 
side-channel attacks.  The second tries less hard to be secure against 
side-channel attacks in favour of being more resilient against GPU 
brute-forcing.  For web-apps, the first "argon2i" is the clear choice.  For 
the other parameters I choose to use the same defaults as of argon2-cffi: 
t=2, m=512, p=2.  On a i7-4790 @ 3.6Ghz the hash takes around 2ms to 
compute.

Best wishes,

  Bas



[1] https://github.com/django/django/pull/5876
[2] https://password-hashing.net
[3] https://github.com/p-h-c/phc-winner-argon2
[4] https://github.com/flamewow/argon2_py
[5] https://github.com/hynek/argon2_cffi

-- 
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/12161663-19c9-4b29-95ad-4d5034395184%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Report - December 26, 2015

[Tim Graham]

Triaged

---

https://code.djangoproject.com/ticket/25956 - Unexpected fake_initial 
keyword thrown on migration (invalid)

https://code.djangoproject.com/ticket/25913 - --fake-initial not working 
with apps with other table names (needsinfo)

https://code.djangoproject.com/ticket/25958 - Deprecate skip_validation in 
BaseCommand (created)

https://code.djangoproject.com/ticket/25967 - TabularInline headers don't 
have good indication for whether or not a field is required (created)

https://code.djangoproject.com/ticket/25962 - inspectdb for oracle 
nvarchar2 could miscalculate field size 2-fold (duplicate)

https://code.djangoproject.com/ticket/25972 - Filtering a ForeignObject 
with 'isnull' lookup fails in Django 1.9 (accepted)

https://code.djangoproject.com/ticket/25978 - Deprecate 
shortcuts.render_to_response() (created)

https://code.djangoproject.com/ticket/25988 - Change 
django.db.models.deletion.CASCADE to django.db.models.deletion.PROTECT 
while creating migrations (wontfix)

https://code.djangoproject.com/ticket/25970 - Support simultaneous open 
connections in LiveServerTestCase (duplicate)

Authored



https://github.com/django/django/pull/5847 - Fixed #25958 -- Removed 
support for 'skip_validation' in BaseCommand.execute(**options).

https://github.com/django/django/pull/5854 - Fixed #25963 -- Clarified 
render_to_response() context_instance deprecation.

https://github.com/django/django/pull/5851 - Fixed #25965 -- Added removal 
of sql* commands to 1.9 release notes.

https://github.com/django/django/pull/5856 - Fixed #25948 -- Added 
guidelines for SimpleTestCase.assertRaisesMessage() usage.

https://github.com/django/django/pull/5853 - Fixed #25969 -- Replaced 
render_to_response() with render() in docs examples and tests.

https://github.com/django/django/pull/5872 - Fixed #25985 -- Updated 
signature of ModelAdmin.formfield_for_* to make request a positional 
argument.

https://github.com/django/djangoproject.com/pull/605 - Fixed #604 -- Added 
section for non-cash donors to fundraising page.

Reviewed/committed

--

https://github.com/django/django/pull/5765 - Fixed #25855 -- Enhanced the 
migration warning for runserver.

https://github.com/django/django/pull/5598 - Fixed #494 -- Added ability to 
specify classes on admin inline fieldsets.

https://github.com/django/django/pull/5824 - Fixed #25838 -- Added "python" 
as an interface to the shell command.

https://github.com/django/django/pull/5837 - Fixed #25950 -- Added support 
for GEOSisClosed.

https://github.com/django/django/pull/5849 - Fixed #25961 -- Removed 
handling of thread-non-safe GEOS functions.

https://github.com/django/django/pull/5858 - Fixed #25972 -- Restored 
support for the isnull lookup with ForeignObject

https://github.com/django/django/pull/5869 - Fixed #25981 -- Added need to 
update migrations to on_delete deprecation warning.

https://github.com/django/django/pull/4970 - Fixed #14286 -- Added 
models.BigAutoField.
https://github.com/django/django/pull/5514 - Fixed #8065 -- Made id_list an 
optional argument for QuerySet.in_bulk().

-- 
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/c93fde05-d0ac-472f-abf5-c9822d788811%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: structural & functional review of django documentation

[Doug Epling]

Greetings Shai --

On Saturday, December 26, 2015 at 3:57:00 PM UTC-5, Shai Berger wrote:
>
> Hi Doug, 
>
> On Saturday 26 December 2015 21:08:58 Doug Epling wrote: 
> > Thanks Carl -- 
> > 
> > Here is a good example: 
> > 
> > I wanted to read-up on the Form class.  First thing I did was go here: 
> > 
> > https://docs.djangoproject.com/en/1.9/search/?q=Form 
> > 
> > yadda, yadda, yadda, recipe, recipe,   where is the simple list of 
> > attributes contained in this class? 
> > 
>
> So, this already seems odd. You want to read up on it, but you're not 
> actually 
> interested in what people wrote up on it? 
>

I am sorry if someone's carefully crafted 'how-to`s' got stepped-on by my 
criticism, really, criticism stings.  But this does not make the criticism 
invalid.  In fact, good writers should relish the sting of criticism 
because it makes them better.

>
> It sounds like you're looking for a Javadoc-style reference. I always had 
> the 
> feelng that Django avoided these by design; a "simple list of attributes" 
> is 
> usually not helpful for a human who wants to get something done. 
>
> > [...]  But


Just in general, it is unproductive to take things out-of-context, and 
respond only to things you pick and choose.
 

>
> > what-the-heck is this 'six' we import from django.util?  So I go here: 
> > 
> > 
> https://docs.djangoproject.com/en/1.9/search/?q=django.utils&release=1.9&pa 
> > ge=1 
> > 
> > Here I reach a dead end.  I could go farther, but this is all a 
> > side-track.  This isn't even relevant to what I am working on.  And it 
> is 
> > entirely possible 'six' is something I should just know about and don't. 
> > 
>
> It is something you should either know about, or not care about. As far as 
>

Au contraire, mon frere!  
 

> forms are concerned, it is just an implementation detail. So if you're 
> looking 
> to use forms, you should probably not care about it. If you're looking to 
> hack 
>

Please try to stay on topic.  The topic is documentation.  The excursion 
into the Form class, specifically, was only exemplary.
 

> on forms, the issue of Python 2/3 compatibility (which six is a solution 
> for) 
> should be familiar to you; and if it isn't, and you're already reading 
> source 
> files, you just might open the six.py module, where you'll find a 
> docstring 
> which reads: 
>
> """Utilities for writing code that runs on Python 2 and 3""" 
>
> > So is anyone convinced yet? 
>
> So, I'm not convinced. In particular, I don't understand the frame of mind 


My frame of mind is that we should put the entire text of this section:

https://www.python.org/dev/peps/pep-0008/#comments

 in a block quote here:

https://docs.djangoproject.com/en/1.9/internals/contributing/writing-documentation/

with links to this:

http://www.pearsonhighered.com/educator/product/Elements-of-Style-The/9780205309023.page

and a link to this:

https://www.python.org/dev/peps/pep-0008/

in the attribution.



> that would lead you along the journey you described. You said you wanted 
> to 
> "read up on forms", but that sounds like a means, not a goal; I think it 
> would 
> help to clear up the difficulties you ran into and the improvements you 
> wish to 
> introduce, if you describe the goals you wish the documentation to serve. 
>
> I have seen "design games" based on "personas" -- where you want to write 
> specs for a system, and you portray the prospective users. You give them 
> names, ages, jobs, some basic life-story, and a main goal for using the 
> system, and then when you consider design decision you can say "oh, that 
> would 
> please Ned to no end", or, "Catelyn wouldn't like that". I think such a 
> game 
> may be helpful for clarifying -- to yourself and to others -- what exactly 
> are 
> the problems you're trying to solve.
>

I have no idea what that means.

P.S.

This along with my prior suggestions to start collecting A) user input, and 
B) potential use-cases from developers/experts.

Many thanks, Shai, for your input.

>
> HTH, 
> Shai. 
>

-- 
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/566faeb6-a679-4e9a-8278-c0eeeff77e0e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: structural & functional review of django documentation

[Shai Berger]

Hi again Doug,

I'm leaving quotes in full here, as you requested, and to help demonstrate 
that it isn't useful at all. It is just "visual noise" that most readers will 
skip over.

On Sunday 27 December 2015 05:42:53 Doug Epling wrote:
> Greetings Shai --
> 
> On Saturday, December 26, 2015 at 3:57:00 PM UTC-5, Shai Berger wrote:
> > Hi Doug,
> > 
> > On Saturday 26 December 2015 21:08:58 Doug Epling wrote:
> > > Thanks Carl --
> > > 
> > > Here is a good example:
> > > 
> > > I wanted to read-up on the Form class.  First thing I did was go here:
> > > 
> > > https://docs.djangoproject.com/en/1.9/search/?q=Form
> > > 
> > > yadda, yadda, yadda, recipe, recipe,   where is the simple list of
> > > attributes contained in this class?
> > 
> > So, this already seems odd. You want to read up on it, but you're not
> > actually
> > interested in what people wrote up on it?
> 
> I am sorry if someone's carefully crafted 'how-to`s' got stepped-on by my
> criticism, really, criticism stings.  But this does not make the criticism
> invalid.  In fact, good writers should relish the sting of criticism
> because it makes them better.
> 

An old Hebrew proverb says (paraphrased), before you call upon others to take 
out the pick between their teeth, take out the wooden beam between your eyes. 
I call you out on what seems like a contradiction in your writing, and instead 
of explaining it, you turn to general talk of criticism -- as if any criticism 
of your text is motivated by being personally hurt by it. 

Again: Please explain why, when you want to "read up" on a topic, a general 
explanation of that topic is not suitable.

> > It sounds like you're looking for a Javadoc-style reference. I always had
> > the
> > feelng that Django avoided these by design; a "simple list of attributes"
> > is
> > usually not helpful for a human who wants to get something done.
> > 
> > > [...]  But
> 
> Just in general, it is unproductive to take things out-of-context, and
> respond only to things you pick and choose.
> 

As opposed to responding only to things you pick-and-choose, taken out of 
context, while still quoting the parts you ignore -- which is what you're 
doing, when you pretend I didn't say that simple lists of attributes, as you 
asked for, are not there by design?

> > > what-the-heck is this 'six' we import from django.util?  So I go here:
> > https://docs.djangoproject.com/en/1.9/search/?q=django.utils&release=1.9&;
> > pa
> > 
> > > ge=1
> > > 
> > > Here I reach a dead end.  I could go farther, but this is all a
> > > side-track.  This isn't even relevant to what I am working on.  And it
> > 
> > is
> > 
> > > entirely possible 'six' is something I should just know about and
> > > don't.
> > 
> > It is something you should either know about, or not care about. As far
> > as
> 
> Au contraire, mon frere!
> 
> > forms are concerned, it is just an implementation detail. So if you're
> > looking
> > to use forms, you should probably not care about it. If you're looking to
> > hack
> 
> Please try to stay on topic.  The topic is documentation.  The excursion
> into the Form class, specifically, was only exemplary.
> 

Wait, so it is good for you to bring up an example, but bad if someone else 
looks at it and shows that, at least in part, it does not exemplify what you 
claimed it did?

> > on forms, the issue of Python 2/3 compatibility (which six is a solution
> > for)
> > should be familiar to you; and if it isn't, and you're already reading
> > source
> > files, you just might open the six.py module, where you'll find a
> > docstring
> > which reads:
> > 
> > """Utilities for writing code that runs on Python 2 and 3"""
> > 
> > > So is anyone convinced yet?
> > 
> > So, I'm not convinced. In particular, I don't understand the frame of
> > mind
> 
> My frame of mind is that we should put the entire text of this section:
> 

No. This is not some goal you are trying to reach. Perhaps it is the way to 
reach some such goal. But it is still completely unclear what that goal is. A 
goal would be "making it easier to find information about a specific method", 
or 
"making it easier to understand how to achieve some task", or "making some 
text easier to read for a novice".

> https://www.python.org/dev/peps/pep-0008/#comments
> 
>  in a block quote here:
> 
> https://docs.djangoproject.com/en/1.9/internals/contributing/writing-docume
> ntation/
> 
> with links to this:
> 
> http://www.pearsonhighered.com/educator/product/Elements-of-Style-The/97802
> 05309023.page
> 
> and a link to this:
> 
> https://www.python.org/dev/peps/pep-0008/
> 
> in the attribution.
> 
> > that would lead you along the journey you described. You said you wanted
> > to
> > "read up on forms", but that sounds like a means, not a goal; I think it
> > would
> > help to clear up the difficulties you ran into and the improvements you
> > wish to
> > introduce, if you describe the goals you wish the documentation to serve.
> > 
> > I have seen "d

Re: MOSS Award to Django

[Samuel Bishop]

Once again I have to thank you for taking the time to keep replying. These 
longer explanations are proving very helpful (at least to me) in 
understanding Django Channels. :-)

I definitely understand the compatibility reasons, I'm also pleased to see 
that signalling via a channel will be as simple as I had hoped, at least 
simple as long as we put aside compatibility issues with Django's built in 
signals. I'd still be pleased with only the ability to make my custom 
signals asynchronous.

Digging into the implementation details, you've sparked my curiosity. For 
some reason the simplicity of the having just send() and receive_many() 
didn't fully dawn on me until now. Once I've made progress with my 
decoupling, I think I'll have to try experiment with cleaving the major 
parts of the entire request/response cycle into a chain of asynchronous 
actors.
I'll likely test how hard it is to 'wrap' each part of the cycle in a way 
that allows it to be called by synchronously or asynchronous code. I'd like 
to avoid creating "yet another async django, that isnt really django 
anymore", keep the existing synchronous code pathway seems like a good 
start at a "useful experiment".

As for 'could you call the end result Django'... I think "Django" is 
whatever we make of it ;-) 
I don't see why we wont still call the combination of all the parts, the 
ecosystem of compatible libraries, etc, "Django", regardless of how much we 
might change between now and far future versions like 4.0 or 9.0. 

Regards
Sam

On Monday, 21 December 2015 19:31:54 UTC+8, Andrew Godwin wrote:
>
>
>
> On Mon, Dec 21, 2015 at 6:05 AM, Samuel Bishop  > wrote:
>
>> Hi Andrew, 
>>
>> Thanks for the detailed response. I'm glad to hear you have tried a few 
>> different ways to implement this, and having read through your reply, and 
>> the channels docs again, I have more questions :-)  
>>
>> Your point about asynchronous code introducing needless complexity is 
>> very well founded, its one of the reasons I like Actor Model Concurrency 
>> over other concurrency models, it scales well computationally, and 
>> *mentally*, as a programmer, I am trying break down my real world goals 
>> into discrete steps of computations, comparisons, iterations and by 
>> combining these steps, I construct my program. Actor Model Concurrency, is 
>> no more complicated than saying "This step can be done without affecting 
>> anything else thats going on", which makes the 'actor/task' much easier to 
>> introduce to existing synchronous code than most other concurrency methods.
>>
>
> I agree - I'm a big fan of actors in general and it's usually what I turn 
> to to write complex simulations when I'm mucking around with game backends.
>  
>
>>
>> One thing that sticks with me as I think about the current channels 
>> design, relates to the idea I've raised in another discussion ( 
>> https://groups.google.com/forum/#!topic/django-developers/-BOsuVdPFXc ).
>> If I put my architect hat on and think about the future a bit, a 'more' 
>> actor based design to channels might simplify later additional async work. 
>> Since all the websocket stuff is new, I'll stick to the existing HTTP cycle 
>> in this example. In version 1 a 'vanilla' Django task/actor would be a full 
>> HTTP request response cycle, like how Django and WSGI currently work. Our 
>> Django task is effectively our WSGI task, much like Pulsar Pulse. If all of 
>> Django is contained inside our new task/worker/supervisor Actor layer, then 
>> it becomes fairly trivial to do things like create separate request 
>> handler, database query, and template rendering task/actors and chain their 
>> calls. Since in the previously linked to discussion thread, I'm talking 
>> about decoupling the ORM from the 'upper' layers of Django, its hard to not 
>> also think what opportunities that would open up for async efforts. How do 
>> you see the architecture of Django channels accommodating such improvements 
>> in future? At the moment your focused on keeping things compatible and 
>> avoiding the need for any of the existing synchronous Django code to 
>> change, is this introducing any design tradeoffs that you are aware of with 
>> regards to hypothetical future developments?
>>
>
> So, what you propose obviously isn't feasible in the short term - I'm 
> doing as much as I can to decouple Channels from "rewrite all of Django" - 
> but notably, channels is a subset of the actor model. In particular, you 
> could see consumers as stateless, single-action actors - but, this means 
> that any future abstraction would be able to build on that.
>  
>
>>
>> Django Channels feels like it contains a possible asynchronous 
>> replacement for signals but is 'holding back', many cases where I can see 
>> myself using a channel, I'm using them with a signal handler, can you 
>> elaborate a bit on your thoughts here? I assume its a compatibility 
>> decision, but is there more to it than just that? 
>>
>
> It's entirely a