Re: Support POST of application/json content type

[S Berder]

On Tue, Sep 10, 2013 at 9:05 AM, Curtis Maloney
 wrote:
>
> On 9 September 2013 19:50, S Berder  wrote:
>>
>> Gents,
>> to sum it up, arguments made and details of how I see the
>> implementation of a response/request encode/decode framework:
>>
>> * need a pluggable interface so current content-types are supported
>> (`application/x-www-form-urlencoded`, `multipart/form-data`), new
>> types (`application/json`), custom and future types
>> (`application/vnd.foobar+json` anybody? See
>> http://developer.github.com/v3/media/#api-v3-media-type-and-the-future
>> for example, `application/msgpack`, `application/protobuf`,
>> `application/capnproto`, etc).
>> * decoder/encoder map (content-type, decoder) should be smart to
>> handle patterns like `text/*` or `application/*xml*` and match things
>> like `Accept: application/json, text/plain, * / *`
>> * choice of decoder would be made on the Content-Type header, maybe
>> supporting a raw by default so data is just passed in case of unknown
>> content type.
>> * decoder/encoder should be available through `request` and `response`
>> objects.
>> * decoded data structure (python object) would be stored in `request.data`
>> * first step is to support requests, next step is to handle responses
>> with the same pluggable functionality and coherent API.
>> * A sensible default for response Content-type would be `text/html;
>> charset=UTF-8`. It should be made available through a setting entry
>> anyway
>>
>
> You should also have access to the decision made by the data parser as to
> which parser was used, instead of having to infer it yourself from the
> content type header.

Indeed, that's the 4th point of my list, maybe it's not clear as it is
but this would be supported.

>>
>> Some questions though:
>>
>> * why keep data and files separated, I see no good reason for this
>> except mimicking PHP's structure. An uploaded file comes from a named
>> input, I hope to find it in request.data (why do a common structure
>> otherwise). I might be missing something but nothing indicates a real
>> need for this in django/http/request.py
>
>
> True, there's some added complexity [small as it is] in forms because File
> fields need to look elsewhere for their values.
>
>>
>> * isn't more or less any data sent to your backend representable as a
>> dict or object with dict access modes? I try to think about
>> occurrences where some data would not have a 'name'.
>>
>
> I frequently send JSON lists of data to my APIs...
Ok, was a bit short sighted on this one, still thinking in terms of
form bound data, it was a long day here in Shanghai. I suppose that
the kind of python object you receive is not so important as you
should do data validation anyway. Your earlier concern about checking
for different content-types doesn't apply to the solution I have in
mind as to whatever data representation you have at the beginning, you
should get a very similar object after decoding. What I mean is if you
send the *same* data through Yaml or JSON, the object in request.data
should be the same or extremely close. I say extremely close because
I'm thinking about xml that is always way more verbose than the others
and *might* add more data to the resulting object. (hint: I don't like
XML, don't need it in what I do and last used it ~8/9 years ago in a
disastrous explosion of SOAP and unix/microsoft interfaces)

Stefan
-- 
http://www.bonz.org/
 /(bb|[^b]{2})/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Support POST of application/json content type

[Curtis Maloney]

On 9 September 2013 19:50, S Berder  wrote:

> Gents,
> to sum it up, arguments made and details of how I see the
> implementation of a response/request encode/decode framework:
>
> * need a pluggable interface so current content-types are supported
> (`application/x-www-form-urlencoded`, `multipart/form-data`), new
> types (`application/json`), custom and future types
> (`application/vnd.foobar+json` anybody? See
> http://developer.github.com/v3/media/#api-v3-media-type-and-the-future
> for example, `application/msgpack`, `application/protobuf`,
> `application/capnproto`, etc).
> * decoder/encoder map (content-type, decoder) should be smart to
> handle patterns like `text/*` or `application/*xml*` and match things
> like `Accept: application/json, text/plain, * / *`
> * choice of decoder would be made on the Content-Type header, maybe
> supporting a raw by default so data is just passed in case of unknown
> content type.
> * decoder/encoder should be available through `request` and `response`
> objects.
> * decoded data structure (python object) would be stored in `request.data`
> * first step is to support requests, next step is to handle responses
> with the same pluggable functionality and coherent API.
> * A sensible default for response Content-type would be `text/html;
> charset=UTF-8`. It should be made available through a setting entry
> anyway
>
>
You should also have access to the decision made by the data parser as to
which parser was used, instead of having to infer it yourself from the
content type header.



