Re: A Django Async Roadmap

I wonder if a sensible first tack onto this might be: Supporting an ASGI/asyncio request-response cycle in 2.2 might be a perfectly achievable goal with or without funding. Users wouldn't be able to use the ORM, or much of the default middleware, but for some gateway-type services I can still

Re: A Django Async Roadmap

> Do we think async is worth going after? I think this is hugely important. Django's advantage in the field currently is in it's developer productivity and maintainability. As frameworks based on Node or on languages with co-operative concurrency built-in continue to mature it's going to face

Re: DEP pre-proposal for a simpler URLs syntax.

I've started to address some of the missing documentation aspects for this, here... https://github.com/django/django/pull/9072 I'll put in a bit more time tomorrow & friday and aim to make sure that it's reviewable by that point. It's a bit of a tough one to have to review right up against the

Re: Rethinking ASGI & Channels

Hi Andrew, Thanks for writing that up so comprehensively! Definitely in favor of moving to a server:consumer interface - as you say that doesn't preclude over-the-network from being one of the possible deployment styles. I like your proposed approach to async vs sync variants of the

Re: On ASGI...

Raising this across in aio-libs for a bit of exploratory discussion... https://groups.google.com/forum/#!topic/aio-libs/7rJ8Pb1y7aA > I'm not sure where I sit on it - on one hand <...> on the other hand <...> Same really, yes. :) -- You received this message because you are subscribed to the

Re: On ASGI...

> My ideal solution is one that allows both approaches, and I'd like to investigate that further. I think you're getting closer to the sort of thing I'm imagining with the uvcorn designs, but I feel like there's still something a little extra that could be done so it's possible to offload over

Re: On ASGI...

> I wonder if there is a way of doing something like this well, so that it's easy to write but also lets you scale later. It's not obvious that sticky websockets are *necessarily* problematic for typically use cases. Couple of things you'd want: * Have clients be responsible for graceful

Re: On ASGI...

> I note that your examples do not include "receiving messages from a WebSocket and sending replies" - I would love to see how you propose to tackle this given your current API, and I think it's the missing piece of what I understand. I've just added an `echo` WebSocket example. I've also now

Re: On ASGI...

> def handler(channel_layer, channel_name, message): Oh great! That's not a million miles away from what I'm working towards on my side. Are you planning to eventually introduce something like that as part of the ASGI spec? > So is the channels object just a place to stuff different function

Re: On ASGI...

Figure I may as well show the sort of thing I'm thinking wrt. a more constrained consumer callable interface... * A callable, taking two arguments, 'message' & 'channels' * Message being JSON-serializable python primitives. * Channels being a dictionary of str:channel * Channel instances expose

Re: On ASGI...

> 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" Gotcha, yes. Although that wouldn't be the case with asyncio frameworks, since the channel reader would be a coroutine. Which makes for interesting design

Re: On ASGI...

Making some more progress - https://github.com/tomchristie/uvicorn I'll look into adding streaming HTTP request bodies next, and then into adding a websocket protocol. I see that the consumer interface is part of the channels API reference, rather than part of the ASGI spec. Is the plan to

Re: On ASGI...

> I suspect there is potential for a very fast async-only layer that can trigger the await that's hanging in a receive_async() directly from a send() to a related channel, rather than sticking it onto a memory location and waiting Yup. Something that the gunicorn worker doesn't currently

On ASGI...

I've been doing some initial work on a Gunicorn worker process that interfaces with an ASGI consumer callable, rather than a WSGI callable. https://github.com/tomchristie/asgiworker In the standard channels setup, the application is run behind a message bus... Protocol Server ->

Re: DEP pre-proposal for a simpler URLs syntax.

> Some positive yes/no on whether or not this is an actual desirable feature for Django from the core team. We've positive feedback from at least Jacob, Ola, Aymeric, and myself, so I'd broadly assume we're good there, so long as there's not any specific blockers that emerge. I'd expect there

Re: DEP pre-proposal for a simpler URLs syntax.

> I'm trusting that they ask for help if there's something the community can do. Personally I've got other priorities at the moment, so it's not something I'm working on or looking at. I do think it's a really nice bit of low hanging fruit tho, just needs someone to do a bit of work on

Re: status of 1.11 release blockers

> this feature https://github.com/django/django/pull/7482 will also be a very good inclusion. Can't see simplified URL routing being complete before the feature freeze. What might be feasible is getting the URL kwarg type conversion basics in, so that it can fully exist as a third party

