open
GitHub issues against the project.
Since I see you have cross-posted this question to both lists (please don't
do that), I will answer on django-users.
Andrew
On Sun, Oct 16, 2016 at 9:37 AM, Amirtpal wrote:
> Hi Django folks,
>
> Just a couple of questions on using Django
I would say that a command to re-optimise a single migration would be a
good idea, especially since it needs no changes to the stored set of run
migrations since it would theoretically do the same thing.
Andrew
On Mon, Oct 31, 2016 at 1:58 PM, Shai Berger wrote:
> Hi,
>
> I
t;> $ python -m unittest discover -p 'test_functional_*.py'
>>>
>>> Unfortunately, you'll lose a lot of power in not being able to reuse
>>> your form code, assert anything about the database state on the remote
>>> server, access django assertion m
s like this (or having another maintainer do it)
on roughly a monthly basis going forward, though there'll be less content
than this first initial knowledge dump. I'd like to make sure people can
keep abreast of Channels work and plans without scouring through the
mailing lists and
a few checks for what
it means to be maintained? It's not something I think we could make hard
and fast rules for, but a sort of checklist for us to use to check
dependencies every release might be useful.
Andrew
On Sat, Nov 5, 2016 at 1:23 PM, Jacob Kaplan-Moss
wrote:
> Hi all -
>
>
ration runners - you can re-use all the nasty work in
the schema editing interface and just replace the other part. This huge
change is the sort of thing I'd want to see working and proven before we
considered changing core, preferably as a third-party app, but of course
I'd like to talk through p
es, constraints
etc. involved.
I wrote a more advanced introspection backend as part of the migrations
work, but you'd need to extend it even more and improve upon features like
foreign key implication before it would be possible to do this.
Andrew
--
You received this message because yo
teeth into, as we
can then start making all the other parts of Django async-capable as a
parallel effort.
Reviews and comments on the PR are encouraged; I want to make sure this is
not going to hurt existing sync Django when it lands, and that it's a
useful stepping stone towards async in view
es long, we might want to consider a
better avenue for constructive feedback.
Andrew
On Tue, Apr 30, 2019 at 12:31 PM Christian González <
christian.gonza...@nerdocs.at> wrote:
>
> Am 30.04.19 um 14:28 schrieb 'Laurens A. Bosscher' via Django developers
> (Contributions
>From my read this also looks like it would make the auto-reloader able to
work a lot better with an async-capable server, so I would be in favour
given that is likely in the future as well.
Andrew
On Tue, Apr 23, 2019 at 9:33 PM Ramiro Morales wrote:
> Hi all,
>
> I had a stab a
So, it looks like most of the comments on this PR have happened and been
resolved - unless anyone has any objections, I will merge it in after a
couple more days (just in time for PyCon US).
Andrew
On Wed, Apr 24, 2019 at 1:50 PM Andrew Godwin wrote:
> Hi everyone,
>
> Just wanted
re means we get to skip writing this up, and from
here on out it becomes much more of a new feature than merely adding safety
and a new handler.
Andrew
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
This is quite unrelated to frontend - I'll explain more of the impact and
potential impact in the DEP when I write it up.
Andrew
On Wed, 1 May 2019, 08:30 Elad Yaniv, wrote:
> Exciting stuff!
> does this mean that django 3.0 COULD compete with frontend js frameworks
> ? (ang
y 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 fro
or synchronously, that's
fine - it takes literally zero extra effort to go either way".
This is why I propose in the DEP that we do the view layer first, and then
move onto the ORM as a second wave.
Andrew
On Thu, May 9, 2019 at 12:29 PM Patryk Zawadzki wrote:
> I'm not s
t not as part of
this async push.
Andrew
On Thu, May 9, 2019 at 12:56 PM Patryk Zawadzki wrote:
> That said, I also think it's important to allow the ORM to support both
>> modes in the long term. I truly believe the best way to be able to write
>> async code is to _have the
On Thu, May 9, 2019 at 1:04 PM Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> Hello Andrew,
>
> Thanks for your work putting together this plan. Within our constraints,
> it's a good plan.
>
> Regarding templating, I would say it isn't a priori
own research and proposal, probably, but it might be a nice way out of the
initial thing of requiring select_related. I just don't know enough about
how that might cascade down the ORM internals to judge it at this point!
Andrew
--
You received this message because you are subscrib
he ORM so people can't screw up by accident. It would be quite easy to
extend this to enforcement on both the sync and async versions - there's
maybe an edge case that you can call an async function from a thread you
have not started an event loop in _yet_, but I'd rather see if and when
ing on an async ORM that works within Django?
>
It is indeed encode/databases!
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 f
on in the DEP that
says why we can't do it in a separate package, but basically, the changes
required to Django are too deep to do separately (or even as a long-running
fork).
Andrew
--
You received this message because you are subscribed to the Google Groups
"Django developers (Co
stin, for his work on writing and updating the
DEP!
Yours in auto-formatting,
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
One quick clarification - when I said "stable (1.0)" release, I in fact
meant the first release that the Black project officially marks as stable.
Black doesn't use versioning that would result in a stable release being
called 1.0, as far as I know, given they are on 19.3b0 rig
On Mon, May 13, 2019 at 4:31 AM Tobias Kunze wrote:
> Hi Andrew (and everybody following the discussion, of course),
>
> First off, thank you for your work here. DEP9 is an excellent technical
> document, and it was as easy and pleasant to read as a document of this
> scope a
writing up a funding plan for this, including
various options for how we can pay people for their work.
Andrew
On Tue, May 14, 2019 at 2:55 AM Andrew Godwin wrote:
>
>
> On Mon, May 13, 2019 at 4:31 AM Tobias Kunze wrote:
>
>> Hi Andrew (and everybody following the dis
p consistency
with Python core to lower the workload. If Python core turned around and
blessed greenlets and gevent as the chosen async solution, I'd change my
mind, but I haven't seen any evidence of that over many years.
Andrew
--
You received this message because you are subscr
one (
https://twitter.com/_tomchristie/status/1005001902092967936) using Python
asyncio/ASGI - and see that it does make a difference. Obviously it doesn't
matter for all deploys, but I believe it matters for the majority of site
architectures as they scale up.
Andrew
--
You received this message
ug and say
that Python async isn't ready. However, I've been working with it for the
last four years, including on several very large deployments, and there are
some direct benefits that I believe we can get without making things a lot
more complex, even inside Django.
Andrew
--
You
The DEP is drafted and in the DEPs repo, and awaiting approval by the
freshly-elected Technical Board once I submit it. In the meantime, we
landed the ASGI patch, as well.
Andrew
On Tue, Jun 25, 2019 at 3:30 PM Chris Barry
wrote:
> Hey all,
>
> Just wondering what the future of this i
e.g.
migrations) rather than direct file access (like templates).
It would be nice to investigate this a bit more, though. If we can get
Django compatible, or work with PyOxidiser if we find a reasonable
workaround they could implement, it would be great.
Andrew
On Thu, Jun 27, 2019 at
dules.
Andrew
On Thu, Jun 27, 2019 at 2:01 PM Peter Baumgartner
wrote:
> The big issue I see is that a resource must reside directly in a
> Python module. You can not load a resource from a child directory,
> e.g. I can load "index.html" from the Python module
> "myproj
uture async work.
If you are interested in helping with fundraising, then please get in touch
with me directly; I have some ideas about how to structure it, but I could
do with some people to help out. Otherwise, stay tuned for more information
about how to get involved contributing and what to work
I'll ask permission and then summarise the points raised back out here!
Andrew
On Sun, Jul 21, 2019 at 1:01 PM Jacob Kaplan-Moss
wrote:
> Congratulations, and great news!
>
> I hope the TB will consider sharing details and/or a summary of the "long
> and involved vot
On Sun, Jul 21, 2019 at 1:11 PM Ehigie Aito wrote:
> Django 3.0?
>
Django follows time-based releases; what's in Django 3.0 will depend on
when we can get it landed. At the moment I am optimistic something will
make it in, but I make no promises!
Andrew
--
You received this mess
oard, this is by far the most detailed a vote has ever gotten, and
I can only apologise to the incoming board for springing this on them right
after an election!
If anyone on this list would like to continue to talk about the above, or
if a Board member wants to bring their conversation out here, y
I agree too. Let's change it.
Andrew
On Sat, Jul 27, 2019 at 4:03 AM Markus Holtermann
wrote:
> Easy: +1 from me as well for reasons state before.
>
> /Markus
>
> On Sat, Jul 27, 2019, at 6:15 PM, Adam Johnson wrote:
> > +1 from me too for the reasons that Aymeric sta
y hard to scale - it needs
stateful storage to aid in transferring connections, and this means it's
really hard to have a single method that will work for everyone. Having
"one right way to do it" is sort of a necessary prerequisite to having
something in Django, and I just don't feel
t the question I'd really want everyone
to answer is if it's worth the porting effort. I suspect the answer is yes,
but this does need a process DEP and some discussion, and maybe also
looking at what cpython are doing and comparing and contrasting.
Andrew
On Wed, Aug 7, 2019 at 4:12 AM
with an email filter
as I do now!), and honestly the same thing for django-users. That said, I
also recognise that diluting the support/discussion pool is not exactly an
attractive idea, which is why I'm asking for input!
Thanks,
Andrew
--
You received this message because you are subscr
ense I am describing - one that
has categories, editable posts, and the ability to selectively get email
for certain categories or threads rather than all-or-nothing. The Groups
forum interface is more just an online mailing list interface, with all the
problems of the underlying list model.
Andrew
t, though my impression
is that it's relatively easy since he had it up before I'd got off the
plane back to the US. Not sure about the djangoproject.com login situation
- we need to investigate how flexible the plugin system is, and it might
need OpenID on the Django end.
Andrew
--
You
oogle Groups is probably
going to be around for a long time).
Andrew
On Monday, August 12, 2019 at 4:04:23 AM UTC-5, James Bennett wrote:
>
> I'm not necessarily opposed to this, but I am a bit skeptical of the
> long-term archival utility of forums, in large part due to my experience a
Another point has been raised to me by someone off-list - adding a forum
would significantly increase the surface area that the Code of Conduct team
have to cover (and potentially become one of the biggest time sinks
required), so we need to consider them in any decision.
Andrew
On Mon, Aug 12
ck thread over in the forum (
https://forum.djangoproject.com/t/forum-feedback/17/).
See you there!
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
I agree - we need to communicate that ASGI support does *not *mean you can
start writing async def views. I think we should put a big disclaimer to
that effect next to it in the release notes and say it should be coming
next release.
Andrew
On Mon, Oct 14, 2019 at 5:45 PM Josh Smeaton wrote
proper story and hooks for running Django as a service (i.e. outside of
a traditional HTTP request/response cycle)
And some ludicrous projects I'd still consider:
* Evented/event-sourcing database work on top of the ORM
* A GraphQL-to-ORM mapper
Andrew
On Tue, Dec 10, 2019 at 8:25 AM Ca
areas (the current
set in djangobench are weak in, say, the HTTP-serving-speed area) and then
run them against pull requests and each release, so we can make sure Django
doesn't get slower while nobody is looking.
I'm sure there's a lot more, but these are top of mind at the moment!
A
I am particularly excited for native async support arriving - that's
something I'd love to have and ship support for from our side when it's
done. The rest looks quite sensible too.
Andrew
On Wed, Mar 11, 2020 at 3:39 AM Jure Erznožnik
wrote:
> His proposed changes look aweso
I also vote in favour of Claude becoming a Merger!
Andrew
On Tuesday, April 21, 2020 at 4:28:41 AM UTC-6, Markus Holtermann wrote:
>
> I vote in favor of Claude becoming a MERGER.
>
> Cheers,
>
> Markus
>
> On Thu, Apr 16, 2020, at 10:31 PM, charettes wrote:
> &
ly matters, and while the
date is sometimes useful for people to resolve merge conflicts, I don't
think it's better than more informative autogenerated names, so I'm happy
to go with the change.
(60 is a bit long though, maybe we can bump it down to something a bit
shorter?)
Andrew
quash down to just a couple of
migrations each app, it would be nice to have that be a shortcut.
Andrew
On Wed, Apr 22, 2020 at 10:35 AM Javier Buzzi
wrote:
> This comes from a place of headaches: we're a large team, and our sprint
> are a month long, in that month we generate a l
Yup, I'm seeing if we can get asgiref fixed today, otherwise I'll revert the
change that broke Django and issue 3.2.9.
Andrew
On Tue, Jun 16, 2020, at 2:48 AM, Florian Apolloner wrote:
> Ok, so rebasing PRs to current master will fix this (leaving this here as
> note for oth
d
they're working on something, and if it allows seamless migration, that'd be
great. That said, if they take more than a month or two, we should just change
it and get it over with.
Andrew
On Tue, Jun 16, 2020, at 12:59 PM, Adam Johnson wrote:
> On the branch rename, right now I&#x
ones I
work on. Migrations isn't meant to only be "makemigrations" and the model-based
approach; there's also an underlying SQL application and dependency ordering
engine that can be used standalone.
Andrew
On Thu, Aug 6, 2020, at 1:27 PM, Paolo Melchiorre wrote:
> HI
that would be my suspicion as to why this
would be structured this way in my original code. As you say, the optimiser has
improved in the years since, but I don't think you can optimise away the
circular reference problem?
Andrew
On Sat, Sep 19, 2020, at 3:20 PM, Silvio J. Gutierrez wrote:
Hey guys, I'd like to contribute to the effort to make Django more async
capable. I've started to write an aioredis based cache backend based on
django-redis, but I noticed the BaseCache in Django is still all
synchronous basically.
I was wondering which backends I should make async capable and
r all
of them and if everything can be made to work regardless of what mode (sync or
async) it's in; hopefully there's a lot less long-lived-connection issues than
in the ORM, say.
Andrew
On Sat, Sep 26, 2020, at 3:56 PM, Adam Johnson wrote:
> Hi Andrew
>
> I don't be
Hey Adam and Andrew,
I can definitely make the naming scheme something like get_async() rather
than just get().
> This section specifically says that the default implementations will back
onto the sync methods by default, so built-in cache backends won't need to
all be converted
Cool, thanks for the clarification. One thing I noticed while programming
the test cases (so WIP is
here: https://github.com/Andrew-Chen-Wang/django-async-redis) is that it's
not really fun having to type out get_async since autocomplete. If a dev
knows that they'll be using an awa
.
I think right now I would prefer get_async all things considered, since I don't
think autocomplete is necessarily easier either way, but I'm open to
suggestions.
Andrew
On Sun, Sep 27, 2020, at 6:03 PM, Andrew Wang wrote:
> Cool, thanks for the clarification. One thing I notice
Hi all,
1.5 weeks ago, I posted that I was interested in making Django's cache
async. Just here to report that the package for django-async-redis is on
pypi and the repo is
here: https://github.com/Andrew-Chen-Wang/django-async-redis. Please test
it out. I have only tested it on a
elp debug it further.
Andrew
On Tue, Oct 13, 2020, at 10:37 AM, Adam Johnson wrote:
> I'd like to see what Andrew thinks on this.
>
> I had a thought that the issue you're seeing may be related to a dependency
> of your project creating/destroying event loops in the backgr
pervise enough forum API access for you to try it,
Tom.
Andrew
On Thursday, October 29, 2020 at 9:23:45 AM UTC-6 carlton...@gmail.com
wrote:
> I don’t have any controls here. I’m pretty sure Florian would be the most
> likely candidate. (No doubt it’s Jacob.)
>
>
>
--
You recei
I have been moving house this week (plus, yknow, the election) so I haven't got
anything done, but hope to poke at it early next week!
Andrew
On Sun, Nov 8, 2020, at 4:34 AM, Carlton Gibson wrote:
> Hi Tom and Andrew.
>
> This week has been *busy *(shall we say) I know — can I
ite my own script to mash the APIs over HTTP)
Andrew
On Sun, Nov 8, 2020, at 2:36 PM, Andrew Godwin wrote:
> I have been moving house this week (plus, yknow, the election) so I haven't
> got anything done, but hope to poke at it early next week!
>
> Andrew
>
> On Sun, Nov 8,
I agree we should not be quite so beholden to our existing Python version
policy - that was mostly to get us out of the early 3.x era. Now things are
more stable, I'd support a policy that is much more like "any stable version of
Python currently out there and supported".
found here:
https://github.com/Andrew-Chen-Wang/SPA-with-httponly-sessions .
The original purpose of this thread was for SPA development, not really for
JWTs. I'm a maintainer at SimpleJWT, a repository that almost all tutorials
use to show React/SPA/JS Frameworks and Django integration. I
re is wide adoption
for webpack, because of the JS bundles continuously growing (being a huge
turn-off once you have a semi-production-grade SPA repository), I proposed
a moderate idea:
To fix this, I'm going to develop a middleware as described in issue #3
here:
https://github.com/Andrew-Che
alled and can have
everyone developing on it do something at once, you can just do it via a
complete migration reset and be happy. Squashing is for a very specific
backwards-compatibility scenario that, I suspect, many Django projects
developed internally are not in.
Andrew
On Tue, May 11, 2021,
ebsocket.
Specifically, this message would reject a pending socket at the HTTP level:
{"accept": False}
While this would close it with an error code at the WebSocket level:
{"accept": True, "close": 1006}
It's not the best, I'll agree, but I feel like it
n sessions? Is there a bad side-effect of this I haven't considered?
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,
work.
Andrew
On Mon, Jan 23, 2017 at 11:57 AM, Tim Graham wrote:
> I'm not sure offhand. Could you provide a link to the issue so we could
> look at the details?
>
>
> On Monday, January 23, 2017 at 1:45:48 PM UTC-5, Andrew Godwin wrote:
>>
>> An interesting bug ha
and
see if I can see examples of how people call it.
Andrew
On Tue, Jan 24, 2017 at 6:50 AM, Tim Graham wrote:
> The change you proposed might be acceptable, although I'm a bit nervous
> about breaking backwards-compatibility in some unforeseen use case. I
> wonder if modifying the
't touch by
default (e.g. SQL), but it's probably more work to be less generally useful.
Andrew
>
> On Wednesday, February 15, 2017 at 1:22:11 PM UTC+1, rap...@makeleaps.com
> wrote:
>>
>> Hello everyone,
>>
>>I spent a couple hours last night trying
It's in the connect message, as message['client']:
http://channels.readthedocs.io/en/latest/asgi.html#connection
Andrew
On Fri, Feb 17, 2017 at 10:05 AM, Fabien Millerand
wrote:
> As far as I know I cannot get client websocket public IP address with
> channels.
>
g 10 messages a second, you'd only need one
Daphne instances but lots of workers.
The number of connections Daphne can take depends on a combination of CPU
speed and kernel limits; it's not going to be RAM-limited except on very
low memory systems.
Hope that helps.
Andrew
On Wed, Mar 1
, but
anyone else on this list who has an opinion should definitely say something.
Andrew
On Sun, Mar 12, 2017 at 5:44 AM, Sebastian Haase
wrote:
> (sorry for cross-posting - post should like be here rather than in
> django-users)
> Hi,
>
> wsgi is specified by
> PEP 333 -- Py
main asgi_redis transport? It would improve performance on asyncio or
twisted as well.
Andrew
On Sun, Mar 12, 2017 at 9:54 PM, Jon Pry wrote:
> I modified Daphne and the ASGI layer to get the one of the examples to run
> under gevent.
>
> Code is here:
>
> https://githu
ugh? Does async support fit in alright? etc. The
message formats themselves would work on anything that looks remotely
similar.
Andrew
On Mon, Mar 13, 2017 at 5:17 AM, James Bennett
wrote:
> WSGI is a framework-independent protocol to allow HTTP servers to
> communicate with Python appli
Hi Alexander,
I believe Daphne does not yet implement body_channel support for large HTTP
requests, just the response version right now. It's on the roadmap, I just
need to get round to adding it in. Until then, I would advise not using it
for large uploads.
Andrew
On Sun, Mar 19, 2017 at
the two fields.
Is there a reason *not* to make this change? Are there specific reasons for why
we are only checking the `username` field during creation?
Feedback appreciated. If others approve of this, I will open a PR.
Andrew
http://jambonsw.com
http://django-unleashed.com
--
You received
I've always felt that `is_staff` should be changed to a permission such as
`can_access_admin` provided by the Admin app itself. However,
`is_superuser` is slightly different, in that it's not a permission, but
rather a flag that says "this user has EVERY permission". It's also
potentially nonsensic
ed set of channel names, and we can block way more efficiently
on servers like Redis.
I want to know if anyone has any feedback on this, especially from the
"potential problems" department; if not, I'm going to try and get this out
before DjangoCon Europe.
Thanks!
Andrew
--
You rece
t as
well? I think this makes more sense anyway, and that's how asgi_redis will
have ended up after my change.
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 a
I have added that in to the spec:
http://channels.readthedocs.io/en/latest/asgi.html#capacity
Andrew
On Tue, Mar 28, 2017 at 9:54 AM, Artem Malyshev
wrote:
> Yes, I saw your changes after I wrote my previous email.
>
> Global capacity for process sounds reasonable. Probably we should
o with a message, that can not be
> dispatched to a client socket? This should not happen so often.
>
Well, given that the reply channel name is generated by the server itself,
it should not be possible that the server does not know about it when the
client sends it, as the client had to get i
implements the
WebSocket PING protocol to keep data flowing down the socket at regular
intervals.
Andrew
On Fri, May 12, 2017 at 10:52 AM, Victor Porton wrote:
> About https://github.com/django/channels
>
> In the past I dealt with another Python WebSocket engine (unrelated to
> Django). Th
Have you tried removing the staticfiles app from INSTALLED_APPS? I believe
that will disable it even with runworker.
Andrew
On Fri, May 12, 2017 at 11:14 AM, Alexander Prokhorov
wrote:
> Dear Colleagues, in particular Andrew ;)
>
> I have a problem with making Channels serve static f
Then I'm afraid you're stuck for now - you are welcome to open an issue
against the Channels project to fix it and even write a patch if you want,
but as DEBUG isn't turned on for production installs, it'll be considered a
little lower priority.
Andrew
On Fri, May 12, 2017 a
e case.
If you switch to the IPC layer (or the Redis layer), you can still use
"runserver" and then just launch an extra delay server, and all the
components will talk to each other.
Andrew
On Wed, May 24, 2017 at 5:27 AM, Václav Řehák wrote:
> Hi,
>
> one of the things I li
I am personally unsure about this - it's extra overhead for smaller Django
sites, and something that larger teams could easily adopt themselves. I
think it might make more sense as a third-party app that plugs in?
Andrew
On Wed, May 24, 2017 at 12:39 PM, wrote:
> To elaborate on this
gle async handling function, which
seems less than ideal to me, or start down the path of having these things
represented as classes with callables on them - so you'd call
"consumer.connect()", "consumer.receive()" etc., which is probably my
preferred design for keeping the e
of WSGI, and it would not be hard to re-layer Channels
to exist behind this pattern. I think at that point the main difference to
WSGI is the need to persist state somewhere outside the locals() of the
function (as you'll still have separate coroutines for
connect/receive/disconnect).
Andrew
nd the restriction about not allowing blocking-listening
within a consumer makes deadlock way, way harder.
Any interface like this would literally just be "this function gets called
with every event, but you can't listen for events on your own"; HTTP
request bodies being not an e
roblem means you simply cannot design around having
things all work in a single coroutine unless you go all the way and
guarantee that things are _always_ in the same thread so you don't need to
do sticky routing.
Andrew
--
You received this message because you are subscribed to the Google Groups
&
ations and ALTER TABLES this would result in on a
large project. We could include in the upgrade notes how to stave it off
(explicitly specify an ID field), but I'm sort of on the fence as to if
that's good enough.
Andrew
On Sat, Jun 10, 2017 at 9:53 AM, Collin Anderson
wrote:
> I mig
Presumably the equivalent would be true of eg. twisted.
>
> (There's a couple of diff things you can do to bridge from the asyncio
> interface -> sync interface if that's useful)
>
Yup, you can't make cross-compatible ones. This is why ASGI right now has a
receive() me
on to help you maintain it before we could accept it
(they would not have to be existing core, but would need some history of
open-source maintenance)
The other thing would be to see the existing code have more comments and
documentation; currently it has very few comments, in particular.
Andrew
O
of
what I understand.
> There are also now initial implementations for both WSGI-to-ASGI and
> ASGI-to-WSGI adapters.
>
>
There's a mostly-complete one in asgiref over here for WSGI-to-ASGI:
https://github.com/django/asgiref/blob/master/asgiref/wsgi.py
If you are feeling l
go project some days).
Andrew
On Mon, Jun 12, 2017 at 6:19 AM, Artem Malyshev
wrote:
> Hi Andrew,
>
> I'm very glad to hear it's considered useful. If you look at recent master
> you can see that I've added documentation and comments to the code.
>
> Exact commit
401 - 500 of 630 matches
Mail list logo
