Hello everybody,
I've fixed very little code in django admin (inlines.js, actions.js)
which makes it forward compatible to jQuery 1.6.
I'm willing to share it, i created a ticket
https://code.djangoproject.com/ticket/17373 before i realized i was
using a different version of jQuery.
So my questi
Hello everybody,
Currently, Django ModelForm enforces it's local version of save_m2m:
https://github.com/django/django/blob/38408f8007eae21b9f1cbbcc7f86d4b2042ff86a/django/forms/models.py#L76
As a result, users who want to overload save_m2m can not support
commit=False:
https://github.com/yourla
Hi all,
Is it possible to trigger an event on add-another ?
Or is there a better solution to work around this problem ?
https://github.com/yourlabs/django-autocomplete-light/blob/master/autocomplete_light/static/autocomplete_light/widget.js#L267
Thanks for answering
Regards
--
You received th
Hi all,
More projects use AJAX nowadays. Django could help them more.
For example, FormView, could check if request.is_ajax_request(), and in
that case return a JSON dict for example:
{
'html': ,
'messages': [],
'error_fields': [],
}
All generic views could do something like this. T
All Django admin would have to do is call:
$(this).trigger('django.admin.another_added') or something like that.
It really sounds like little work and would allow user defined callbacks to
be executed.
What do you think ?
On Fri, Nov 9, 2012 at 12:29 PM, James Pic wrote:
> Hi a
Hello everybody,
Thank you for your feedback. And pretty soon I will tackle this problem in
an external app - or consider joining the party if somebody else has
started, in this case feel free to let me know.
I can understand most of the points made here, expect just one, please bare
with me. Sev
I understand what you mean, I realized my point of view was too
user-centric and not very conceptual. So, thanks for that and I'm still
totally up to make or help making an external app in my
next re-factor session.
Here's a single point I'd like the list's attention: it would be great if
we could
22 PM, Javier Guerra Giraldez
wrote:
> On Sun, Nov 25, 2012 at 12:04 PM, James Pic wrote:
> > it would be great if we could make urls easier to reverse in Javascript.
>
> you shouldn't have to.
>
> good REST design means not using database IDs. any response that
> referen
I've set up the test_project of one of my apps -
http://jpic.pythonanywhere.com/ (user/pass: test/test) it went pretty well.
Great work !
One question thought, most of the time, free accounts disappear at some
point, when the company grows. Are you committed to maintaining free
accounts ?
Thanks
It's great! I just have a few questions:
- would it be useful to mention that if the app lives in a separate (ie.
open source) repo, it will need the repo to contain a test_project to run
`./manage.py test theapp` in CI systems ?
- would it be useful to add an example .travis.yml and some info abo
I'm not sbure but I think you can make an external app that overrides
syncdb and creates optimised many to many tables before handing the job
django's syncdb. If the tables exist, django won't create them.
On Wed, Nov 28, 2012 at 9:56 PM, Anssi Kääriäinen
wrote:
> On 27 marras, 21:11, Trey Raymo
This might also work:
https://github.com/simone/django-compositekey#customize-the-manytomany-intermediate-modeltable
On Fri, Dec 7, 2012 at 10:51 AM, James Pic wrote:
> I'm not sbure but I think you can make an external app that overrides
> syncdb and creates optimised many to
There are *many* apps providing bootstrap templates for
django.contrib.admin, here a few:
- https://github.com/michaelhelmick/django-bootstrap-admin
- https://github.com/gkuhn1/django-admin-templates-twitter-bootstrap
- https://github.com/riccardo-forina/django-admin-bootstrapped
- https://github.
Sometimes I had to enable DEBUG and disable TEMPLATE_DEBUG in order to
get useful information about a crash. Am I the only one ?
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this grou
You should use something like bitbucket or github.
Did you check existing form libraries like django floppy forms or
django crispy forms ?
I think this belongs to django-users as well.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributio
Hi all,
I've had this issue reported for the second time in
django-autocomplete-light's tracker.
For the first time on Jan 16th 2014 by a user whom I thought was a
django core-dev so I didn't really bother following up on this - I beg
your pardon for that.
This has also be reported a few hours a
Done. Will debug the [French] out of this tomorrow at the sprint.
Le 3 juin 2015 16:01, "Tim Graham" a écrit :
> Yes, it looks like a legitimate bug. Please file a Trac ticket.
>
> On Wednesday, June 3, 2015 at 8:55:47 AM UTC-4, is_null wrote:
>>
>> Hi all,
>>
>> I've had this issue reported for
In DAL we mostly moved autocomplete_light/__init__.py to
autocomplete_light/shortcuts.py, and we're trying to make a fuss about
it on internet so that users using google before opening issues find
it :D
It would be great if other libraries used the same renaming for the
sake of consistencies betwe
Awesome, we can drop support on that one:
https://github.com/yourlabs/django-permissions-widget
Keep up the great work !!
--
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
Hello everybody,
Do you think uWSGI deserves a place in the official django documentation ?
I think it should because it's easier, safer, faster and more secure
than flup or mod_wsgi. Also, it made my sysadmin life really easy and
that's something cool to share with the community.
In this case,
Hello everybody,
Sorry if this topic has already been brought, I asked about it on IRC but
nobody answered.
Being a old user of xUnit patterns in several languages, i just figured that
there might be a mistake in django testing documentation example.
The example is: self.assertEqual(self.lion.sp
On Wed, Jul 3, 2013 at 7:25 PM, C. Kirby wrote:
> I just ran into an issue where a user was copy/pasting username and password
> from a text file into the login screen. For some reason the c/p process was
> adding a trailing space to their credentials and they were failing login.
>
> Is there a re
GitHub has great http support now, which includes pushes. I think the
documentation could mention https git urls everywhere:
- let users who know about the benefits of ssh keys use them on their own,
- let the others send their GitHub username/password at every push.
--
You received this message
Why not just override the username class attribute in your subclass ?
by None or even something which returns instance.email.
In reality I have no idea, some of my users are using their email
address as usernames and it's not a problem for django, so anything
project-specific would sound a little
I should state that I have no education and that I have the feeling
that I understand GCBVs perfectly.
But django-vanilla-views are not as usable because you cannot reuse
isolated pieces of functionality like you can with mixins.
Maybe this is a documentation problem ?
Maybe the docs should expl
Hi all,
I found that there was a hard coded 2 seconds limit in
StoppableWSGIServer.shutdown:
https://github.com/django/django/blob/1.6/django/test/testcases.py#L999
This causes problems on slow boxes ie. travis:
https://travis-ci.org/yourlabs/django-autocomplete-light/jobs/15177543
Can we enable
Russ I think it would work if the timeout was just increased.
On Tue, Dec 10, 2013 at 12:36 AM, Shai Berger wrote:
>
> This would be a new feature, and I think it is a little late for one of those
> for 1.6. In 1.7, the whole StoppableWSGIServer class is gone -- with Python
> 2.7 and above, the s
Hi all,
Generic Foreign Keys is pretty useful, do you think Django could provide a
model with 2 GFKs and Generic Many-to-Many fields ?
There is a little old implementation in an app that has been out there for
a while so it's pretty old: https://github.com/coleifer/django-generic-m2m/
We could p
Hi all,
In Select widgets, as well as many other (including MultipleHiddenInput,
where it's not used) rendering methods all have a choices=() kwarg and use
a chain(self.choices, choices) when rendering.
Maybe I'm missing something, but it seems like this has just been sitting
there since 2006 and
Felt free, thanks for answering.
--
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...@googlegroup
Hi all,
Many apps provide new related managers to extend your django models with.
For example, django-tagulous provides a TagField which abstracts an M2M
relation with the Tag model, django-gm2m provides a GM2MField which
abstracts an relation, django-taggit provides a TaggableManager which
abstra
Hi all,
My understanding of the design issue I'm facing was too approximative
at the time I opened this topic, sorry about that.
The way I understand it now, is that we have only 2 moving parts but 3 features:
- input validation in the form field,
- business logic in the model field,
- problem:
Thanks for the advice, I started trying moving form-related stuff from
FieldBase into a new ModelFormFieldBase class, and it turns out that
there's a lot more we could, or should, move than just
value_from_object and save_form_data.
Why not move out everything that couples the form field and the m
Sure, my bad, this is the example with form_business, a GFK, before /
after: https://gist.github.com/jpic/c6a16723db62f779848f
If we make it to encapsulate value_from_object / save_form_data
elsewhere than in the model field then it will allow form fields and
forms used in the admin to do more.
Just click "Details" and then "Console output". You'll find this:
+ flake8
./django/contrib/sessions/backends/db.py:91:30: E901 SyntaxError: invalid syntax
ERROR: /home/jenkins/workspace/isort/django/contrib/sessions/backends/db.py
Imports are incorrectly sorted.
--- /home/jenkins/workspace/isort
Hi all,
Currently, the model field defines the default form field that's used
by the modelform metaclass. It would be nice if an external app could
overwrite this.
For example, a user installs an app which provides a more elaborated
relation select field. They configure the app to be able provide
Thanks Tim. Something like that would work, perhaps the first step
would be to make modelfield.formfield a bit more configurable ?
Currently, the default form field class for a model field is hardcoded
in the model field's formfield() method, ie:
https://github.com/django/django/blob/master/django
Hi !
Currently, by default, django's ModelForm uses form fields which are
known to be compatible for the modelfield.
By "compatible", I mean that it works when the ModelForm calls:
- ModelField.value_from_object() to get the initial formfield value
for the model's field, via model_to_dict:
https
On Wed, Mar 9, 2016 at 3:09 PM, Johannes Hoppe wrote:
> We'll you can change the `default` form Field using
> `django.db.models.Field.formfield`.
Do you mean that, for example, an app like django-select2 could
provide the following model fields ?
- Select2WidgetForeignKey,
- Select2WidgetOneToOn
I just meant that currently, if a user wants to make Select2 the
default widget for a model field, it is necessary to subclass the
modelfield class and override the model field's formfield() method
just to change the default widget it uses, sorry if it wasn't clear !
--
You received this message
Hi all,
There's a pattern I like to use in my projects which I'd like to
suggest for django startproject.
It looks like:
project_name/
setup.py
src/
myapp1/
myapp2/
project_name/
settings.py
urls.py
manage.py
wsgi.py
My settings.py here uses environment v
That sounds pretty fair, particularly since the new default settings
provide a great ootb experience.
Thanks for your feedback, keep up the great work !
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To u
Perhaps django-modeltranslation could help too:
http://django-modeltranslation.readthedocs.org/en/latest/registration.html
(I really like this app BTW)
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To uns
On Tue, Mar 15, 2016 at 1:59 AM, Ramez Ashraf wrote:
>
> 1. Inlines (FormView is like a teenager playing in the park next to Spartan
> Hero)
There are inlinemodelformsets you can use outside the admin.
> 2. Entry Log change message
django-activity-stream or even django-reversion
> 3. Various
Hi,
OpenShift Origin is an Open Source PaaS system based on cool stuff
like kubernetes, docker, ansible, golang ... developed mostly by
RedHat. It's probably comparable to Heroku, but more flexible and
completely Open Source (thanks RedHat !!).
I use OpenShift every day, including for a few open
Perhaps, should we also start moving mod_python / uwsgi docs upstream ?
--
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 dj
Pretty nice docs they have nowadays I recon !
Perhaps we don't need documentation for all open source PaaS out there
(ie. DEIS, the open source heroku-ish PaaS for CoreOs). Having at
least one could help though.
The only documentation about deploying django apps is in their blog
and it's not very
I'd like to illustrate why I think having official documentation about
deployment on PaaS would be great.
What I mean by "there is confusion", is that IMHO on a PaaS SECRET_KEY
should be managed by settings.py in an automatically created file in a
private and persistent directory.
For example:
h
Sorry for to quoting:/
--
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
What do you mean stuck? Aren't you supposed to port the packages and submit
a patch in that case? How are you stuck ? I know the first portings are
hard but once you've ported a dozen it becomes piece of cake so don't be
afraid of trying ! And please contribute to the apps !!
I know some people wh
FTR, there's also Djangonauts which have been there for a while:
https://github.com/djangonauts
Sorry, I tried not to look uncivil - and yet I fail to see where I
was, but definitely re-reading and thinking about it (I'm not an
english native speaker). Please anyone feel free to PM me and point me
On Thu, Mar 17, 2016 at 2:17 PM, Tim Graham wrote:
> It seems useful, but I'm not sure if it increases the coupling between model
> and forms in an undesirable way?
The coupling is already there because model fields sit right
in-between the db and form fields, so I don't know if it would
actually
If we prefer to remove form related stuff from models, then we should
be able to register new default model forms:
models.py:
class YourModel(models.Model):
your_field = models.BooleanField()
forms.py:
class YourModelDefaultForm(django.?.ModelFormConfiguration):
class Meta:
help
Perhaps it is a bit early for this but Is there anywhere origin is checked
against ALLOWED_HOSTS ?
Middleware support would be nice to but I guess you'll come to that when
implementing user authentication.
Keep up the great work !
--
You received this message because you are subscribed to the G
Hi all!
Perhaps the wiki is the best place for this kind of things?
Thanks for your feedback
Best
James
On Mar 16, 2016 12:59 AM, "James Pic" wrote:
> I'd like to illustrate why I think having official documentation about
> deployment on PaaS would be great.
>
&g
On Wed, Mar 16, 2016 at 3:22 PM, Matías Iturburu wrote:
> Even if I submit a patch I wouldn't be able to:
> - Merge it into mainline.
> - Upload the patched version to pypi.
>
> So it's a no-starter,
> I can't rely on my fork, not for production, as I
> should guarantee that the package it's, at l
Yes, overriding the model field to change the definition of
formfield() works. It is indeed possible to define two model field
classes which have different formfield() methods, for example:
ManyToManyCheckboxField()
ForeignKeyRadioField()
Should Django provide such fields ?
formfield_callback is
Hi Connor,
Overall I find it pretty cool that work on this has been started.
There are a few questions I'd like to ask on this proposal.
In this example:
class ReadingDelete(UserPassesTestMixin, DeleteView):
model = Reading
def test_func(self):
user = self.reques
On Sat, Apr 2, 2016 at 10:44 AM, Florian Apolloner
wrote:
> Yeah, I am also mostly worried about this. formfield for me is a quick
> shortcut, if you want to customize it, do it at the form level imo.
Does this mean we can close #26369 ?
--
You received this message because you are subscribed t
Adding dependencies would definitely be a huge step forward. I think
Django doesn't have them because pip wasn't as awesome as it is today
back in the early days, but nowadays it would definitely make sense.
That would mean a bit more work for distribution package maintainers
but if we can start co
Hi all,
I agree with Thomas here, we shouldn't give any detail to the user
blocked because of permission configuration. We should however log
that somewhere like django-rules-light for the admin.
BTW This proposal looks great, keep up the good work B)
James
--
You received this message because
Please test your projects against django master too.
On May 21, 2016 1:31 AM, "Ed Morley" wrote:
> Another idea might be to encourage more packages to test on Travis against
> Django master (with that sub-job marked as allowed to fail, so it doesn't
> fail the whole run) - so any incompatibilitie
Shouldn't the forms refactor happen first ?
--
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...@
I've found testing your own projects on django master to be
tremendously useful. Then, I don't have any surprise when I test on
django alpha, everything passes and I have nothing to do. Not to
mention the tremendous amount of things I learn on the way, at a
slower, more regular pace. Compare this t
There are a lot of interresting things to do, perhaps we could extract
code from the admin into the core ?
An example of this is the django-addanother app, which replicates the
pattern used by the admin add another widget in an app for usage
outside the admin. Would moving that kind of things from
On Thu, May 26, 2016 at 4:37 PM, Tim Graham wrote:
> I'm skeptical of moving anything JavaScript related from admin into core as
> this makes a stronger endorsement of and coupling to jQuery.
Makes sense, would there be any intermediary solution at least ?
--
You received this message because y
Hi all,
Are there any plans to make Site.name translatable ?
Would that be something we want to offer as a feature ?
Thanks
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group
Thanks, I'm really looking for a way to use the models as this is for the
django CMS light project which makes dynamic multi site a central
requirement.
Perhaps we could make this model swappable ?
For now I'm just going to rely on the translatable site level yaml metadata
we already have in plac
Indeed first and last name dont make sense en various culture. In the
Memopol project for exampe where wé have a table of European Parliament
representative we have all sorts of names including (The Earl Of) name
suffix which is part of the reasons our first / last name system was
completely checkm
On Sat, Jul 30, 2016 at 8:08 AM, Josh Smeaton wrote:
>
> I think having a single name field is reasonable for the vast majority of
> cases, but it fails where projects really do need to identify two names for
> things like sorting or categorising.
I'd be willing to believe that a project requires
Aymeric, it doesn't matter if tens of milions of names fit into your
model, it only takes one to have a issue that's going to require the
project developers to invest time in it. So I'm a bit lost about
what's the most practical approach here.
--
You received this message because you are subscrib
Thanks for your reply Aymeric. If I understand correctly the best way to
approach this, besides increasing the current limits - which I've had to do
myself a few times - is to create a separate app providing a custom model
with an ArrayField for name (sorting) and a migration script, and let time
t
Hello list \o/
Currently, we can attach scripts and css by declaring their urls in Media.
It then renders the script and link tags, allowing users to have that
outside the form tag in the template, ie. in the HTML head.
A good way to pass a widget's configuration from python to js is to pass
them
Thanks for the heads up, a similar ticket has been closed as wontfix,
because it isn't compatible with CSP:
https://code.djangoproject.com/ticket/13978
While I'm all against inline scripts, I have a use case which seems be
legitimate:
https://github.com/yourlabs/django-autocomplete-light/pull/733/
True, this is a feature that's been invented a countless number of times.
Perhaps one implementation could be supported by the organization ?
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe f
Nice one Matthias !
We might have something similar, in dal, discussion is undergoing:
https://github.com/yourlabs/django-autocomplete-light/issues/756#issuecomment-252368089
Currently ddf also renders json in a script tag in the middle of the form,
i think I might take the same direction as you
On Tue, Oct 11, 2016 at 2:20 PM, Johannes Hoppe
wrote:
>
> At the current point I don't see how we could add a more generic widget to
> Django outside of the admin. This would require ether a manual registration
> of models as autocomplete light does it, or another approach that doesn't
> rely on
Perhaps we could override this default with a setting ?
--
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+
I recon i use a single settings module that feeds from env vars for any
project i touch myself, but I suggested adding a setting because that would
leave the choice up to the user like it's currently the case in django
projects (some people still rely on local_settings import or use several
setting
Hi all,
I'm looking for a way to override the default form field widget for some
fields of some model classes, at the project level.
Currently, we have to override all the model classes for that. That's
considerable as a hack, because we don't exactly want to "override the
default in every form c
Wow, nice memory Tim !
Yes it's a problem I've been trying to find a solution for during the last
years. We've had a solution in DAL v2 by providing a custom model form
which would make relation fields to a model that has an autocomplete
registered use an autocomplete field by default. This soluti
Thanks for your suggestion Adam ! However, I have a feeling that to apply
that technique on the flatpages use case we'd also have to:
4. Monkey patch django.contrib.models.FlatPage.content,
5. Override and deal with flatpages migrations from now on.
The proposal removes the cost of steps 1., 3.,
Absolutely ! If we don't want to monkey patch, we can use the other step:
4. get control on the flatpage form in the admin:
https://gist.github.com/Kub-AT/3676137
Then, there's the fatpages use case. Fatpage is an imaginary fork of
flatpages that adds create and edit views. In this case, we also n
Thanks a lot for your time and quick answer Adam ! The ModelFormMetaclass
usage you suggest is not supported by Django at this point. Suggesting that
doing it is easy and supported seems incorrect in my experience, starting
with the fact that there is no documentation.
There are a lot of problems
Thanks for your reply Adam ! To make it general purpose, perhaps we could
make such a patch in Django and replace should_fixup by a signal ?
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe fr
Hi all,
Currently, the model fields define which form fields should be used for
them by default. That's why we have to specify form stuff such as "blank"
when declaring our model fields, and pretty much everybody would like to
see a fix appear.
Would it be possible to add a new option for users t
There is a history of problems related to the coupling between forms and
models. For example, when a user suggested to pass a field instance to the
model field to make it default [0], or when I suggested to improve
formfield [1]: it was rejected because it would increase the coupling
between forms
If you've been maintaining several django apps for several versions of
Django (ie. stable, oldstable, lts) then it's pretty easy to imagine how
useful this can be. The deprecation policy removes the need of a
compatibility layer for code that should support only one version of
Django, but does not
On Wed, Feb 15, 2017 at 12:21 AM, Adam Johnson wrote:
> Sorry for the terrible pun here, but I'd like to suggest the
> meta-feature... allowing 3rd party apps to add their own options to Meta
> classes. If there was a sensible API for this (or if Django just copied all
> attributes defined in Met
Hi all,
It seems like runserver won't retry to connect to the database after a
failing connection. Once the db server is up, it looks like I have to
restart runserver manually.
If this is correct, may I suggest that we make runserver retry connecting
to the database if it fails ?
Thanks
--
You
Sometimes it's not started because some modern orchestration tools such as
ansible-container and docker-compose (perhaps more) start everything at
once, and django might be faster than the db, or I have to fix something
with the db orchestration tool.
I noted we might have the same issue with redi
Thanks for your feedback, the use case i was talking about is not quite
valid anymore, since docker-stack and docker-compose v3 do handle
dependencies.
However, perhaps runserver could just exit if checks don't pass, which
makes sense I think, allowing the optional use of a shell loop. I'd prefer
until manage check; do sleep 1; done; manage runserver would work for me
then, thanks Shai !
However, I'm still a bit puzzled by having a process that's just stuck when
checks fail (if I understand correctly) is there any particular reason why
it is this way ? If not, perhaps a retry or exit could
Seems similar to this discussion:
https://groups.google.com/forum/#!searchin/django-developers/forms%7Csort:relevance/django-developers/zG-JvS_opi4/wS-4PBfPBwAJ
Yes, signal/slot is a pattern that allows quick and easy decoupling of
components that have to work on the same payload, and I've been us
Thanks for sharing some of your insight Aymeric, if I'm not mistaken then
the auto-reload feature/case invalidates Shai's suggestion: would you
recommend that the runserver process exits with non-zero when a check fails
rather than being stuck waiting for another code change to trigger a
reload, so
Sure, this probably involves allowing Form instance definition by
composition with a new object (ie. FormConfiguration,
ModelFormConfiguration ...) rather than by subclassing Form or ModelForm.
I'll make a complete writeup about it ala Diderot then haha
--
You received this message because you a
It works on SyntaxErrors because updating the code triggers a reload, but
if the check fails for something that's not related to code (db conn, redis
conn...) then it's stuck and we have to manually interrupt runserver to
start it again, unless we touch some code just to trigger the reload as you
m
It seems like we have 2 kind of issues:
- code broke runserver,
- network broke runserver.
In the first case, runserver waits for a code reload event which is perfect
;)
In the second case, runserver also waits for a code reload event, which is
not very intuitive after fixing a network error.
So
I do not see myself using Django without Channels anymore, it's become a
basic Django feature for me and I just love it. Despite my perhaps lack of
knowledge about the protocol internals, such features seem like it would
certainly benefit the Python community and anyway I'd say it's worth a try
jus
On Mon, Mar 13, 2017 at 12:26 PM, Etienne Robillard wrote:
> ASGI is for building platform-oriented web applications in Django.
Could you elaborate on this ? The only mention of Django I found in
the spec linked by the OT is "Django Channels ships with a no-op
consumer attached by default; we rec
1 - 100 of 109 matches
Mail list logo