Re: Consider reverting or adding guidelines on how to use class based views for security sensitive features

Just to be absolutely clear, in case it's needed... > is to hold off the deprecation of the function-based views. Markus is specifically referring to the FBV implementations of the contrib.auth views here. (Not to FBVs generally, which we've no intention of deprecating whatsoever) - Tom >

Re: DEP pre-proposal for a simpler URLs syntax.

> What is the current status of this pre-proposal? I think it's ready for some initial work to validate the approach. I've got some time available for this in the near future, given that I'm currently on open source work full time . > Is

Re: DEP pre-proposal for a simpler URLs syntax.

> an option could be to target this for inclusion in Django 2.0 but make the necessary fixes in Django 1.11 to allow this to exist as a third-party app in the meantime. Interesting idea, yup. I'm open minded at this stage. Other hurdles to get past first, so let's see how we go before calling a

Re: DEP pre-proposal for a simpler URLs syntax.

> wondered if it'd be possible here to get rid of the converter in the syntax at all, or have a default one if none is provided. Actually yes, I'd not noted in the proposal but you can also simply use eg. path('users//') By default that'll give you the 'string' convertor. (Accepts any text

Re: DEP pre-proposal for a simpler URLs syntax.

I've iterated on the pre-proposal, with what I think represents the best options to date. https://gist.github.com/tomchristie/cb388f0f6a0dec931c611775f32c5f98 The updates are: * Using a different name for the syntax: `path()`. * Dropping the leading slashes. * Simplifying the "unintended

Re: DEP pre-proposal for a simpler URLs syntax.

Yup, good points there. I wasn't really considering `include` at that point. Definitely some awkwardnesses that need thinking about there. urlpatterns = [ path('', homepage), path('users/', users_list) ] Looks very odd to me, since those are not actually valid URL paths. ('/' and

Re: DEP pre-proposal for a simpler URLs syntax.

> About the url convention We're not changing anything about the URL conventions, we're changing the oath syntax. Django tends to use a trailing slash style by convention. This proposal wouldn't change that in any way. > The only technical reason I see for enforcing the starting slash The

Re: DEP pre-proposal for a simpler URLs syntax.

Some possibilities: 1. Use a different name for the new function. path('/users//') Actually `path` is pretty valid as a name there - that's *exactly* what it represents - the path portion of the URL. Alternately `route`? 2. Keep `url` for both styles, but with a really simple

Re: DEP pre-proposal for a simpler URLs syntax.

Okay then, I've made some updates: * Updated the import design, in line with Jacob's suggestion. * Brief note on URL conventions, and the leading '/'. * Section on guarding against errors between `from django.conf.urls import url` and `from django.urls import url`. * Brief note on the internal

Re: DEP pre-proposal for a simpler URLs syntax.

> My suggestion is that we move towards `url()` giving "new style" patterns Agreed. I couldn't see a nice way around to do that, but moving the import to `from django.urls import url` sidesteps the issue nicely. Sounds good to me. -- You received this message because you are subscribed to the

Re: DEP pre-proposal for a simpler URLs syntax.

> There's text that elaborates on how to detect which one of the two options is implied. I'd recommend making that a section in and of itself. Probably a good plan, yup. I was somewhat writing that section as I thought, so it comes out a bit jumbled. I'm more confident in retrospect that regex

DEP pre-proposal for a simpler URLs syntax.

Hi folks, I wanted to push forward the consideration of introducing a simpler URLs syntax, plus support for URL parameter type conversion. A pre-proposal is available here: https://gist.github.com/tomchristie/cb388f0f6a0dec931c611775f32c5f98 At this point I'm seeking feedback, before

Re: Challenge teaching Django to beginners: urls.py

Wanted to add my support for this. Personally I'd be totally in favour of considering something along these lines for core, once there's a fully proven design. The capture syntax is: * Far simpler. * Meets pretty much every single real-world case I ever see. * Gives us type coercion. * Also

Re: should blank POST data fallback to use model field defaults?

It's not perfect but given that it's an inherent limitation of HTML checkboxes, I don't think that documenting that limitation is that big a deal. forms.BooleanField(required=False) feels like an odd combination to me in any case. One way we could potentially help users would be to error in

Re: Extend support for long surnames in Django Auth

I'd always defer towards humanized limits, rather than technical limits, so I'd suggest 100 chars seems like a decent cap. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group

Re: Enforcing a max size for form field values read into memory (review/determination of next steps needed)

