Re: Django 1.4 roadmap

> > > Since we never had a list of features that we were committing to adding > for 1.4, I don't see any reason why we can't release an alpha as soon as > > the release blockers are dealt with. Agreed. There will > always be extra feature

HttpRequest.read(), HttpRequest.body, HttpRequest.raw_post_data

I see that as of 1.4 `HttpRequest.raw_post_data` is being marked as "pending deprecation", and `HttpRequest.body` has been introduced. This still leaves us with two ways to get at the request body - `.body` and `.read()` If we're going to make the change of marking `raw_post_data` as deprecated,

Re: HttpRequest.read(), HttpRequest.body, HttpRequest.raw_post_data

> a design decision was made long ago that HttpRequest objects should provide a file-like interface (thus also .readline(), .readlines(), and .xreadlines()) Wouldn't having .read() .readline(), .readlines(), and .xreadlines() all on `request.body` provide a slightly cleaner interface, whilst st

Making sure Web APIs built with Django don't have CSRF vulnerabilities.

Hi all, This is a follow on to an issue that's been discussed on django-security. It's been suggested that it should be raised in this forum instead, so... Most of the time when building Web APIs with Django the right thing to do is to wrap API views in @csrf_exempt. Generally Web APIs shou

Re: Making sure Web APIs built with Django don't have CSRF vulnerabilities.

I don't know how much of an issue it really is (or not), but I haven't really seen it being done right. Of all the examples I've found of devs implementing session authentication on top of piston and tastypie, (See here

Re: [GSOC 2012] Customizable serialization

Hi Piotr, I'd really like to see something along these lines making it into Django. I worked on this during the 2011 DjangoCon.eu sprints, which I posted about a while back

More on Customizable Serialization

Seeing another proposal for Customizable Serialization for the GSoC this year prompted me to dust off the bits of work I've done along similar lines. I'd really like to see this get properly addressed in core and I thought it was about time I helped to make it happen. I've made a fairly comprehen

Re: Customizable Serialization check-in

Hey Piotr, Thanks for the quick response. > However sharing ideas and discuss how the API should look and work it will be very desirable. That'd be great, yup. I've got a couple of comments and questions about bits of the API, but I'll wait until you've had a chance to post your proposal t

Re: More on Customizable Serialization

do so - t...@tomchristie.com - Tom On Saturday, 28 April 2012 04:05:17 UTC+1, Russell Keith-Magee wrote: > > Hi Tom, > > On Friday, 27 April 2012 at 12:44 PM, Tom Christie wrote: > > Seeing another proposal for Customizable Serialization for the GSoC this > year > > p

Re: Customizable Serialization check-in

Hey Piotr, Here's a few comments... You have 'fields' and 'exclude' option, but it feels like it's missing an 'include' option - How would you represent serializing all the fields on a model instance (without replicating them), and additionally including one other field? I see that you could

Customizable serialization now passing Django's test suite.

I've been working away on django-serializerslately, and I've now got a customizable serialization API that's backwards compatible with the existing serializers, and is passing Django's serializer tests. Exactly where I take this will depend on h

Re: Customizable Serialization check-in

> if I put list in input I want list in output, not generator I wouldn't worry about that. The input and output should be *comparable*, but it doesn't mean they should be *identical*. A couple of cases for example: *) You should be able to pass both lists and generator expressions to a given s

Re: Customizable Serialization check-in

th considering. As ever, if there's any of this you'd like to talk over off-list, feel free to drop me a mail - t...@tomchristie.com Regards, Tom On Wednesday, 20 June 2012 16:28:51 UTC+1, Piotr Grabowski wrote: > > W dniu 20.06.2012 13:50, Tom Christie pisze: > > >

Re: Customizable Serialization check-in

Thanks Piotr, It's been interesting and helpful watching your progress on this project. I wouldn't worry too much about not quite meeting all the goals you'd hoped for - it's a deceptively difficult task. In particular it's really difficult trying to maintain full backwards comparability with

Moving forward with Serialization.

