Newforms proxy serialization problem

Hi everyone, I'm posting this here as every ticket I try to submit fails with a "500 Internal Server Error (Submission rejected as potential spam" message. After or around r6625 a bug has been introduced whereby when a newforms error dict is serialized with any serializer (I've tried simplejson a

Re: Newforms proxy serialization problem

sender = forms.EmailField() cc_myself = forms.BooleanField(required=False) form = ContactForm({'subject': '', 'sender': 'invalid_address'}) form.is_valid() json = simplejson.dumps(form.errors) #this should work On Nov 1, 9:14 pm, andrew gleave <[

Re: Newforms proxy serialization problem

Thanks Karen, I'll try that now. On Nov 3, 2:29 pm, "Karen Tracey" <[EMAIL PROTECTED]> wrote: > On 11/3/07, andrew gleave <[EMAIL PROTECTED]> wrote: > > > > > I've added some sample code which illustrates the problem. Still > > can'

Re: default values on database level

would just blow up if you tried to pass a function. Andrew On Wed, Jul 29, 2015 at 4:50 PM, Michael Manfre wrote: > > > On Wed, Jul 29, 2015 at 11:42 AM, Podrigal, Aron > wrote: > >> Hi Loic, >> >> Agree with having a db_default kwarg. >> >> I am not

Re: Keeping apps without migrations?

speed before it goes forward. Alternately, we could modify the autodetector to have a "create only" mode that's more efficient or just write a new generator that is quick because it knows it's only making nonmigrated apps' migrations. Andrew On Thu, Aug 6, 2015 at 4:56 PM,

Re: Ability to migrate other applications

app_a.0003, and then they ship a new version that has app_a.0004, then suddenly app_a.0003 has two different children and the migration solver is going to really hate you. Do you have a proposed workflow or tooling that would get around this? Andrew On Mon, Aug 24, 2015 at 10:54 AM, Emmanuelle

Re: Ability to migrate other applications

t encourage extension with models, etc. I still think Django should make it quite hard to do this and screamingly obvious that you're going down a dark path, but at the same time we should at least have it be possible. Andrew -- You received this message because you are subscribed to th

Re: Keeping apps without migrations?

pseudo-unmanaged, but I see no reason not to have the syncdb-like solution keep working as it at least runs off of SchemaEditor now. Andrew On Thu, Aug 27, 2015 at 5:14 PM, Markus Holtermann wrote: > The general benefit of *not* having migrations is the incredible better > performance to set

Re: CHECK Constraints and migrations

ation Operation classes that people could put into their migrations manually, or potentially have some other way of outputting those migration files with operations in them (a lot of the code to write them out is re-useable). Hopefully someone else has a better idea! Andrew On Thu, Aug 27, 2015 at

Re: CHECK Constraints and migrations

think you want to take a stab at it, you're more than welcome, and I'm more than happy to review patches against migrations. Andrew On Thu, Aug 27, 2015 at 9:25 PM, Gavin Wahl wrote: > That's too bad. I don't think it's really worth it unless the experience > wor

Re: Keeping apps without migrations?

idea, but I'm not sure if it was similar or not. It definitely sounds faster - this is how South did it, of course, and given we now have all the serialisation/deserialisation code for models it would seem to be not too hard to do. Andrew -- You received this message because you are subsc

Re: CHECK Constraints and migrations

