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

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

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

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 to work on it at the DjangoCon sprints,

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

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

rg 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 April 2013 13:33, Tom Christie <christ...@gmail.com &g

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

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: > > > On Apr 22, 2013 7:15 AM, "Tom Christie"

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

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

Re: URL dispatcher fallthrough?

atabase > 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: >> >> * A `UrlNotMatched` exception sounds like the potential source of >

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

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

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 >

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

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

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

Re: Moving forward with Serialization.

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)serialisation. They already serialise to HTML: why should > > they not be able to serialise to other stream types? >

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

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

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

Re: Customizable Serialization check-in

st, 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: > > > > deserialized_value function with empty content > > Are you asking about 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

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

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

Re: More on Customizable Serialization

mchristie.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 > > prompted me to d

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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]

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

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"

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

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

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

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

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

<    1   2