Hi all, During Piotr's GSOC addressing customizable serialization I've been continued to work on my own implementation. I've now got what feels to me to be a natural conclusion of the design, which is the 'forms' branch of the 'django-serializers'

Re: Moving forward with Serialization.

> Do you know Colander? I do now. Thanks, that's very similar, and looks well done. > I personally think that Forms are already the place that should handle (de)serialisation. They already serialise to HTML: why should they not be able to serialise to other stream types? Conceptually I agree.

Re: Moving forward with Serialization.

xisting fixtures it'd be much appreciated. Regards, Tom On Saturday, 1 September 2012 12:39:32 UTC+1, Piotr Grabowski wrote: > > W dniu 31.08.2012 10:25, Tom Christie pisze: > > > I personally think that Forms are already the place that should > > handle (de)serial

Re: Improve tutorial to use class based views

Hi Jonas, The tutorial *does* cover class based generic views, but only towards the end: https://docs.djangoproject.com/en/dev/intro/tutorial04/#use-generic-views-less-code-is-better Starting with function based views, and then moving on to class based views by the end feels like the right app

Re: Django performance vs others

Please. As Jacob has already made clear, this thread isn't helping move anything forward. Can we please respect his request and move on. Django's community is absolutely interested in addressing practical steps towards improving performance and would no doubt welcome specific work towards prof

Google groups - possible issues with deleted posts.

Be aware that there may be issues with google groups at the moment... There are two messages in this thread that are marked as deleted, apparently not intentionally

Re: Proposal: Django URL Admin (django-urls)

Since this isn't really appropriate for django-dev, could we move any further discussion on this over to the django-users group, please? Many thanks! Tom On Sunday, 16 December 2012 18:53:43 UTC, Zach Borboa wrote: > > > 1) Being able to create redirects (which seems to already be on the > >

Re: Django 1.5 release plans

Hi Yann, There's [a thread on django-users][1] that should answer your request. >From Russ "It's difficult to give an exact date for the release of Django 1.5. We've put out 2 beta releases, which means there are no more features to be added; and the list of release blocking bugs is down to sin

Re: Ticket #17093 -- quarantine global state in django.template

Hi Christopher, > OK, let mi introduce the idea for Google Some Of Code of this year. The idea is stolen from Pyramid [3]. The main new concept is a renderer. A renderer may be current TemplateEngine as well as JSON serializer or mako renderer. I can't really comment on if it'd be appropriate

Re: first() and last(), earliest() and latest()

> +1 for the first syntax. The others are duplicating functionality > that is already present via more aptly named methods. The first > syntax is also more consistent with other ORMs. Seconded. Seems much more obvious, simple and explicit than the other options to me. On Thursday, 28 Februar

Re: URL dispatcher fallthrough?

For what it's worth I'd be against this proposal as it stands. * I haven't seen anything anything that convinces me that a single wrapping view isn't a reasonable alternative in the examples cited. * A `UrlNotMatched` exception sounds like the potential source of incredibly non-obvious bugs and

Re: URL dispatcher fallthrough?

something > along the lines of "Must not perform any operation requiring a database > write or any other operation with side effects before the check for > DoesNotResolve is made.". > > Eric > > On Thursday, March 28, 2013 3:28:10 AM UTC+11, Tom Christie wrote: >>

Re: Request method in urls.py

This proposal is actually *very* similar to the 'URL dispatcher fall-though' threadthat came up recently. I don't think it'd take much adjustment to take Jacob's django-multiurl project

Proposal for simplifying part of the GCBV API slightly.

I'd be interested to know what you folks think of this proposal. SingleObjectMixin currently exposes these three attributes and one method all dealing with queryset filter arguments... * pk_url_kwarg = 'pk' * slug_field = 'slug' * slug_url_kwarg = 'slug' * get_slug_field() I was wondering if it

Re: Proposal for simplifying part of the GCBV API slightly.

d `lookup_kwarg` with the later defaulting to the same as the former if unset, but I'm not wild about something like that given that the intention of this proposal is to try to slightly slim down an aspect of the API. On Monday, 22 April 2013 12:37:32 UTC+1, Calvin Spealman wrote: > >