> a consensus on how to proceed here might be useful for documenting best practices as other apps run into similar troubles. I guess I'd suggest... Most realistic in immediate future: Accept it as a current limitation (possibly handle TooManyFieldsSent) Someday later, perhaps: Allow a "select

Re: Call for Channels work

> if you can work on drafting a call that would be great Sure, sounds like a sensible place to start. I won't get onto anything immediately, but I'll start to have a think about spec'ing it out at some point. (Other offers/progress on this from anyone also welcome in the meantime tho') > Why

Re: Call for Channels work

> we don't have a mechanism to delegate the "what should we build" part of the question for work other than channels. I guess there's two aspects to that. 1. Do Mozilla allow some flex in meeting the proposal / do we have an differing priorities now / do we want to discuss what those should

Re: Call for Channels work

Do the Django MOSS committee have any plans for the request parsing/response rendering portion of the Django MOSS proposal? I'm assuming that any of the following could be reasonable choices: * Expecting to issue a call for work in due course, but treating channels as the priority for now. *

Re: Some thoughts on upgrade pain & deprecations.

Picking this up in trac: https://code.djangoproject.com/ticket/26713 And github: https://github.com/django/django/pull/6732 On Thursday, 2 June 2016 16:00:26 UTC+1, Tom Christie wrote: > > > I'm against adding custom behavior in Django > > That's entirely reasonable, yes. > >

Re: Some thoughts on upgrade pain & deprecations.

> I'm against adding custom behavior in Django That's entirely reasonable, yes. In which case, what do folks think of the following suggestions: * Linking prominently to the 'upgrading django ' section from at the begining of every

Re: Some thoughts on upgrade pain & deprecations.

The low tech solution to this, may just be to have the release notes recommend running your test suite using `PYTHONWARNINGS=once`, and making sure not to swallow any output, eg. with py.test that'd be... PYTHONWARNINGS=once py.test tests -s I'm fairly sure that making that point explicitly

Some thoughts on upgrade pain & deprecations.

I've just finished upgrading Django REST framework to support 1.10, and it's given me some food for thought on things that can make Django upgrades painful. Firstly, here's a couple of things that I needed to track down in order to upgrade that weren't obvious at first... * A bunch of test

Re: Rewriting admin internals

> I also think that working on existing outstanding ticket first and trying to solve issues incrementally would be a good approach? Absolutely, yes. There's plenty of good work that can be done there. -- You received this message because you are subscribed to the Google Groups "Django

Re: Rewriting admin internals

> But for the money I don't have any initial source to manage It. Jacob is using the figure more to give an idea of the amount of effort he believes it would involve, rather than suggesting that we should make a serious attempt to raise that amount of money. > can you guide/ show me any

Re: Testing pre-release Django

> I'd be curious to hear from any third-party package maintainers how they feel about it. I've not found testing against master to be particularly helpful, as it's not apparent if an issue is substantial or not, without putting in work. The alpha releases *are* tremendously helpful for having

Re: Withdrawing Channels from 1.10

Seems sensible. In particular having the documentation available as part of the regular Django docs would mean there's very little difference to the end user, but without us having to get everything merged into the core codebase. Is the docs element something we can reach a consensus on, or are

Re: Django Integration

> The notion that I would now have to use a data store to run my app at all didn't feel right Fortunately, you don't need to. From the docs in the pull request... "It's an optional part of Django; you don't need to interact with it if you're just writing a normal website, but if you want the

Re: Django Integration

My preference would be to shift the alpha deadline *without* yet making a firm decision on if channels hits 1.10 or not. That would take a little pressure off, and not force anyone into making a decision prematurely. Moving the window back (say 3 weeks?) and allowing a little more time for the

Re: Enforcing a max size for form field values read into memory (review/determination of next steps needed)

> If you are using django-rest-framework, how would the fields counter work?. It would be a shame if only multi part and urlencoded uploads would have the benefit of these checks, while still allowing json, xml and others still be "exploited". Note I didn't really read the code changes

Re: JsonpResponse subclass of HttpResponse helps easily create JSONP-encoded responses.

JSONP is essentially a browser hack. There have been security issues raised around it, and we I don't believe we should encourage its usage by including it in Django core. (If anything we *might?* want to consider CORS for built-in support at some point.) I'd agree with Florian here - I'd rather

Re: Extending JSONField serialization

Customizing the encoder (or even using DjangoJSONEncoder by default) isn't so bad. I'm less convinced about the usefulness of customizing the decoder - once you've encoded the data into JSON any additional type information is lost, so casting back to python primitives is always going to need