> Some questions though:
>
> * why keep data and files separated, I see no good reason for this
> except mimicking PHP's structure. An uploaded file comes from a named
> input, I hope to find it in request.data (why do a common structure
> otherwise). I might be missing something but nothing indicates a real
> need for this in django/http/request.py
>

True, there's some added complexity [small as it is] in forms because File
fields need to look elsewhere for their values.


> * isn't more or less any data sent to your backend representable as a
> dict or object with dict access modes? I try to think about
> occurrences where some data would not have a 'name'.
>
>
I frequently send JSON lists of data to my APIs...

--
Curtis

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [discussion] communication guidelines in django

[Russell Keith-Magee]

On Mon, Sep 9, 2013 at 5:30 AM, Jorge Cardoso Leitao <
jorgecarlei...@gmail.com> wrote:

> Hi Django dev mailing list.
>
> The objective of this email is two-fold:
> A: I want to share a book I've read about written communication. Since
> communication in Django, and open source in general, is mainly written,
> some of you may found interesting to take a look.
> B: I want to suggest adapting some of the book's content to Django's
> documentation on a form of guidelines on how to communicate on the project
> (skip to end of the mail if part A is not relevant for you).
>
> -- Start of part A --
>
> The book's title is "How to Read a Book", is from 1940 and last revised in
> 1972, and basically teaches one how to read (a book).
> I find it more general to the extent that it teaches one on how to
> communicate.
> Here I highlight some of its points (the book can be found online here:
> http://crap.sceleris.net/HowtoReadABook.pdf):
>
> 0. The book is about reading for *understanding*, as opposed to for
> entertainment or for getting informed.
>
> -- Reading for understanding -
>
> 1. Understanding requires information and thought, but none of them is a
> sufficient condition. It is sufficient to explain something in own words to
> understand it.
>
> 2. from 1., any written text must have information, and every writer *and
> reader* must think during writing and reading respectively.
>
> 3. Every (good) text has a unity (and not a multiplicity), and every unity
> has a multiplicity (a set of sub-units). Each sub-unit has itself a unity.
> This is repeated until the un-fractionable element of thought, the argument.
>
> Putting in other words: each book has a final conclusion. Each part of the
> book has a conclusion that is one of the arguments to the
> book's conclusion. Each chapter of each part has a conclusion that is
> an argument to the part's conclusion, etc. This repeats itself (e.g.
> chapters, sections, sub-sections, paragraphs) until the basic element:
> an argument made out of prepositions and reasoning connecting prepositions.
>
> 4. The reader must be able to state the unity of the book and enumerate
> the major parts that it is constituted before he starts reading it
> (top-down approach). This is to avoid wasting time reading
> an uninteresting book.
>
> 5. The reader must then reach the unity of each sub-unit by a bottom-up
> approach: prepositions with reasoning generate arguments, arguments
> generate conclusions of sub-units, which are arguments of larger sub-units.
> At some point this meets the top-down approach (4.). If the reader can
> state, by own words, how the author reached the book's unity by this
> bottom-up construction, the authors claim he understood the book.
>
> -- After understanding, criticism... -
>
> 6. Do not begin criticism until you have completed your outline and your
> interpretation of the book. (Do not say "I agree", "I disagree", or "I
> suspend judgment", until you can say “I understand.”).
>
> 7. Do not disagree disputatiously or contentiously (e.g. only disagree if
> you expect that some agreement will be possible). Here is a beautiful
> passage on this:
>
> The trouble is that many people regard disagreement as unrelated to either
> teaching or being taught. They think that everything is just a matter of
> opinion. I have mine, and you have yours; and our right to our opinions is
> as inviolable as our right to private property. On such a view,
> communication cannot be profitable if the profit to be gained is an
> increase in knowledge. Conversation is hardly better than a ping-pong game
> of opposed opinions, a game in which no one keeps score, no one wins, and
> everyone is satisfied because he does not lose—that is, he ends up holding
> the same opinions he started with.
> We would not—and could not—write this book if we held this view. Instead,
> we hold that knowledge can be communicated and that discussion can result
> in learning. If genuine knowledge, not mere personal opinion, is at stake,
> then, for the most part, either disagreements are apparent only—to be
> removed by coming to terms and a meeting of minds; or they are real, and
> the genuine issues can be resolved—in the long run, of course—by appeals to
> fact and reason. The maxim of rationality concerning disagreements is to be
> patient for the long run. We are saying, in short, that disagreements are
> arguable matters. And argument is empty unless it is undertaken on the
> supposition that there is attainable an understanding that, when attained
> by reason in the light of all the relevant evidence, resolves the original
> issues.
>
>
> These rules continues, specifically on what form one can disagree:
>
> 7.1. Author is uninformed (relevant information neglected)
>
> 7.2. Author is misinformed (wrong information)
>
> 7.3. Author is illogical (formal fallacy, e.g. (A=>B) => (~A => ~B),
> typically difficult to find in written language)
>
> 

Re: [discussion] communication guidelines in django

[ptone]

On Monday, September 9, 2013 3:30:41 AM UTC-7, Jorge C. Leitão wrote:
>
>
> Specifically, my suggestion is to add a new section, probably in 
> https://docs.djangoproject.com/en/dev/internals/contributing/new-contributors/,
>  
> on how to communicate in this project (which should be similar to other 
> open source projects).
>

I think there is room for some small targeted improvements to that doc.

There is no link anywhere on that page to this mailing list - so the 
mention of it in the FAQ could be made a link.

This page has most of the current guidelines about when posting to this 
list is warranted (with links):

https://docs.djangoproject.com/en/dev/internals/contributing/triaging-tickets/

As far as other additions, the docs, like the code goes through a process 
of submitting a ticket and patch - so if you have an idea, I would start 
that discussion on the ticket tracker. Things don't usually require a 
pre-discussion here unless it is something contentious. I will say that you 
will need to consider the practical side that contributor docs need to be 
concise, too wide a scope of "how to communicate on the internet" will 
create its own barrier via sheer mass of docs, so understand there is a 
line to tread.

-Preston

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Kickstarter for Django Admin?

[German Larrain]

BTW, the URLs
http://blog-amirouche.dotcloud.com/notes/2013/admin-next-a-new-api.html
http://amirouche.github.io/blog/django-admin-next-a-new-api.html
lead to 404s.

The correct one is
http://www.hypermove.net/notes/2013/admin-next-a-new-api.html

On Saturday, March 30, 2013 5:49:27 PM UTC-5, Amirouche Boubekki wrote:
>
>
> 2013/3/30 Victor Hooi 
>
>> heya,
>>
>> Aha, yes - we need a roadmap, and somebody from the team to execute it 
>> *grins*.
>>
>> For the former - I believe there was already discussions on that sort of 
>> thing on this board?
>>
>> There's a wiki page with some notes as well:
>>
>> https://code.djangoproject.com/wiki/AdminNext
>>
>> I also had a look at some of the existing projects:
>>
>>- https://github.com/yawd/yawd-admin
>>- https://github.com/michaelhelmick/django-bootstrap-admin (Doesn't 
>>appear to be too active)
>>- https://github.com/riccardo-forina/django-admin-bootstrapped
>>- https://github.com/aobo711/bootstrap-django-admin
>>- 
>> https://github.com/gkuhn1/django-admin-templates-twitter-bootstrap(Doesn't 
>> appear to be too active)
>>- https://github.com/divio/djangocms-admin-style
>>
>> And there's obviously Grapelli.
>>
>> A lot of these are obviously just reskins, while others offer a bit more.
>>
>> From the existing projects, we can draw two clear requirements that 
>> people want:
>>
>>- Changing the look and feel - I'm not sure what Django core's 
>>feelings on it, but there seems to be a feeling from the community that 
>> the 
>>look of the current Django Admin is somewhat dated? Also, any new admin 
>>should probably be responsive, and work on mobile or non-desktop devices, 
>>if that's possible. 
>>
>>
> This question leads to another should Django develop its own css framework 
> and re-use existing one, if Django use an existing one, Django must make it 
> easy to work with the preprocessor. While I liked much bootstrap, 
> foundation's mobile first approach of Foundation is appealing even if more 
> verbose.
>  
>
>>
>>- More customisations -  a lot of people want to create dashboards 
>>around the admin, add new sections/tabs, or move things around - the 
>>current Admin doesn't have much scope for that, or it's not easily 
>>accessible. 
>>
>> Those are all things that are doable right now. I though it was about 
> something more «disruptive» that's why I called the page AdminNext to 
> follow the naming of next html version... whatever the naming, the goal 
> should be the same aka. not only a cbv-Admin which should only adress the 
> customisability (and readability) side but add features. This lead me to 
> the group/permission-centric admin which creates menu based on permissions, 
> but I did not implement it. I've documented a sketch API [1], but I'm not 
> very happy with it, I'm now thinking about something in the spirit of 
> lettuce to create an admin.
>
> I stopped working on the composite admin because a) the composite thing is 
> too much b) I wasn't confortable with the code handling inlines in current 
> admin so I started thinking about fixing it but got stuck (!).
>
> Also there is this conversation that is somehow related: 
> https://groups.google.com/forum/#!msg/django-developers/wI18E6BZImQ/TS2wSvUCkaAJ
>
> Maybe Django should gather money somehow and tell a company to do the job 
> instead of relying on the community ?
>
> HTH,
>
> Amirouche
>
> [1] http://amirouche.github.com/blog/django-admin-next-a-new-api.html
>
>  
>
>> For the latter, not sure I can help you there...lol. I thought Idan Gazit 
>> was working on something before though? Or are there other designers on the 
>> Core team? 
>>
>> Cheers,
>> Victor
>>
>> On Sunday, 24 March 2013 22:14:58 UTC+11, Russell Keith-Magee wrote:
>>
>>>
>>> On Sun, Mar 24, 2013 at 6:20 PM, Victor Hooi  wrote:
>>>
 Hi,

 I read recently about Andrew Goodwin's successful kickstarter project 
 for better Django schema migrations:

 http://www.kickstarter.com/**projects/andrewgodwin/schema-**
 migrations-for-django

 Kudos to him for awesome work on South so far a swell =).

 There doesn't seem to be much movement on the Admin front - 
 https://groups.google.com/d/**msg/django-developers/**
 Vozu6U3gz84/vvbTqrWitxIJ

 I'm wondering - is there any impetus for a similar kickstarter for the 
 Django admin?

 I for one would be willing to put my money where my mouth is and back 
 it - and I'm sure other people/companies who use Django in their own 
 projects would as well.