g a > check-constraints feature in Django (I'm certainly in favor). > For the record, I am also in favour of this. Andrew -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscri

Re: Making the test suite run faster

I'm on board merging this without Oracle support - if I understand right, it means we just have to run those non-parallel for now, so we're not losing anything, right? Andrew On Sun, Aug 30, 2015 at 1:19 PM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > He

Re: Ability to migrate other applications

till don't have an order relative to each other, so if we change the code in Django that does order resolution even slightly it could result in different operation orders or even different "final" rendered models. Andrew On Mon, Sep 7, 2015 at 5:16 PM, Shai Berger wrote: > O

Re: Optimizing before applying migrations?

so on. There's nothing blocking it from what I know - it shouldn't be too hard to take the loaded operation set and run the optimiser on it before it's applied. Andrew On Fri, Sep 11, 2015 at 2:38 AM, Christian Hammond wrote: > Hi everyone, > > We're working on upgrading

Re: An issue with Django 1.8.6 support for south migrations

I think if the fix is easy, we should continue to support them past 1.7, since we're retaining syncdb support. However, if it's crazy complicated, it's likely not worth it. Andrew On Wed, Nov 4, 2015 at 11:59 PM, David Filipovic wrote: > I have initially created

Re: An issue with Django 1.8.6 support for south migrations

That's an excellent point, Shai - if there are migrations they might be essential to the app functioning. I think in that case we should not have them work on 1.7 and up, and encourage people to send PRs to the apps moving the directory name if it would work with syncdb. Andrew On Sat,

Re: why django 1.9 migrations are essential?

; for correctness reasons, you really shouldn't be anyway. There was some work on adding a "MIGRATE" option to be stuck in the TEST key for databases, but it's not landed yet and wouldn't be till 1.10 anyway. Andrew On Wed, Nov 11, 2015 at 12:59 PM, Tim Graham wrote: > Hi, ha

Re: Non-atomic migrations in Django?

I also agree this looks sensible - I think South even had an attribute like this on the migration class, it just never got ported over. +1 On Tue, Nov 24, 2015 at 8:19 AM, Marc Tamlyn wrote: > +1 to idea and API. I've wished I had this recently - even if it's just so > I can check up on the prog

Re: Migration "rebase", or just an "undo" that works with conflicts

target migrations as well, potentially? Andrew On Mon, Nov 30, 2015 at 7:33 PM, Silvio wrote: > I've had this situation come up too. It would indeed be very useful. > > Django South had something vaguely related: > > http://south.readthedocs.org/en/latest/tutorial/part3.html

Re: Migration "rebase", or just an "undo" that works with conflicts

e the twin-tip check on the migrate command if you're asking to reverse one of those tips; that should solve that issue. Andrew On Wed, Dec 2, 2015 at 2:48 PM, Shai Berger wrote: > On Tuesday 01 December 2015 08:40:34 Andrew Godwin wrote: > > You can undo a migration manually using

MOSS Award to Django

ngo, as well as hopefully release a pluggable app version that will run on 1.8 and 1.9 - I have some plans around how to do that effectively, but they involve hitherto unforged paths around Django and how we package dependencies, so I can't say we'll get there 100%. Andrew -- You re

Re: MOSS Award to Django

an at-most-once delivery style, which will work for operations that aren't critical, or if people build their own retry logic (but at that point, maybe use Celery). Andrew On 16 Dec 2015 07:32, "Shai Berger" wrote: > On Wednesday 16 December 2015 08:08:59 Markus Holtermann wrot

Re: MOSS Award to Django

involved". > I don't agree; I think it's more "do you have enough workers to handle this". Channels makes all workers serve all requests, so if you're doing e.g. video encoding you can't segregate it from request handling. However, you could have multiple c

Re: MOSS Award to Django

approaches (I've been prototyping bits of this for years); this approach ended up being the nicest design and the one I have the most confidence in that we can scale and shard to large work volumes. Andrew On Thu, Dec 17, 2015 at 10:30 AM, Samuel Bishop wrote: > I'm uncertain how po

Channels integration plan, first draft

asing part of it as a separate codebase, though still under the Django umbrella. 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

Re: Channels integration plan, first draft

was basically unused by anyone these days, but hey, happy to be proved wrong. Do we have any usage numbers on it to know if we'd need it for a new standalone server to implement? It's really not hard to add it into the request format, just thought it was one of those CGI remnants we m

Re: Channels integration plan, first draft

wrote: > On 12/17/2015 11:50 AM, Andrew Godwin wrote: > > - I thought SCRIPT_NAME was basically unused by anyone these days, but > > hey, happy to be proved wrong. Do we have any usage numbers on it to > > know if we'd need it for a new standalone server to implemen

Re: Channels integration plan, first draft

over is slightly less verbose than normal HTTP and needs less work to use, but it's not a big saving) Andrew On Thu, Dec 17, 2015 at 9:01 PM, Anssi Kääriäinen wrote: > Is the idea a large site using classic request-response architecture would > get the requests at interface servers,

Re: Channels integration plan, first draft

m to the client). It does mean going a bit beyond the normal dictionary interface for a message to allow a way to stream the contents of a key rather than just read it, but I think that would be easy-ish to do. Andrew On Thu, Dec 17, 2015 at 11:13 PM, Sam Willis wrote: > Hi, > > To s

Re: Channels integration plan, first draft

sts. I think Django absolutely has to adapt to the modern web environment and move away from just rendering templates when browsers request them, and this to me is part of that. If there are other solutions to the same problems I think we should consider them as well; I've just not run across any

Re: Channels integration plan, first draft

eople will want to turn on, and that provides a lot of value in exchange for a slight round-trip performance hit - my goal is sub-5ms, and preferably sub-3. If it starts being 10/20/30 milliseconds of cost, then we'll have to change our approach until it's acceptable. If you don't want

Re: Channels integration plan, first draft

ct handling are basically indistinguishable from the outside. I'll work on another draft that more clearly highlights WSGI and direct request handling in the "keeping Django the same part" - hopefully that will help make things clearer. > > Andrew, I thank you for your patience

Re: Channels integration plan, first draft

On Fri, Dec 18, 2015 at 5:28 PM, Anssi Kääriäinen wrote: > On Friday, December 18, 2015, Andrew Godwin wrote: > >> >> >> On Fri, Dec 18, 2015 at 3:44 PM, Mark Lavin wrote: >> >>> > You seem to be assuming I'm here to foist a brand new middle layer

Re: Channels integration plan, first draft

ven channel in both the redis and database backends, which is a good rough metric, though in systems like this I do prefer to know queue time (i.e. how long are items on the queue before consumption) - that's a lot harder though. Might be a good idea to carve out a channel_length() API on backe

Re: MOSS Award to Django

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 :-)