Extending JSONField serialization

> Should JSONField accept additional kwargs to customize the encoder and the > decoder? Quick take here: That sounds like a bit too much "cleverness" to me. The most obvious issue it'd cause is putting values of one type into the field, but getting objects of a different type back. (eg

Re: is_authenticated as property

> My own opinion is that if you don't have tests to catch the mistake in the first place, you're doing it wrong. Not sure I'd necessarily agree there - easy to miss the anonymous case. No obvious best thing to do tho'. On the one hand it's too easy to get wrong, on the other the current visual

Re: Fellow Report - November 28, 2015

Hi Edwar, Commenting on the ticket itself would be more appropriate. Also note that the ticket's only been open 5 days - I'd suggest a little more patience might be needed :) T. -- You received this message because you are subscribed to the Google Groups "Django developers

Re: Allow impossible model validation (mainly admin and generic forms)

> Append form's non_field_errors with message like Given that the IntegrityError doesn't occur until the point of .save(), it's not obvious how that'd work in terms of the Forms API. You're absolutely correct that there's a class of constraints that can fail here, but it's not evident to me

Re: Why passing request, *args, **kwargs in dispatch method for generic views

Although those variables are available in both places I'd prefer to see them passed explicitly. That will tend to nudge users slightly more towards passing variable around explicitly and slightly away from storing state on the view instance (which can be a bit of a gnarly practice - harder to

Re: Making max_length argument optional

I'm with Tom here. Forcing `max_length` to always be set on CharField feels like the right decision. Having a default there seems unnecessary obscure, and more likely to lead to untested/unnoticed failure cases. It *could* be that we'd allow `max_length=None` to explicitly turn off the

Re: status of 1.9 release blockers

To back that up I'll make a formal commitment to helping review & ensure completion of the PR if it *does* get deferred to 1.10. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this

Re: status of 1.9 release blockers

Given that it addresses such a core component I'd probably rather see it deferred to 1.10. I'd hope that doesn't affect the motivation of the author (it's a fiddly bit of work to get right and its good to see it being addressed) but from my point of view it'd be better to see it really

Re: moving the class-based View base class out of django.views.generic?

Yup, I think that's a good proposal. -- 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

Re: Why leave explicit null=True when blank is True in IntegerField, DateField etc?

That kind of implicit behavior would just leave things more confused. Writing a few characters less code isn't a benefit if it comes at the expense of making the behavior less obvious. -- You received this message because you are subscribed to the Google Groups "Django developers

Re: request for API review of streaming responses additions

Potential there to treat these as separately reviewable pull requests. For example - needing streaming template generation doesn't *necessarily* imply needing streaming responses. The node-by-node rendering might mean imply that less memory is used during the template rendering, even if the

Re: Django Admin New Look

Could we give users guidance on overriding the admin's application specific static files with global static files if we do this? Not immediately clear to me what order static files are copied in, but presumably it's possible to ensure that the jquery static files included in the admin app

Re: #25227 Add utility method `get_updated_model()` to `ModelForm`

I'm not super convinced that form.instance is widely better than form.save(commit=False). That's even more true if we're not sufficiently convinced by it that we'd be deprecating the existing style. It would: * Promote making views making in-place changes on the instance -> doesn't tend to be

Re: Fellow Report - July 11, 2015

Consistently bloody amazing. Thanks for doing such a great job. -- 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

Re: Django Admin New Look

Amazing work so far. :) -- 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.

Re: Extending the URL Dispatcher (GSoC 2015 proposal)

> E.g., flask uses a simple `` to match an integer and capture it in the `id` parameter. Support to check for conflicts would be a lot simpler with those patterns. It would definitely be a best-effort feature. >From my point of view, this by itself would make for a really nicely-scoped GSoC

Re: JsonResponse and list values

I haven't dug out sources on this, but I think that vulnerability had been dealt with a long time ago, and isn't an issue on browsers with any real market share today. Would need to double check though - don't remember where I came across it previously. -- You received this message because

Re: Postgres specific fields and third party apps.

Thanks Marc, that's helpful input. > I would probably have the motivation to create a PR for DRF showing a possible travis/testing setup for what I have proposed. No, don't worry about that. We actually don't have any need to *hit* the database in those tests at all, we just need to make sure

Postgres specific fields and third party apps.