Re: Proposal for simplifying part of the GCBV API slightly.

gt; a lot with CBVs since I first suggested the URL kwarg overrides, and I > think it's better to have less configurable fields and focus instead on > having good entry points into customising the classes through method > overrides. > > > Andy > > > > On 22

Re: test discovery

Hi Carl, Excellent, excellent stuff - many thanks to both yourself and Preston. Couple of questions: * Will it be possible to globally configure the default file/path pattern? Jannis's django-discover-runner includes support for a `TEST_DISCOVER_PATTERN` - is there anything similar, or just

Re: Proposal for simplifying part of the GCBV API slightly.

day, 2 May 2013 08:58:56 UTC+1, Tom Christie wrote: > > I've created ticket #20432 <https://code.djangoproject.com/ticket/20342> for > this proposal. > I don't know if it needs to go to 'design decision needed', but if it gets > approved I'll plan

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 pr

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 documentat

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 (Contr

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

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 '_me

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 Goo

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 _me

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 documen

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 c

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 CharFi

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 causing

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 o

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 al

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 t

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 yo

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 pro

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. To

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 django-dev

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

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 com

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 (Contribution

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 django-developers+unsubscr...@googleg

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 thorough

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 gro

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 validatio

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 fo

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 that

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 (Contributi

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

Proposal - Handling arbitrary request Content-Types.

Hey All, This is somewhat related to the ticket “Process HTTP PUT into request.FILES and request.PUT as done for POST” [1], although much broader in scope. In that ticket there’s a link to a related discussion [2] where Malcolm Tredinnick explains why a request.PUT that mirrors the current

HttpRequest.read() issues

It's not very obvious from the docs or source if HttpRequest.read() can always be safely treated as a limited input stream, or if the developer needs to respect HttpRequest.META['CONTENT_LENGTH']. As far as I can tell the intention is that it can always be treated as a limited stream, that seem

Re: HttpRequest.read() issues

I've created two tickets for this, with patches and tests... http://code.djangoproject.com/ticket/15762 - WSGIRequest should wrap the test client wsgi.input in LimitedStream http://code.djangoproject.com/ticket/15763 - MultiPartParser's LimitBytes is now redundant. It's possible that I've misun

Re: HttpRequest.read() issues

> So, OP should not be trying to read more than CONTENT_LENGTH. >From the underlying stream, sure. The question is if it's okay to do on the HttpRequest object. It's an issue because now that HttpRequest exposes a file-like interface to the stream some users are likely to do things like this:

Re: HttpRequest.read() issues

Actually it occurs to me that (1) shouldn't be a performance hit for accessing .POST either, because whilst you're now creating a LimitedStream, you're able to drop MultiPartParser's use of LimitBytes. -- You received this message because you are subscribed to the Google Groups "Django develop

Re: HttpRequest.read() issues

It occurs to me that (1) isn't a hit for accessing multipart POST requests, since we're wrapping the underlying stream in LimitedStream, but beng able to drop MultiPartParser's use of LimitBytes. -- You received this message because you are subscribed to the Google Groups "Django developers" g

Re: HttpRequest.read() issues

> Where is the proof that using a limited stream is a performance issue? These sorts of things are never going to be the bottleneck and sounds a bit like premature optimisation to think that wrapping it with a length limiting stream is going to be an issue. There isn't any, so good point. :) E

Re: HttpRequest.read() issues

Okay, since there's clearly an underlying issue here I've created a seperate ticket for this and marked the other two tickets as duplicates of it. So... #15785 - HttpRequest.read(NUM_BYTES) can read beyond the end of wsgi.input stream. (Violation of WSGI spec & under-defined behaviour) [1] Th

Re: HttpRequest.read() issues

> Last night I actually did test it :-). You're right the difference in > performance is less than a statistical deviation between different > uploads over network. Nice work. And point well made Graham! > Creating a single wrapper object is a negligible hit but the code bloat from making > it

Customizable serialization. (Finally?)

Hi all, Over the coding sprints at djangocon.eu I started working on a proposal for customizable serialization. [1] I've talked over the API and implementation with Russ, and I think we're broadly happy with it all, so I'd like to open it up to wider discussion. What I have right now looks

Re: WSGIRequest._stream.read() blocking

> Isn't this the same bug as and ? Yes. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.go

Re: Customizable serialization. (Finally?)

> A suggestion though, is to be able to declare serializers in a > similar fashion as models or forms. Actually that's a fair point, yup - the proposal could be made a little closer to the existing Forms and Models APIs. Something along these lines... class ModelPKField(SerializerField): def

Re: Customizable serialization. (Finally?)

Yup. The current implementation (see the github repo) allows properties and methods that only take a 'self' argument to be serialized by adding the name to 'fields' or 'include'. If you need anything more involved then you'd write a custom method on the Serializer class. (or a custom SerializerF

Re: Customizable serialization. (Finally?)

Cool, thanks, all good points. Slight haitus working on this right now whilst I try to get my head around the right way to try to bring it more into line with the Forms API, but hoping to pick it up again once I've marshaled my thoughts. Obviously I'll keep the list updated if I do make more he

Re-opening 5617?

Hi All, I recently bumped into the same issue as reported in #5617. (And duplicate #6377 .) IE: Django's default 500 view uses a Context, not a RequestContext, which means any 500 templates which uses MED

Re: Re-opening 5617?

Heya, Thanks for the feedback. I quite like the explicit 'STATIC_URL' only approach, although I think a lot of users would still run into a problem there, because 'request' isn't also added in explicitly to the Context... For context, my particular use case is a simple '500.html' template,

Re: Re-opening 5617?

Hey Jannis, > https://docs.djangoproject.com/en/dev/releases/1.4/#static-template-tag That's rather nice. > Adding the request is a non-starter, IMO; the "request" context > processor isn't even in the default list of TEMPLATE_CONTEXT_PROCESSORS, > so this would mean adding something to the 500

Re: Proposal: Support for HTTP PATCH method

I'm basically in agreement with Russ here. I'd consider the first three points as being non-controversial. With regards to ProcessFormView I think implementing a put() method, but not a patch() method falls squarely into the 'good-enough' category of behavior. In any case, although there are e

Re: Proposal: better support for generating rest apis in django core

Hi Karol, Thanks for bringing that up. I'll start by saying that I would love to see richer Web API support in core Django - in my opinion there are absolutely some fundamentals that could be addressed. However, I personally think that the benefit that we'd get probably isn't (yet?) worth

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 cached

Re: Confusion around generic views queryset cloning.

My apologies, this was intended to be posted to the Django users group. On Thursday, 11 July 2013 21:54:25 UTC+1, Tom Christie wrote: > > I've noted that the generic view implementations use the private `_clone` > method when returning the queryset > attribute<https://gith

Re: Confusion around generic views queryset cloning.

n 11 July 2013 22:26, Carl Meyer > wrote: > >> Hi Tom, >> >> (You said 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 C

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 commente

Re: Support POST of application/json content type

be a call to request.DATA? > > 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 pref

Re: Support POST of application/json content type

aditional web way of picking >>> up form encoded POST data, which would also be available in request.DATA as >>> 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 $

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 s

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

Re: A policy on calling super()

> FooMixin.__init__ won't be invoked. > > Alex > > > On Sun, Sep 29, 2013 at 10:00 AM, Tom Christie > > > wrote: > >> Calling super in base classes (ie anything that inherits from 'object') >> just seems unnecessary and obscure to me.

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, but

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

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. A

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 and

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 `.P

Re: Support POST of application/json content type

ow the ongoing work in that branch. 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

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 m

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: [GSOC] Weekly update

> This has been resolved by using the ImmutableList datastructure Looks fine. Behaviourally it's the same as a tuple, but with more explicit errors if you attempt to modify it, which seems reasonable. Given that `.get_fields()` and `.fields` return `ImmutableList`, presumably `.field_names`, `.

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 wil

  1   2   >