>>>
>>> Good to hear :-)
>>>
>>> There's one significant difference here. Andrew's project was to deliver 
>>> South-like functionality to trunk. South is a known quantity, and there 
>>> 

Re: make the source code of the django tutorial available ?

[gilberto dos santos alves]

very great task!

2013/9/8 German Larrain :
> I know there are different opinions on this topic but if anyone is
> interested, I created a repo for the tutorial. The idea is to have branches
> and tags that match those of the documentation.
>
> https://github.com/glarrain/django-tutorial-source-code
>
> A nice advantage of that is to be able to compare how the resulting code of
> the official tutorial changes between releases. Others are:
>
> Be able to check that the tutorial is correct (it's kind of difficult to
> spot mistakes from the documentation, either rendered or rst), i.e. the code
> works (in fact, I think I discovered a bug in the current master, which I
> will file in trac ASAP).
> Let the user compare at the end of the tutorial the code he/she typed with
> the one in the repo.
>
> Best regards,
> Germán
>
> On Wednesday, January 16, 2013 11:28:42 PM UTC-6, Russell Keith-Magee wrote:
>>
>>
>>
>> On Thu, Jan 17, 2013 at 1:17 PM, Daniel Greenfeld 
>> wrote:
>>>
>>>
>>>
>>> On Wednesday, January 16, 2013 4:43:14 PM UTC-8, Russell Keith-Magee
>>> wrote:

 Hi Daniele,

 On Thu, Jan 17, 2013 at 7:07 AM, Daniele Procida 
 wrote:
>
>
  2) This is what version control is for. I'd much rather see someone do
 the tutorial and use version control on their own repository, rather than
 just pull down the latest version of a repo that contains all the code they
 need.

 Following point 2, it might be worth suggesting that people use version
 control during the tutorial. I'm not suggesting we turn the Django tutorial
 into a parallel tutorial on git, but seeding the idea in people's heads has
 the benefit of reinforcing best practice (you do version control everything
 you do, right?), and makes it easier to work around the rollback problems
 you describe; if they don't know what version control is, they might be
 encouraged to go investigate, and as a result, another code-fairy gets 
 their
 wings :-)
>>>
>>>
>>> There are already third-party versions of the Django tutorial that also
>>> instruct on source control and TDD. These are great, and wonderful, but I
>>> feel they overwhelm beginner Django developers with too much.
>>
>>
>> To be clear -- I'm not suggesting we try and make the Django tutorial a
>> parallel tutorial on source control. I'm just suggesting that we drop a
>> gentle hint at the start of the tutorial, to the effect of:
>>
>> "If you know how to use a source control system (like Git), you might want
>> to set up your tutorial directory as a repository.
>>
>> If you don't know how to use a source control system, don't worry. You
>> don't need to know anything about source control to complete this tutorial.
>> However, source control systems are incredibly useful tools that are used
>> widely in software development, and you'd be well advised to learn how to
>> use them."
>>
>> and then, after completing relevant blocks of work:
>>
>> "If you're using source control on this project, now would be a good time
>> to commit what you've done."
>>
>> The aim is to encourage best practice, or at least make users *aware* of
>> best practice, but leave the details up to them.
>>
>> Yours,
>> Russ Magee %-)
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.