I'm not sure if there'll be an actionable outcome of this, but wanted to raise it for discussion. We've started supporting some of the PostgreSQL specific fields in Django REST framework, and I ran into a roadblock when adding a new testcase. Unsurprisingly we're not able to test them without

Re: resurrecting an old friend, whitespace in forms, #6362

> leaving a ticket open is a better signal for inviting discussion and patches. There's been over 22,000 issues raised in Django's history. It's understandable and desirable that maintainers close off tickets aggressively if they don't think they should be tackled. I wouldn't get too hung up

Re: resurrecting an old friend, whitespace in forms, #6362

> it will be backwards incompatible for every Django installation out there, but also because throwing away data that the user actually entered should be an opt-in, not opt-out behavior. If adequately called out I think there'd be a valid case that the current and future issues it'll be

Re: resurrecting an old friend, whitespace in forms, #6362

Trimming at `request.POST` or at the `Form` layer absolutely isn't sensible, and a `normalize` argument is probably just overcomplicating things, but I got the impression from that ticket that nobody would have any great issue with someone issuing a patch with a `trim_whitespace` flag on

Re: Settings: lists or tuples?

> So, I've been working on a patch ... Suggestions? Normalizing on lists as the default throughout is good. Warning about using tuples and putting their usage on a deprecation path seems a little unnecessary. I don't think that was discussed in this thread, but I've only scanned through, so I

Re: Settings: lists or tuples?

Hi Andreas, I'm completely in agreement with you that *in theory* using tuples would be a (very marginal) improvement. I also happen think that the idea that tuples are semantically different from simply being immutable lists is a nonsense - regardless of what a particular section of

Re: Last call: Meta API (GSoC 2014/PR 3114) is ready for commit

Wonderful - great work Daniel and thanks to everyone else for their hard work on review & guidance. Lovely stuff. Tom On Monday, 5 January 2015 05:12:41 UTC, Russell Keith-Magee wrote: > > Hi all, > > Following up on my pre-Christmas email - I believe that PR 3114 - the > formalisation of

Re: Delivering PR 3114 - The _meta refactor

Thanks Russ, appreciate your time. I've no great problem with keeping 'through' table API undocumented with 1.8, probably doesn't matter too much either way. Just flagging it up, but looks like 'no change' there, which is okay. -- You received this message because you are subscribed to the

Delivering PR 3114 - The _meta refactor

One thing I'm unclear on: Does the new API contain any (public API) way of determining if a relationship has an associated through table? Entirely possible that I'm being stupid and that's outside the scope of the API, but it's the one thing I see in Django REST framework's ModelSerializer

Re: Explicit relative imports

Contrary voice here, but I don't dig explicit relative imports, it's just adds an extra decision point for no real benefit. Personally I always recommend full absolute imports, ordered strictly alphabetically - there's then never any room for confusion or decision making around how the imports

Re: Django Mptt Admin as an inline form

Hi Neeraj, This group is for discussion of development of Django itself. You want the 'Django users' group, here... https://groups.google.com/forum/#!forum/django-users All the best, Tom -- You received this message because you are subscribed to the Google Groups "Django developers

Re: Django Content Negotiation implement

> I'll be trying to enhance my knowledge base about django request response and other related stuffs necessary if you please show me some light to get started or from where actually should I start. I'd generally think that a decent place to start would be to write up what some of the

Django Content Negotiation implement

There's no particular timeline for it. The two people most likely to progress it are Mark Lavin and myself. Mark is the author of the DEP and has been busy lately, focusing on releasing the "Lightweight Django" book that he's co-authored. He has mentioned that it's possible he'll get back to

Re: Django 1.7, KeyError: u'manager' error

Hi Taenyon, This list is for development on Django itself. I see you've also asked the question on the `django-users` mailing list, which is the right mailing list for your question. You'll want to follow up any further questions on the `django-users` thread rather than this one. All the best,

Re: Should reverse() return a Unicode string?

One point of clarity is that we ought to return the same type for each of `reverse`, `request.path`, `request.get_full_path`, `request.path_info`, and the values in the `request.GET` dictionary. Given that, the answer is clearly "it should be a string". It's also a little unclear to me what

Re: The greatest proposal yet: rename this damn group

Options?... * Django core * Django core development For comparison the Rails folks have "Ruby on Rails: Talk " and "Ruby on Rails: Core " - Tom On Friday, 5 September 2014

Re: Requiring GitHub login for actions on Trac