Re: MOSS Award to Django

documentation and so forth. Any radical change that might end up happening would have to happen in slow steps over many releases, and only with the buy-in of the community - I don't even fully have that yet, and I don't expect to get it until Channels can show that it works, is backwards-compa

Re: Request for Input: WSGI 2.0

handling, so I don't think I'd want to throw it away and adopt WSGI 2 directly if it came along, but Django would definitely keep a direct-WSGI mode for that as it always has. Andrew On Mon, Jan 4, 2016 at 9:14 AM, Marc Tamlyn wrote: > Hi Cory, > > [Disclaimer - I don't s

Re: slow migrations

diculously slow sometimes. Andrew On Thu, Jan 7, 2016 at 2:03 PM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > As far as I understand, the CPU cost comes from generating a full set of > model classes for each step of the migration history. That’s consistent >

Re: Django Integration

x27;s only because I'm able to do the work now and wait to get paid for it later; I don't expect the same of other contributors. Andrew On Fri, Mar 4, 2016 at 3:58 PM, Chad Paulson wrote: > I was happy to read that part of the Mozilla Open Source Support program > funding that w

Re: Django Integration

addition and tweaking some imports. Andrew On Sat, Mar 5, 2016 at 4:44 PM, Tim Graham wrote: > Hi Andrew, > > What's your thinking about whether or not any of this will make it into > 1.10? The alpha is scheduled for May 16. > > On Saturday, March 5, 2016 at 2:40:05 PM UTC-5, An

Re: Feedback on Django Channels

On Fri, Mar 18, 2016 at 4:40 PM, Vincent wrote: > Hey Andrew, > > Thanks for looking through all that, and for the reply. > > I like the simplicity of your updated examples. I started to make a > counter-example to suggest that `include` be inside of a `route` ( > ht

Re: Feedback on Django Channels

tification.routing.routing"), ] It also means that the simple example case stays quite readable: routing = [ route("websocket.connect", ws_connect), route("websocket.receive", ws_receive), route("websocket.disconnect", ws_disconnect), ] We can also

Re: Feedback on Django Channels

plicated, you only get the WebSocket path passed in the > connection message, so you have to also use a channel session to keep track. > > This feels like a distinct step back from the URL routing we already have > in Django, and it was surprising to me to have to do this by hand. It >

Re: Feedback on Django Channels

Yes, my intent is that "path" is just a stand-in for "any string key in a message", thus you could route other ways (for example, `method` in http.request, though that's probably not super useful inside Django). Andrew On Sat, Mar 19, 2016 at 1:40 PM, Vincent wrote:

Re: Feedback on Django Channels

way. I think include should never need a channel, and route should always need one - which means the router always knows that every entry has exactly one channel defined that can be matched against. Andrew On Fri, Mar 18, 2016 at 5:43 PM, Vincent wrote: > Andrew, > > Ah, excellent. I ju

Re: Feedback on Django Channels

You're right. Assume I put the keyword arguments at the end, sorry - the two positional arguments are the channel name and the consumer. On Fri, Mar 18, 2016 at 12:21 PM, Ryan Hiebert wrote: > > On Mar 18, 2016, at 9:58 AM, Andrew Godwin wrote: > > routing = [ >

Re: Feedback on Django Channels

or FileResponses to the main handling code rather than just Staticfiles, so it should be fine. 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 receiv

Re: Feedback on Django Channels

redis nodes into memory-only mode so that the data is never persisted, at least (channels doesn't need persistance beyond about a minute), but I can imagine a channel layer where you pass a symmetric encryption key in its configuration or similar. Andrew -- You received this message because

Re: Feedback on Django Channels

let people provide a regex to match against e.g. http.request and websocket.connect's `path` key. It's probably something we could pay for someone to work on for the "main" (Redis-backed) layer implementation? I could add it in too, but it's not as high priority as some other

Re: Feedback on Django Channels

. Andrew On Tue, Mar 22, 2016 at 2:24 PM, Jacob Kaplan-Moss wrote: > I do think encrypting the Redis channel layer is something we should > offer: Redis out of the box doesn't do transport-layer encryption, which is > going to make Channels a hard sell to anyone with any for of > regu

Re: Feedback on Django Channels

irements when I was dealing with HIPAA (and some other compliance > regulations) a few months ago. > > Alright, good to know. I'll put a task down in my notes for message encryption and we can add it to the list of things people can work on and get paid for when we put that up.

DjangoCon US 2016

ee the link above). Is cost a concern? Not a problem! Apply for financial aid (deadline April 25th). <https://2016.djangocon.us/financialaid> You can follow all the latest on Twitter <https://twitter.com/djangocon>. Hope to see you in Philly! Andrew -- You received this messa

Re: Feedback on Django Channels

On Fri, Apr 1, 2016 at 11:32 PM, Shai Berger wrote: > Hi, > > Finally found the time to go through this discussion. > > The first note that comes to mind is: > > Although it has already been pointed out more than once that positional > arguments cannot follow keyword arg

Re: Feedback on Django Channels

to change all the docs and examples to work this way - specifying "consumer=" as a kwarg will already work. I'm slightly concerned about forcing keyword-only, though. Andrew -- You received this message because you are subscribed to the Google Groups "Django develope

Re: Vendoring Select2

In previous projects (before moving to rolling my own UI components), I ended up favouring Selectize (http://selectize.github.io/selectize.js/) after getting fed up with Chosen and Select2 - but this was a few years ago and I can't remember my reasons. But if it hasn't been considered, it might be

Re: Django Integration

ms of things like making the enforce_ordering decorator a bit more efficient, but I see these as being entirely valid things to do after the feature freeze) Andrew On Tue, May 3, 2016 at 5:57 PM, Tim Graham wrote: > Hi Andrew, > > How are things going with the patch [0]? Do you think you

Re: Django Integration

aybe because we're declaring them as core dependencies (I patched in install_requires into setup.py for them) we should be very strict? If this patch is going to be denied based on Daphne not having sufficient test coverage then I suspect we'll miss the deadline and have to foist this

Re: Django Integration

ange I'm going to make, Django will depend on these in install_requires but not actually use them until you try and use a channels feature; they're in install_requires out of user convenience (having a traceback the first time you use the new built-in Django feature seems bad). Consideri

Re: Django Integration

he other option, but it seems to run contrary to Django's traditional batteries-included philosophy (and would result in some ugly, ugly import code in the channels modules). I'm curious to hear more opinions though, if there's support for it I'm happy to change it. Andrew -- You

Re: Django Integration

iate that I've spent a hell of a lot of time getting the project to this point, and anything missing is not because of malice or incompetence but because I don't believe that 100% test coverage is a necessary prerequisite for getting something merged in, merely sufficient test coverage, a

Re: Django Integration

ething Python recently started doing for similar not-experimental but not-100%-final APIs) (Also, I would posit that the fact it barely changes anything in Django is part of the good design, but I am biased there!) Andrew -- You received this message because you are subscribed to the Google Gr

Call for Channels work

pond here or email me directly! 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+unsub

Re: Django Integration

help fix release blocking bugs > if Andrew isn't available? Are we playing for any or all bug fixes? If > these requests have to go through the MOSS committee, will that delay > getting things fixed? > > Migrations delayed the 1.7 release for months, and I'd like some vote of &g

Re: Django Integration

> there? > > Jacob mentioned he'd been running it on something, but I don't know what exactly, and I only hear mention, not details, of people trying it in production. Personally, it's only running on my own sites, which are anything but high traffic. I had discussed with s

Re: My Take on Django Channels

a much more difficult prospect and one we can only really tackle when we drop Python 2 support. I do believe, however, that the ASGI model maps well to writing an event-based single-process program with async support; in fact, I should probably go write an asyncio in-memory backend version to make

Re: My Take on Django Channels

separate stack to manage it. Do you have an alternate proposal for how Django should integrate websocket support, or do you believe it's not the job of Django to handle at all and should be left entirely to other software? I'm curious, because I obviously believe Django needs to support W

Re: My Take on Django Channels

On Thu, May 5, 2016 at 2:39 PM, Carl Meyer wrote: > Hi Andrew, > > On 05/05/2016 02:19 PM, Andrew Godwin wrote: > > I will put my hand up and say that this sidestepped the DEP process, and > > that's entirely my fault. It was not my intention; I've been working

Re: My Take on Django Channels

at this point for not realising sooner and trying to find ways to not do it - people only pay real attention to a patch as you're close to merging and emotionally invested in it, and it's a little exasperating. Jacob has graciously stepped in to help write one, and I am going to have a

Re: My Take on Django Channels

asty bugs, and I'm still convinced the core design is sound - we'll take it to a DEP and run it through the actual process before merge to make sure that Django is at least on board with that opinion, I owe you that much at least. Andrew -- You received this message because you are su

Re: Django Integration

On Thu, May 5, 2016 at 9:28 PM, Anssi Kääriäinen wrote: > On Thursday, May 5, 2016, Andrew Godwin wrote: >> >> Do you have a link to the presentation about them removing it? >> > > https://youtu.be/839rskyJaro around 34 minutes and onwards, another > version is h

Re: Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

on 2. > I agree, and I would love to see more native async code as we go forward that interoperates with both async webservers and async channel worker classes. There is not yet a standard for "async WSGI", and I suspect ASGI can at least partially fulfill this role with the message f

Re: Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

er`` is just whatever > bytes > come in off the wire. This also gets exposed in other features, like > backpressure where ASGI didn't currently have a concept of allowing the > queue > to apply back pressure to the web connection but now Andrew has started to > come > aroun

Re: Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

I haven't looked at it carefully yet) you're basically > describing the approach taken by hendrix [1]. I'd be curious, Andrew, if > you considered a thread-based approach as an option and rejected it? It > does seem like, purely on the accessibility front, it is perhaps even

Re: Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

On Fri, May 6, 2016 at 2:11 PM, Carl Meyer wrote: > > On 05/06/2016 02:31 PM, Andrew Godwin wrote: > > > > On Fri, May 6, 2016 at 1:19 PM, Carl Meyer > <mailto:c...@oddbird.net>> wrote: > > > > On 05/06/2016 01:56 PM, Donald Stufft wrote: >

Re: Django Integration

ing ownership of the git repos and mentioning it in official documentation; this to me seems like a less severe thing than merging it into core, and also something that there is not a deadline preventing so we can discuss it further if needs be. Andrew -- You received this message because you are

Withdrawing Channels from 1.10

achieve with Channels can be done as an external package for now, and hopefully it will prove the correct decision to take. Andrew -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubsc

Re: Withdrawing Channels from 1.10

On Tue, May 10, 2016 at 10:25 AM, Carl Meyer wrote: > On 05/10/2016 10:39 AM, Andrew Godwin wrote: > > - Being almost purely an addition to Django, even though it technically > > inserts a new layer, makes it more well-suited to live externally than > > many other feature

Process DEP for "official" non-core projects

o split out Django into more packages, as well, it could provide a useful base for that to structure around (though we'd want to beef up security/backwards-compat timelines). It's also probably sensible that whatever we come up with covers localflavor, as well, since that's sort of in t

Re: DEPs (was: Making Django more PaaS-friendly)

l the discussion around it seems invaluable for larger features, and would have been Nice To Have given recent events. Andrew -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscr

Re: Process DEP for "official" non-core projects

t; hearing from people who've already been actively involved in localflavor > maintenance. > Me too - I'm not entirely clear what the state of maintenance and releasing is like for it at the moment. Andrew -- You received this message because you are subscribed to the Google Groups &quo

Re: Process DEP for "official" non-core projects

t is probably the better option rather than letting it linger. I would be inclined to merely mark it as deprecated and not drop it from e.g. the GitHub org, though, as where would we move it *to*? Andrew -- You received this message because you are subscribed to the Google Groups "Dja

Re: Process DEP for "official" non-core projects

Good point. I'll get a proper DEP draft written up for next week and then we can comment on it directly with more substance - it sounds like the idea of having one is popular, though, which is what I mainly wanted to check! Andrew On Thu, May 12, 2016 at 12:52 PM, Marc Tamlyn wrote: &g

Re: AJAX support in auth views

would help root a discussion! Andrew On Sat, May 14, 2016 at 11:04 PM, Luke Hodkinson wrote: > Hi all, > > I've been using a patched version of Django for a while now that includes > AJAX support for the login/logout views in contrib/auth. I've searched the > django-devel

Official Projects DEP

ng the existing localflavor under this too). Pull request is up here: https://github.com/django/deps/pull/23 - comments welcome. Andrew -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe

Re: Official Projects DEP

points or opinions on the plan, now is the time! Andrew On Wed, Jun 8, 2016 at 1:34 PM, Andrew Godwin wrote: > Hi everyone, > > I've started on an "official projects" process DEP as I discussed here a > while back, to formalise the process of adopting non-core packages

Re: Official Projects DEP

g set; do you think we should? I think asking the project to come with a plan for that stuff is helpful, and if it would need Fellow involvement, the proposal should include them as part of the maintenance team maybe? Andrew > > > On Friday, June 10, 2016 at 3:01:23 AM UTC-4, Andrew Go

Re: Call for Channels work

self. > > I'd like us to get going on this earlier than November, but I can't offer much extra time towards it; if you can work on drafting a call that would be great. Why would this write you out of pitching for it, though? Andrew -- You received this message because you are subscrib

Re: Official Projects DEP

I've revised the documentation section for clarity about external hosting, and given the lack of further discussion or dissention, I'm now taking the DEP to the technical board for a decision. Andrew On Sun, Jun 12, 2016 at 4:35 AM, Andrew Godwin wrote: > > On 12 Jun 2016

Re: Official Projects DEP

I am happy to report that the Official Projects DEP, number 0007, was approved by the Technical Board and is now adopted as final! Andrwe On 4 Jul 2016 11:39 am, "Andrew Godwin" wrote: > I've revised the documentation section for clarity about external hosting, > and give

Proposing Channels as an Official Project

t move for Channels; adopting it as an official project and mentioning it in the official docs gets us a long way to filling the hole I first saw in Django without going all the way into core straight away. Andrew -- You received this message because you are subscribed to the Google Groups "Dj

Re: Proposing Channels as an Official Project

time to dedicate, security coverage, burnout and the "bus factor" both mean a single-person project is not the best approach. Andrew On Fri, Jul 15, 2016 at 6:26 PM, Andrew Godwin wrote: > Hi everyone, > > Now the Official Projects DEP has landed, I would like to su

Re: Django Channels and WebSocket Routing and URL Parameters

g = [ # You can use a string import path as the first argument as well. include(chat_routing, path=r"^/chat"), ] You can read more in the docs here: http://channels.readthedocs.io/en/latest/getting-started.html#routing Andrew On Thu, Aug 18, 2016 at 7:45 AM, Robert Rosk

Channels is now an official Django project!

need to be done (there'll be deprecation warning code in there so things don't mysteriously break on upgrade). Andrew -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from

Re: Channels is now an official Django project!

e any questions or clarifications, please say and I'm happy to discuss. --- Andrew On Fri, Sep 9, 2016 at 4:08 PM, Tim Graham wrote: > Could you please share the information that you submitted to the technical > board as per the DEP: "The Shepherd will submit the project, the list of &

Re: Channels is now an official Django project!

hannels and its merits and downsides constantly. I tried to build on the problems people had with my merge approach and do this slowly, define a process, and get people involved - I'm not sure what else I could have done? Waited another two months? Andrew On Fri, Sep 9, 2016 at 4:51 PM, Tim Grah

Re: Channels is now an official Django project!

helps improve the process > for next time. I'm interested to see how this experiment turns out. > Thanks, and I am as well - this is new ground for all of us, I think, and while I'd like it to end up working fantastically, we can also learn along the way and work out how to better

Re: Adding aggregates to ModelAdmin.list_display

We have an implementation of both annotations in *list_display* and adding an aggregates for the entire list (which we call *list_summary* and what you are calling here *list_aggregates*) and there are a bunch of subtleties in the interaction due to Admin's built in support for pagination and f

Re: Django Channels Load Testing Results

You might want to run a small site with WebSockets - there are a number of reasons to use ASGI mode, and it's important we make it scale down as well as up. Andrew On Mon, Sep 26, 2016 at 1:30 PM, Chris Foresman wrote: > Why would you be running a small website in ASGI mode with

LiveServerTestCase change in Django 1.11 means can't run functional tests against external server?

Very much appreciate the Django framework. I noticed in the docs for Django 1.11 that the *DJANGO_LIVE_TEST_SERVER_ADDRESS* environmental variable is slated to be removed, along with the accompanying

<    1   2   3   4   5   6   7   >