-- 
gilberto dos santos alves
+55.11.98646-5049
sao paulo - sp - brasil

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

[discussion] communication guidelines in django

[Jorge Cardoso Leitao]

Hi Django dev mailing list.

The objective of this email is two-fold:
A: I want to share a book I've read about written communication. Since 
communication in Django, and open source in general, is mainly written, some of 
you may found interesting to take a look.
B: I want to suggest adapting some of the book's content to Django's 
documentation on a form of guidelines on how to communicate on the project 
(skip to end of the mail if part A is not relevant for you).

-- Start of part A --

The book's title is "How to Read a Book", is from 1940 and last revised in 
1972, and basically teaches one how to read (a book).
I find it more general to the extent that it teaches one on how to communicate.
Here I highlight some of its points (the book can be found online here: 
http://crap.sceleris.net/HowtoReadABook.pdf):

0. The book is about reading for understanding, as opposed to for entertainment 
or for getting informed.

-- Reading for understanding -

1. Understanding requires information and thought, but none of them is a 
sufficient condition. It is sufficient to explain something in own words to 
understand it.

2. from 1., any written text must have information, and every writer and reader 
must think during writing and reading respectively.

3. Every (good) text has a unity (and not a multiplicity), and every unity has 
a multiplicity (a set of sub-units). Each sub-unit has itself a unity. This is 
repeated until the un-fractionable element of thought, the argument.

Putting in other words: each book has a final conclusion. Each part of the book 
has a conclusion that is one of the arguments to the book's conclusion. Each 
chapter of each part has a conclusion that is an argument to the part's 
conclusion, etc. This repeats itself (e.g. chapters, sections, sub-sections, 
paragraphs) until the basic element: an argument made out of prepositions and 
reasoning connecting prepositions.

4. The reader must be able to state the unity of the book and enumerate the 
major parts that it is constituted before he starts reading it (top-down 
approach). This is to avoid wasting time reading an uninteresting book.

5. The reader must then reach the unity of each sub-unit by a bottom-up 
approach: prepositions with reasoning generate arguments, arguments generate 
conclusions of sub-units, which are arguments of larger sub-units. At some 
point this meets the top-down approach (4.). If the reader can state, by own 
words, how the author reached the book's unity by this bottom-up construction, 
the authors claim he understood the book.

-- After understanding, criticism... -

6. Do not begin criticism until you have completed your outline and your 
interpretation of the book. (Do not say "I agree", "I disagree", or "I suspend 
judgment", until you can say “I understand.”).

7. Do not disagree disputatiously or contentiously (e.g. only disagree if you 
expect that some agreement will be possible). Here is a beautiful passage on 
this:

>   The trouble is that many people regard disagreement as unrelated to 
> either teaching or being taught. They think that everything is just a matter 
> of opinion. I have mine, and you have yours; and our right to our opinions is 
> as inviolable as our right to private property. On such a view, communication 
> cannot be profitable if the profit to be gained is an increase in knowledge. 
> Conversation is hardly better than a ping-pong game of opposed opinions, a 
> game in which no one keeps score, no one wins, and everyone is satisfied 
> because he does not lose—that is, he ends up holding the same opinions he 
> started with.
>   We would not—and could not—write this book if we held this view. 
> Instead, we hold that knowledge can be communicated and that discussion can 
> result in learning. If genuine knowledge, not mere personal opinion, is at 
> stake, then, for the most part, either disagreements are apparent only—to be 
> removed by coming to terms and a meeting of minds; or they are real, and the 
> genuine issues can be resolved—in the long run, of course—by appeals to fact 
> and reason. The maxim of rationality concerning disagreements is to be 
> patient for the long run. We are saying, in short, that disagreements are 
> arguable matters. And argument is empty unless it is undertaken on the 
> supposition that there is attainable an understanding that, when attained by 
> reason in the light of all the relevant evidence, resolves the original 
> issues.

These rules continues, specifically on what form one can disagree:

7.1. Author is uninformed (relevant information neglected)

7.2. Author is misinformed (wrong information)

7.3. Author is illogical (formal fallacy, e.g. (A=>B) => (~A => ~B), typically 
difficult to find in written language)

7.4. Author's analysis is incomplete (most common, when the analysis does not 
consider other important arguments).

Each of these bullets, as well of each of the 

Re: Support POST of application/json content type

[S Berder]

Gents,
to sum it up, arguments made and details of how I see the
implementation of a response/request encode/decode framework:

* need a pluggable interface so current content-types are supported
(`application/x-www-form-urlencoded`, `multipart/form-data`), new
types (`application/json`), custom and future types
(`application/vnd.foobar+json` anybody? See
http://developer.github.com/v3/media/#api-v3-media-type-and-the-future
for example, `application/msgpack`, `application/protobuf`,
`application/capnproto`, etc).
* decoder/encoder map (content-type, decoder) should be smart to
handle patterns like `text/*` or `application/*xml*` and match things
like `Accept: application/json, text/plain, * / *`
* choice of decoder would be made on the Content-Type header, maybe
supporting a raw by default so data is just passed in case of unknown
content type.
* decoder/encoder should be available through `request` and `response` objects.
* decoded data structure (python object) would be stored in `request.data`
* first step is to support requests, next step is to handle responses
with the same pluggable functionality and coherent API.
* A sensible default for response Content-type would be `text/html;
charset=UTF-8`. It should be made available through a setting entry
anyway

Some questions though:

* why keep data and files separated, I see no good reason for this
except mimicking PHP's structure. An uploaded file comes from a named
input, I hope to find it in request.data (why do a common structure
otherwise). I might be missing something but nothing indicates a real
need for this in django/http/request.py
* isn't more or less any data sent to your backend representable as a
dict or object with dict access modes? I try to think about
occurrences where some data would not have a 'name'.

I'm sure I left some obvious things out like more settings and others
but this will become obvious while coding.

If no strong objection, I'm ready to start in that direction and
provide code sometime next week.

Stefan

On Thu, Sep 5, 2013 at 7:31 AM, Curtis Maloney
 wrote:
> To weight in from an author of a different API tool
>
> In django-nap there's a simple "get_request_data" method which, essentially,
> determines how to parse the request according to the content type.  However,
> currently each API only supports a single serialiser format [and HTTP Form
> encoding] so there's little guessing involved.
>
> However, I wouldn't want to see the same on Request, unless there was also a
> direct way to imply the type you want.  For instance, if I get a request
> that's in XML, and I ask for request.JSON, I'd like it to either yield empty
> or raise an error.  Whereas when I didn't case, accessing request.DATA would
> make a best guess.
>
> So I see two paths... either you use a "Decode it for me according to
> content-type" interface, or a "Treat is as this type, and fail predictably
> if it's not" one.
>
> The current GET/POST is, of course, the latter.  And there's no reason we
> can't have both :)
>
> --
> Curtis
>
>
>
> On 5 September 2013 04:06, Jonathan Slenders 
> wrote:
>>
>> Would that mean that the object returned by request.DATA/POST/whatever
>> could be a different type, depending on what the user posted?
>>
>> I don't want to see code like:
>>
>> if isinstance(request.DATA, YamlObject): ...
>> elif isinstance(request.DATA, dict): ...
>>
>> although, I'm not sure how any view could handle any random
>> content-type...
>>
>>
>>
>> Le mercredi 4 septembre 2013 13:57:29 UTC+2, Marc Tamlyn a écrit :
>>>
>>> The thing with request.POST is that it's kinda unintuitive when extended
>>> to other HTTP methods (e.g. PUT). This is why the old request.raw_post_data
>>> was renamed request.body.
>>>
>>> request.POST would behave in the expected traditional 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 $REQUEST
>>> which we mimic on the request object. The generally have different use cases
>>> anyway - one for complex web things and the other for standard web browsers.
>>>
>>> (the above is what tom said...)
>>>
>>> Tom - what else do you have in DRF's Request that you would need?
>>>
>>>
>>> On 4 September 2013 12:56, Tom Christie  wrote:

 > Creating a request.DATA attribute would break compatibility with old
 > code and seem to me less intuitive.

 The implementation would ensure `request.POST` would still be populated
 for form data.

 There wouldn't have to be any backwards incompatible changes, and usage
 of `request.DATA` (or whatever better name there might be, perhaps simply
 `request.data`) would be entirely optional for using with generic request
 parsing, instead of form data only.


 > Where