Absolutely +1. Clearly the most pragmatic choice. On Thursday, 7 August 2014 13:43:45 UTC+1, Josh Smeaton wrote: > > I don't think "vendor lock in" is a good enough reason to avoid it. If > GitHub were to go away, the move to a new code platform would be the > greater problem. Also, nothing

Re: [GSOC] Weekly update

1) get_fields should return a list instead of a tuple >>> Previously, get_fields would return a tuple. The main reason was related to memory and immutability. After discussing with Russell, we decided this endpoint should actually return a list as it is a more suited data structure. >> Can

Re: HTTP PUT request

Hi Mark, Sadly Malcolm is no longer with us . There is a thread herefor dealing with request parsing which - if it

Re: Support POST of application/json content type

Cheers all, Tom On Thursday, 12 September 2013 11:20:07 UTC+1, Tom Christie wrote: > > > why keep data and files separated > > Mostly because that's the way it already works, so... > > * request.data would essentially provide a strict superset of the > functionality tha

Re: #18659 -- Deprecating request.REQUEST

> but perhaps we should provide better names for `request.GET` and `request.POST` at the same time Sure, I'd absolutely agree in principle, and for what it's worth REST framework provides `.QUERY_PARAMS` and `.DATA` attributes on the request which are recommended instead of using `.GET` and

Re: #18659 -- Deprecating request.REQUEST

+1 on removing it. It's usage reinforces incorrect assumptions about the meaning and behaviour of `request.POST` and `request.GET`. > It's hardly ever a good design pattern to handle GET and POST identically I'd phrase is as "It's hardly ever a good design pattern to handle query parameters

Re: Working towards a simpler GCBV implementation?

> But django-vanilla-views are not as usable because you cannot reuse isolated pieces of functionality like you can with mixins. The reusable components that it gives you are `GenericView` and `GenericModelView`. Generally they're going to be the baseline that you'd want to work with anyways.

Re: Permission to use some Django material ?

Hi Stan, I would simply include some text in the license noting that some images are taken from the Django source and their usage is subject to it's license, with a link to the Django license. I'm sure that'd be plenty sufficient attribution. All the best, Tom On Thursday, 3 October 2013

Working towards a simpler GCBV implementation?

Hi folks, I recently released an alternative implementation of Django's existing class based views. The intention was to mirror the *exact* same set of functionality that we currently provide, but simplify the implementation and API. It's nothing cleverer or grander than a clean re-write,

Re: A policy on calling super()

won't be invoked. > > Alex > > > On Sun, Sep 29, 2013 at 10:00 AM, Tom Christie > <christ...@gmail.com > > wrote: > >> Calling super in base classes (ie anything that inherits from 'object') >> just seems unnecessary and obscure to me. It's not a patter

Re: A policy on calling super()

Calling super in base classes (ie anything that inherits from 'object') just seems unnecessary and obscure to me. It's not a pattern I use or have seen, and after playing around a bit I can't see any sensible case where it'd make a difference. `View` should always be the last (right-most)

Re: Support POST of application/json content type

> why keep data and files separated Mostly because that's the way it already works, so... * request.data would essentially provide a strict superset of the functionality that request.POST provides. In general you'd be able to replace `request.POST` with `request.data` anywhere and seemlessly

Re: Support POST of application/json content type

s >>> well, but request.DATA is the "new" way of doing it. Personally, I'd >>> lowercase it though, to remove confusion with the PHP $POST $GET $REQUEST >>> which we mimic on the request object. The generally have different use >>> cases anyway - on

Re: Support POST of application/json content type

A? > > Stefan > > On Wednesday, 4 September 2013 18:13:12 UTC+8, Tom Christie wrote: >> >> Hi Stefan, >> >> Sure, I'd be interested in seeing us improve how we deal with JSON >> requests and responses. >> >> My preference would be to introduce a

Re: Support POST of application/json content type

Hi Stefan, Sure, I'd be interested in seeing us improve how we deal with JSON requests and responses. My preference would be to introduce a request parsing and response rendering API that allows us to support not just JSON, but any media type that has a parser installed for it. (I've

Re: Confusion around generic views queryset cloning.

id in a follow-up this was intended for django-users, but >> personally I think it's on-topic for -developers, so I'm replying here.) >> >> On 07/11/2013 02:54 PM, Tom Christie wrote: >> > I've noted that the generic view implementations use the private >> >

Confusion around generic views queryset cloning.

I've noted that the generic view implementations use the private `_clone` method when returning the queryset attribute . Presumably the need for that is something to do with the potential for querysets to be

  1   2   >