Re: Support POST of application/json content type

2013-09-10 Thread S Berder 
On Tue, Sep 10, 2013 at 12:17 PM, S Berder  wrote:
> 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})/

In the absence of strong objection, I will start working on this base.

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: Allowing custom attributes in Meta classes

2013-09-10 Thread Andy McCurdy 

On Sep 10, 2013, at 7:05 PM, Russell Keith-Magee  
wrote:

> I share James' reservations about this as a feature -- attaching flags to 
> Meta is something I can see being abused in all sorts of ways -- but that 
> doesn't mean there's no legitimate uses for extensions to Meta. For example, 
> the USERNAME_FIELD added in support of custom users should, arguably, be a 
> Meta option -- but there was no way we could add that without making a Meta 
> option available to every class.

For what it's worth, I've loosely copied Django's "metaclass w/ Meta options" 
pattern for several projects. In cases where I needed a bit more flexibility, 
the metaclass looked for a well named attribute on the class that would specify 
the options class to use. For example:


class Model(object):
# _meta is a ModelOptions instance
__OPTIONS_CLASS__ = ModelOptions


class Foo(Model):
# _meta is a ModelOptions instance, inheriting Model's __OPTION_CLASS__


class User(Model):
# _meta is a UserModelOptions instance that looks
# for a USERNAME_FIELD option
__OPTIONS_CLASS__ = UserModelOptions

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

2013-09-10 Thread Russell Keith-Magee 
Here's a draft for inclusion right underneath the heading introducing
GZipMiddleware

.. admonition:

  Security researchers recently revealed that when compression techniques
(including GZipMiddlware) are used on a website, a site becomes exposed to
a number of possible attacks. These approaches can be used to compromise,
amongst other things, Django's CSRF protection. Before using GZipMiddleware
on your site, you should consider very carefully whether you are subject to
these attacks. If you're in *any* doubt about whether you're affected, you
should avoid using GZipMiddlware. For more details, see the [paper
discussing the BREACH attack], and the [website that provides a summary of
the issues involved.]

Yours,
Russ Magee %-)


On Tue, Sep 10, 2013 at 9:24 AM, Daniele Procida  wrote:

> On Fri, Aug 9, 2013, Daniele Procida  wrote:
>
> >What should the documents have to say on the subject now, in light of
> >?
> >
> >
>
> I'm rasising this issue again, because our documentation still suggests
> using GZipMiddleware and doesn't offer any warnings; I'd submit a pull
> request updating the documents, but I don't know enough about the subject
> to know what it should actually say.
>
> Daniele
>
> --
> 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.
>

-- 
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: Allowing custom attributes in Meta classes

2013-09-10 Thread Russell Keith-Magee 
On Tue, Sep 10, 2013 at 7:34 AM, Marc Tamlyn  wrote:

> I'm not sure either way on this one. I don't want people to get carries
> away with Meta, it's not a dumping ground for any old thing you like. That
> said, for a developer of a third party library which extends the ORM, the
> inability to extend Meta is very problematic.
>
> I think a balance could be found where strict validation is retained, but
> third party apps can add to that validation. The difficulty is the API - if
> would be good if it could be done on a per model basis rather than a
> global. This should be explicit on behalf of the end user. I'm not sure how
> this would work though.
>
On the basis that this discussion is happening at all, I've just closed
#21081 as a duplicate of a newly-reopened #5793.

I share James' reservations about this as a feature -- attaching flags to
Meta is something I can see being abused in all sorts of ways -- but that
doesn't mean there's no legitimate uses for extensions to Meta. For
example, the USERNAME_FIELD added in support of custom users should,
arguably, be a Meta option -- but there was no way we could add that
without making a Meta option available to every class.

So - I think custom Meta options are something that should be *possible*. I
don't have any particular ideas for how it should be implemented, though.

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.

[ANNOUNCE] Security releases issued (1.4.7, 1.5.3, 1.6 beta 3)

2013-09-10 Thread James Bennett 
Today the Django team is issuing multiple releases -- Django 1.4.7, Django
1.5.3, and Django 1.6 beta 3 -- as part of our security process. These
releases address a directory-traversal vulnerability in one of Django's
built-in template tags.

More details can be found on our blog:

https://www.djangoproject.com/weblog/2013/sep/10/security-releases-issued/

As a reminder, we ask that potential security issues be reported via
private email to secur...@djangoproject.com, and not via Django's Trac
instance or the django- developers list. Please see
https://www.djangoproject.com/security for further information.

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

2013-09-10 Thread Daniele Procida 
On Fri, Aug 9, 2013, Daniele Procida  wrote:

>What should the documents have to say on the subject now, in light of
>?
>
>

I'm rasising this issue again, because our documentation still suggests using 
GZipMiddleware and doesn't offer any warnings; I'd submit a pull request 
updating the documents, but I don't know enough about the subject to know what 
it should actually say.

Daniele

-- 
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: Allowing custom attributes in Meta classes

2013-09-10 Thread Marc Tamlyn 
I'm not sure either way on this one. I don't want people to get carries
away with Meta, it's not a dumping ground for any old thing you like. That
said, for a developer of a third party library which extends the ORM, the
inability to extend Meta is very problematic.

I think a balance could be found where strict validation is retained, but
third party apps can add to that validation. The difficulty is the API - if
would be good if it could be done on a per model basis rather than a
global. This should be explicit on behalf of the end user. I'm not sure how
this would work though.

Marc
On 10 Sep 2013 13:04, "Karan Lyons"  wrote:

> Hey all,
>
> I recently opened up a ticket (https://code.djangoproject.com/ticket/21081)
> that turns out to be a dupe of https://code.djangoproject.com/ticket/5793,
> both in regards to allowing custom attributes in a model's Meta class.
>
> It was wontfix'd six years ago, the reasoning being that Meta should
> really only be for setting options related to Django internals. I'm
> personally of the opinion that at this point Meta is considered the place
> for *any* options related to a model by developers, and that handling
> custom options outside of Meta seems against the general Django coding
> style. Currently you can come up with hacks like
> https://github.com/karanlyons/django-save-the-change/blob/feature/update-together/save_the_change/mixins.py#L188to
>  take care of the issue, but this isn't very nice for a number of reasons.
>
> Do we think this should still be a wontfix, and are there any other
> reasons why?
>
> --
> 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.
>

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

Allowing custom attributes in Meta classes

2013-09-10 Thread Karan Lyons 
Hey all,

I recently opened up a ticket (https://code.djangoproject.com/ticket/21081) 
that turns out to be a dupe of https://code.djangoproject.com/ticket/5793, 
both in regards to allowing custom attributes in a model's Meta class.

It was wontfix'd six years ago, the reasoning being that Meta should really 
only be for setting options related to Django internals. I'm personally of 
the opinion that at this point Meta is considered the place for *any* 
options related to a model by developers, and that handling custom options 
outside of Meta seems against the general Django coding style. Currently 
you can come up with hacks 
like 
https://github.com/karanlyons/django-save-the-change/blob/feature/update-together/save_the_change/mixins.py#L188
 
to take care of the issue, but this isn't very nice for a number of reasons.

Do we think this should still be a wontfix, and are there any other reasons 
why?

-- 
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: Order of INSTALLED_APPS

2013-09-10 Thread Tim Graham 
Yes, here's the ticket to add validation for 
INSTALLED_APPS: https://code.djangoproject.com/ticket/12288

On Monday, September 9, 2013 6:32:48 PM UTC-4, German Larrain wrote:
>
> Hi guys
>
> A related question: What about repeated entries of apps in INSTALLED_APPS? 
> I remember seeing this once and, if I recall correctly, no errors were 
> raised. I guess ImproperlyConfigured would be a suitable exception.
>
> Germán
>
> On Tuesday, August 13, 2013 5:09:45 AM UTC-5, Stefano Crosta wrote:
>>
>> Aymeric, Ramiro, Florian,
>>
>> thanks a lot for your answers!
>>
>> Indeed there is some (slightly hidden :D ) documentation! 
>> And it has improved since 1.5, I now see! - I remembered reading 
>> something before, but I couldn't find them anymore when I wrote yesterday's 
>> message.
>>
>> My proposal would then be to simply add another box to the 
>> https://docs.djangoproject.com/en/dev/ref/settings/#installed-apps to 
>> say "order matters" once more and link the other two pages for translations 
>> and templates.
>> *if you think this would* help I could do it as well as a ticket. To save 
>> everybody's time no answer will mean it's not worth it!
>>
>> (PS. Also please fully disregard my momentary lapse of reason concerning 
>> `sets` in the settings - I don't know what got into me)
>>
>> thanks&best,
>> Stefano
>>
>>
>> On Monday, August 12, 2013 8:29:49 PM UTC+2, Florian Apolloner wrote:
>>>
>>> On Monday, August 12, 2013 3:41:15 PM UTC+2, Ramiro Morales wrote:

 For translations, we have such documentation already: 


 https://docs.djangoproject.com/en/1.5/topics/i18n/translation/#how-django-discovers-translations
  

>>>
>>> For templates too: 
>>> https://docs.djangoproject.com/en/dev/ref/templates/api/#django.template.loaders.app_directories.Loader--
>>>  but I agree it's somewhat hidden ;) 
>>>
>>> Florian
>>>
>>

-- 
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: django.utils.functional documentation

2013-09-10 Thread Aymeric Augustin 
Hi Daniele,

As you noticed, the purpose of these functions isn't very well defined. They 
were written to fill specific use cases in the Django codebase.

Before we document django.utils.functional, effectively making it a stable API, 
it would be best:
- to define a consistent and nice API covering a sensible scope,
- to make sure their behavior is intuitive and as safe as possible, and 
otherwise consider adding safeguards.

Sometimes not documenting anything is better than providing a sub-par API… This 
isn't a strong opinion or a -1, just something for you to consider before 
moving forwards with that plan.

-- 
Aymeric.



On 9 sept. 2013, at 12:47, Daniele Procida  wrote:

> There are caching/laziness-related functions and classes in 
> django.utils.functional, but none seem to be documented (apart from 
> cached_property which has documentation forthcoming).
> 
> 
> django.utils.functional.memoize
> 
> Caches the output of a function in a dictionary. Could this be implemented as 
> a decorator, and if so, would that be a more elegant way to make use of it?
> 
> 
> django.utils.functional.lazy
> 
> Makes a callable lazy. Could this also be implemented as a decorator? And 
> could a function be both memoized and made lazy?
> 
> 
> django.utils.functional.allow_lazy
> 
> A decorator that makes a function respect the laziness of its arguments - if 
> it's called with lazy arguments, it will itself become lazy.
> 
> 
> django.utils.functional.LazyObject
> django.utils.functional.SimpleLazyObject
> 
> Wrappers to make classes lazy. The difference between them is that when the 
> wrapped classes are finally instantiated, the former makes it possible to 
> manipulate the instantiation. The difference between these and 
> django.utils.functional.lazy:
> 
> * lazy() can be applied to any callable, not just objects
> * lazy() needs to know in advance what type the resulting items will be, 
> whereas these don't
> 
> 
> django.utils.functional.Promise
> django.utils.functional.curry
> django.utils.functional.lazy_property
> 
> I can't work out what these are for. Are they things that ought to be 
> documented?
> 
> 
> Daniele
> 
> -- 
> 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.

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