Re: Design discussion: admin alert messages

2013-10-09 Thread Ryan Allen 
It doesn't appear that the images I attached are being shown. Imgur instead:

Updated error:
http://imgur.com/JdoGyqw
Updated Error with Protonopia
http://imgur.com/Ve1ifAP

Deuteranomoly Success Message
http://imgur.com/QvqOHuo

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fa627c40-3d46-4a73-b65e-2ba2991b24fc%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Design discussion: admin alert messages

2013-10-09 Thread Ryan Allen 
Yes, thank you Russ. The conditions you mentioned were all considered when 
these 
screenshots  were created, with the exception of 
Deuteranomoly (reduced sensitivity to green) as the test results were 
nearly the same as the Protonomaly (reduced sensitivity to red) screenshots.

For good measure - Deuteranomoly Success Message




On Wednesday, October 9, 2013 8:40:55 PM UTC-4, Russell Keith-Magee wrote:
>
>
> For the sake of completeness, it's worth pointing out two things:
>
>  1) "Color blindness" isn't a single medical condition. It's half a dozen 
> different conditions, all with different colour distortions, ranging from 
> mild colour spectrum distortion (Protanomaly, Deuteranomaly and 
> Tritanomaly), to complete absence of colour vision (Achromatopsia).
>
>  2) The existing design already accounts for this. It's a monochromatic 
> design (all messages in yellow) that uses icons to differentiate between 
> "error", "warning" and "info". The proposed designs are introducing colour, 
> but aren't removing the iconic elements.
>
> For me, the only question here is the specific choice of colour. The 
> existing design isn't heavily using colour to communicate significance of a 
> message. Introducing colour will be a UX win for those with colour vision; 
> if we pick a good set of colors, those with a mild colour sensory disorder 
> will still be able to distinguish error types based on colour. However, 
> even if you are completely monochromatic, the icons are still there, so a 
> visual cue exists.
>
> Yours,
> Russ Magee %-)
>
> On Thu, Oct 10, 2013 at 6:52 AM, Ryan Allen 
> > wrote:
>
>> Recent commits to improve error messages, particularly for those with 
>> color blindness:
>>
>> 
>>
>>
>> 
>>
>>
>> On Tuesday, October 8, 2013 2:46:08 PM UTC-4, Ryan Allen wrote:
>>>
>>> Here are comparisons for several different color blindness types: 
>>> http://imgur.com/a/**JaLPD 
>>>
>>> On Tuesday, October 8, 2013 3:16:32 AM UTC-4, HM wrote:

 Did you test the colors with a color-blind filter? Always a question to 
 ask when red and green is given significance in any way. The new error red 
 is better though, bigger contrast to the white.



 On 7 October 2013 22:44, Ryan Allen  wrote:

> https://github.com/django/**django/pull/1715
>
> Currently, all admin messages have a background color of light yellow, 
> whether they are success message, warning message, or error message. 
> Errors 
> are displayed with red (#F00) text.
>
> This pull request would give success messages a green background and 
> errors a light red with dark red border and text.
>
> Current alerts: http://imgur.com/a/**dIO6O 
> Updated alerts: http://imgur.com/a/**fw54u 
>
> -- 
> 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-develop...@**googlegroups.com.
> To post to this group, send email to django-d...@googlegroups.com.
> Visit this group at 
> http://groups.google.com/**group/django-developers
> .
> To view this discussion on the web visit https://groups.google.com/d/*
> *msgid/django-developers/**2ab5f4ee-16df-4bf2-8d3e-**
> 893885d51f39%40googlegroups.**com
> .
> 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-develop...@googlegroups.com .
>> To post to this group, send email to 
>> django-d...@googlegroups.com
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/59c5ad77-ce65-4d51-8d3f-2a9253b6dd8c%40googlegroups.com
>> .
>>
>> 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 g

Re: Dynamic AUTH_USER_MODEL based on modules or routes

2013-10-09 Thread Russell Keith-Magee 
On Thu, Oct 10, 2013 at 9:06 AM, Burak Emre Kabakcı
wrote:

> Again, thanks for the other alternatives.
>
> Today, I have worked with auth.backends.ModelBackend and it seems it would
> be possible to separate user resources (like if the route namespace is
> "myapp", then go with Customer table) if get_user(self, user_id) method is
> called with request parameter. It's only called by auth.get_user(request)
> which already has the request parameter in order to obtain backend session
> key. I had to change original Django source code to send extra request
> parameter to ModelBackend.get_user (which is really embarrassing, I know).
> Then I used monkey patching technique in my application code to keep Django
> source code original. (which is also embarrassing)
>

The reason that I really want to do is the database will be used by another
> framework in Java and my teammates insist on keeping customers data on
> another table (It also seems reasonable to me).
>
> I think your separated project solution is the legit way to to something
> like that but the problem is I have to run two python instances in server
> and it will become harder to manage these instances. Also AFAIK they will
> have to use different ports I will have to use reverse proxy to attach the
> other project to a path.
>
> No, they wont. Apache can trivially set up different subpaths under a
single domain.

However, we're now well outside the domain of a Django Developers thread --
you're back into Django-users territory.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJxq84-oK4FArK%2Bi-uPUfzGst%2BPbmXV4fwtBZ2_-ofo5nZRJnQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Dynamic AUTH_USER_MODEL based on modules or routes

2013-10-09 Thread Burak Emre Kabakcı 
Again, thanks for the other alternatives.

Today, I have worked with auth.backends.ModelBackend and it seems it would 
be possible to separate user resources (like if the route namespace is 
"myapp", then go with Customer table) if get_user(self, user_id) method is 
called with request parameter. It's only called by auth.get_user(request) 
which already has the request parameter in order to obtain backend session 
key. I had to change original Django source code to send extra request 
parameter to ModelBackend.get_user (which is really embarrassing, I know). 
Then I used monkey patching technique in my application code to keep Django 
source code original. (which is also embarrassing)

The reason that I really want to do is the database will be used by another 
framework in Java and my teammates insist on keeping customers data on 
another table (It also seems reasonable to me).

I think your separated project solution is the legit way to to something 
like that but the problem is I have to run two python instances in server 
and it will become harder to manage these instances. Also AFAIK they will 
have to use different ports I will have to use reverse proxy to attach the 
other project to a path.

Sincerely,
Burak Emre

On Thursday, October 10, 2013 3:09:22 AM UTC+3, Russell Keith-Magee wrote:
>
>
> On Thu, Oct 10, 2013 at 6:00 AM, Burak Emre Kabakcı 
> 
> > wrote:
>
>> Thanks for the suggestions.
>>
>> @Andre Terra I figured out that my solution doesn't work actually. 
>> Custom managers is not useful in my case because underlying auth system is 
>> still same, it means it will also use same same session tables, cookies etc.
>>
>> @Russell Keith-Magee  Sorry, I couldn't understand what you mean in your 
>> second paragraph. What I'm trying to do is exactly what you're suggesting, 
>> in the example there is an app called "myapp" and I resolve the url and if 
>> the request is routed to a view in "myapp" app I change AUTH_USER_MODEL 
>> setting because AFAIK all applications use a shared settings.py file. If 
>> there's a way to use different settings for each application, please let me 
>> know.
>> Otherwise if you're suggesting that I should start new project that has 
>> its manage.py and settings.py I think it would be much more painful.
>>
>
> Yes - I mean having two separate projects, with two separate settings 
> files, etc. 
>
> As for being "more painful" -- more painful than what? You haven't 
> proposed an alternative that will actually work - your middleware-based 
> solution is fundamentally flawed, for the reasons I described in the first 
> paragraph of my original response.
>
> It's not like we're talking about a lot of code here. You need to have 2 
> different settings files. However, those two settings files can share a 
> common base -- at a bare minimum, it only needs to say:
>
> ---
> from common_settings import *
>
> AUTH_USER_MODEL = 'project1.User'
> ---
>
> where common_settings is a file that contains the settings common between 
> the two projects. Yes, there's some complexity here. But then, you're the 
> one with a project with two different concepts of User. It doesn't matter 
> *what* you do, there's going to be complexity. 
>
> It's also worth pointing out the other alternatives:
>
> * Use a *single* user model, but have *profiles* to cover the different 
> "types" of user. If you need a foreign key, use a foreign key to the 
> *profile*, not the User.
>
> * Write your own authentication backend. Django's auth backend is 
> pluggable, and isn't bound to auth.User at all. 
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d9b7106b-5e30-4275-ba26-112f324031c1%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Design discussion: admin alert messages

2013-10-09 Thread Russell Keith-Magee 
For the sake of completeness, it's worth pointing out two things:

 1) "Color blindness" isn't a single medical condition. It's half a dozen
different conditions, all with different colour distortions, ranging from
mild colour spectrum distortion (Protanomaly, Deuteranomaly and
Tritanomaly), to complete absence of colour vision (Achromatopsia).

 2) The existing design already accounts for this. It's a monochromatic
design (all messages in yellow) that uses icons to differentiate between
"error", "warning" and "info". The proposed designs are introducing colour,
but aren't removing the iconic elements.

For me, the only question here is the specific choice of colour. The
existing design isn't heavily using colour to communicate significance of a
message. Introducing colour will be a UX win for those with colour vision;
if we pick a good set of colors, those with a mild colour sensory disorder
will still be able to distinguish error types based on colour. However,
even if you are completely monochromatic, the icons are still there, so a
visual cue exists.

Yours,
Russ Magee %-)

On Thu, Oct 10, 2013 at 6:52 AM, Ryan Allen  wrote:

> Recent commits to improve error messages, particularly for those with
> color blindness:
>
>
> 
>
>
> 
>
>
> On Tuesday, October 8, 2013 2:46:08 PM UTC-4, Ryan Allen wrote:
>>
>> Here are comparisons for several different color blindness types:
>> http://imgur.com/a/**JaLPD 
>>
>> On Tuesday, October 8, 2013 3:16:32 AM UTC-4, HM wrote:
>>>
>>> Did you test the colors with a color-blind filter? Always a question to
>>> ask when red and green is given significance in any way. The new error red
>>> is better though, bigger contrast to the white.
>>>
>>>
>>>
>>> On 7 October 2013 22:44, Ryan Allen  wrote:
>>>
 https://github.com/django/**django/pull/1715

 Currently, all admin messages have a background color of light yellow,
 whether they are success message, warning message, or error message. Errors
 are displayed with red (#F00) text.

 This pull request would give success messages a green background and
 errors a light red with dark red border and text.

 Current alerts: http://imgur.com/a/**dIO6O 
 Updated alerts: http://imgur.com/a/**fw54u 

 --
 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-develop...@**googlegroups.com.
 To post to this group, send email to django-d...@googlegroups.com.
 Visit this group at 
 http://groups.google.com/**group/django-developers
 .
 To view this discussion on the web visit https://groups.google.com/d/**
 msgid/django-developers/**2ab5f4ee-16df-4bf2-8d3e-**
 893885d51f39%40googlegroups.**com
 .
 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/59c5ad77-ce65-4d51-8d3f-2a9253b6dd8c%40googlegroups.com
> .
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJxq84_jjjWMP%2BGbLD8JAw92tPtu13dBuiqGXUYMvPs7n0_3Xg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Support POST of application/json content type

2013-10-09 Thread abh2134 
Hi all,

I would love to be involved with this feature. 

My suggestion is to do the following:

   - Check requst.is_ajax()
   - Check request.META.get('CONTENT_TYPE').count('application/json')
   - Parse request.body using django.utils.simplejson.loads
   - ... and set *request.JSON* to the result 

I have a small piece of middleware that implements this procedure and have 
posted it as a gist, https://gist.github.com/abhillman/6910689.

If there is interest in using my code, I would be very happy to write some 
unit tests.

abh

On Thursday, September 12, 2013 3:46:53 AM UTC-7, Stefan Berder wrote:
>
> Tom,
> I get the context and that form is tied to that behavior but outside of 
> "that's how it is now" is there any technical reason for this? I can't read 
> forms code at the moment but will do tonight and will look at how FILES is 
> used in there. I'm not usually afraid by impacts of it's the "right thing 
> to do". I think it would make for a stronger interface of you could simply 
> find your data in request.data.
>
> I will create a branch in my fork on github and will send it here for 
> progress.
>
> Stefan, from my mobile
> -- 
> http://www.bonz.org/
> /(bb|[^b]{2}/
> On 12 Sep 2013 18:20, "Tom Christie" > 
> wrote:
>
>> > why keep data and files separated
>>
>> Mostly because that's the way it already works, so...
>>
>> * request.data would essentially provide a strict superset of the 
>> functionality that request.POST provides.  In general you'd be able to 
>> replace `request.POST` with `request.data` anywhere and seemlessly start 
>> supporting JSON or other data without any other changes required.
>> * Form expect the data and files to be provided separately which would be 
>> awkward otherwise.
>>
>> > In the absence of strong objection, I will start working on this base. 
>>
>> Sure thing.  As it happens, I was also considering taking a crack at this 
>> in the coming weeks, so please do follow up on this thread linking to your 
>> repo if you start working on it, so myself and others can track any 
>> progress.  (And perhaps collaborate.)
>>
>> Cheers :)
>>
>>   Tom
>>
>> On Wednesday, 11 September 2013 04:52:08 UTC+1, Stefan Berder wrote:
>>>
>>> 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 s

Re: Dynamic AUTH_USER_MODEL based on modules or routes

2013-10-09 Thread Russell Keith-Magee 
On Thu, Oct 10, 2013 at 6:00 AM, Burak Emre Kabakcı
wrote:

> Thanks for the suggestions.
>
> @Andre Terra I figured out that my solution doesn't work actually. Custom
> managers is not useful in my case because underlying auth system is still
> same, it means it will also use same same session tables, cookies etc.
>
> @Russell Keith-Magee  Sorry, I couldn't understand what you mean in your
> second paragraph. What I'm trying to do is exactly what you're suggesting,
> in the example there is an app called "myapp" and I resolve the url and if
> the request is routed to a view in "myapp" app I change AUTH_USER_MODEL
> setting because AFAIK all applications use a shared settings.py file. If
> there's a way to use different settings for each application, please let me
> know.
> Otherwise if you're suggesting that I should start new project that has
> its manage.py and settings.py I think it would be much more painful.
>

Yes - I mean having two separate projects, with two separate settings
files, etc.

As for being "more painful" -- more painful than what? You haven't proposed
an alternative that will actually work - your middleware-based solution is
fundamentally flawed, for the reasons I described in the first paragraph of
my original response.

It's not like we're talking about a lot of code here. You need to have 2
different settings files. However, those two settings files can share a
common base -- at a bare minimum, it only needs to say:

---
from common_settings import *

AUTH_USER_MODEL = 'project1.User'
---

where common_settings is a file that contains the settings common between
the two projects. Yes, there's some complexity here. But then, you're the
one with a project with two different concepts of User. It doesn't matter
*what* you do, there's going to be complexity.

It's also worth pointing out the other alternatives:

* Use a *single* user model, but have *profiles* to cover the different
"types" of user. If you need a foreign key, use a foreign key to the
*profile*, not the User.

* Write your own authentication backend. Django's auth backend is
pluggable, and isn't bound to auth.User at all.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJxq84-Z-%3DQH35_jMHVrs2Ddp9zMBnxLAY_bzFzrptt2a75vKw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Design discussion: admin alert messages

2013-10-09 Thread Ryan Allen 
Recent commits to improve error messages, particularly for those with color 
blindness:






On Tuesday, October 8, 2013 2:46:08 PM UTC-4, Ryan Allen wrote:
>
> Here are comparisons for several different color blindness types: 
> http://imgur.com/a/JaLPD
>
> On Tuesday, October 8, 2013 3:16:32 AM UTC-4, HM wrote:
>>
>> Did you test the colors with a color-blind filter? Always a question to 
>> ask when red and green is given significance in any way. The new error red 
>> is better though, bigger contrast to the white.
>>
>>
>>
>> On 7 October 2013 22:44, Ryan Allen  wrote:
>>
>>> https://github.com/django/django/pull/1715
>>>
>>> Currently, all admin messages have a background color of light yellow, 
>>> whether they are success message, warning message, or error message. Errors 
>>> are displayed with red (#F00) text.
>>>
>>> This pull request would give success messages a green background and 
>>> errors a light red with dark red border and text.
>>>
>>> Current alerts: http://imgur.com/a/dIO6O
>>> Updated alerts: http://imgur.com/a/fw54u
>>>
>>> -- 
>>> 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-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/2ab5f4ee-16df-4bf2-8d3e-893885d51f39%40googlegroups.com
>>> .
>>> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/59c5ad77-ce65-4d51-8d3f-2a9253b6dd8c%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Dynamic AUTH_USER_MODEL based on modules or routes

2013-10-09 Thread Burak Emre Kabakcı 
Thanks for the suggestions.

@Andre Terra I figured out that my solution doesn't work actually. Custom 
managers is not useful in my case because underlying auth system is still 
same, it means it will also use same same session tables, cookies etc.

@Russell Keith-Magee  Sorry, I couldn't understand what you mean in your 
second paragraph. What I'm trying to do is exactly what you're suggesting, 
in the example there is an app called "myapp" and I resolve the url and if 
the request is routed to a view in "myapp" app I change AUTH_USER_MODEL 
setting because AFAIK all applications use a shared settings.py file. If 
there's a way to use different settings for each application, please let me 
know.
Otherwise if you're suggesting that I should start new project that has its 
manage.py and settings.py I think it would be much more painful.

Sincerely,
Burak Emre 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5482e77e-effb-404b-9a70-945c5f75ee7a%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal to end the war with flake8 warnings

2013-10-09 Thread Aymeric Augustin 
On 9 oct. 2013, at 20:38, Tim Graham  wrote:

> If accepted, I'll put together a more concrete proposal that includes which 
> errors we'll ignore, etc.

Sure, go ahead!

I'm always embarrassed when contributors work on large cleanup patches, because 
they're especially tedious to review and don't get committed. However I support 
committers pushing such changes.

-- 
Aymeric.




-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1E190825-533C-4DCD-98D8-7B5FB2179FA0%40polytechnique.org.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Merge policy for cleanup commits

2013-10-09 Thread Danilo Bargen 
Hm, I'm not sure I understand your e-mail. The link you just posted points 
to exactly the topic we're discussing right now. Maybe you meant to post 
another URL?

Cheers,
Danilo

On Wednesday, October 9, 2013 9:11:09 PM UTC+2, Tomáš Ehrlich wrote:
>
> Relevant discussion 
>
> https://groups.google.com/forum/#!msg/django-developers/tcNVvbAv4-M/bs0zPNLqv48J
>  
>
>
> Cheers, 
>   Tom
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d0957cc5-8177-448f-b7c4-110137987304%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal to end the war with flake8 warnings

2013-10-09 Thread Daniele Procida 
On Wed, Oct 9, 2013, Tim Graham  wrote:

>Our docs currently state: "Note, however, that patches which only remove 
>whitespace (or only make changes for nominal PEP 8 conformance) are likely 
>to be rejected, since they only introduce noise rather than code 
>improvement. Tidy up when you're next changing code in the area." I 
>somewhat disagree, I think it's better to make cleanups in separate commits 
>so that when looking at a commit, you don't need to figure out what changes 
>are stylistic and what changes are needed for the fix.

I certainly agree with this.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20131009192201.149641%40smtp.ntlworld.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Merge policy for cleanup commits

2013-10-09 Thread Tomas Ehrlich 
Relevant discussion
https://groups.google.com/forum/#!msg/django-developers/tcNVvbAv4-M/bs0zPNLqv48J


Cheers,
  Tom

Dne Mon, 8 Jul 2013 09:59:49 -0700 (PDT)
Danilo Bargen  napsal(a):

> Hi there
> 
> (I tried to find previous threads concerning the same topic, but could not 
> find any. If this is already the n-th discussion about the topic, sorry 
> about it.)
> 
> I don't quite agree with the cleanup commit policy stated in the docs:
> 
> Systematically remove all trailing whitespaces from your code as those add 
> > unnecessary bytes, add visual clutter to the patches and can also 
> > occasionally cause unnecessary merge conflicts. Some IDE’s can be 
> > configured to automatically remove them and most VCS tools can be set to 
> > highlight them in diff outputs. Note, however, that patches which only 
> > remove whitespace (or only make changes for nominal PEP 
> > 8conformance) are likely to be 
> > rejected, since they only introduce noise 
> > rather than code improvement. Tidy up when you’re next changing code in the 
> > area.
> 
> 
> I did such a PR today (without knowing that policy): 
> https://github.com/django/django/pull/1345
> 
> While I agree that small PRs which fix issues like whitespace should not 
> necessarily clutter up the commit history, I disagree for larger cleanup 
> commits. In some places the code has serious formatting issues (e.g. lines 
> that are indented 3 instead of 4 characters and that only work thanks to 
> the lax Python indentation parsing). Also, I disagree that 1 commit which 
> cleans up a file would "clutter" its commit history.
> 
> While I support fixing coding standard issues on-the-go, I think that it 
> clutters up the commit history in a worse way than a cleanup commit would, 
> because the commits are not strictly focused on the feature or bug they 
> concern.
> 
> In addition to the PEP8 changes there were also a few pyflakes changes that 
> go beyond simple whitespace formatting. For example in the core module 
> there were a few places where "variable == None" was used, even though 
> "variable is none" should be used preferredly. Another issue would be 
> "type(c) == Typeclass" instead of "isinstance(c, Typeclass)".
> 
> Anyways, if you don't want to accept such commits that's OK, but I think 
> adherence to coding standards is pretty bad in many Django modules and it 
> should be fixed. And for sure I won't be the last person to send you such a 
> pull request.
> 
> Danilo
> 


signature.asc
Description: PGP signature

Re: Proposal to end the war with flake8 warnings

2013-10-09 Thread Anssi Kääriäinen 
+1

 - Anssi

On Wednesday, October 9, 2013 9:38:17 PM UTC+3, Tim Graham wrote:
>
> I'd like to propose cleaning up Django's codebase so that we can run 
> flake8 (with some rules ignored) as a presubmit check (for example, hooked 
> into pull request submissions).
>
> Our docs currently state: "Note, however, that patches which only remove 
> whitespace (or only make changes for nominal PEP 8 conformance) are likely 
> to be rejected, since they only introduce noise rather than code 
> improvement. Tidy up when you’re next changing code in the area." I 
> somewhat disagree, I think it's better to make cleanups in separate commits 
> so that when looking at a commit, you don't need to figure out what changes 
> are stylistic and what changes are needed for the fix.
>
> The benefit of doing the cleanup now is that we could automate these style 
> checks afterward which will make code review more efficient. As Alex wrote 
> in his blog post on code 
> review: 
> "Don't use humans to check for things a machine can. This means that code 
> review isn't a process of running your tests, or looking for style guide 
> violations."
>
> A drawback is that it will introduce some noise in the commit history in 
> the short term and make git blame less efficient. I believe the long term 
> benefit of not being at war with these issues is worth this trade-off.
>
> If accepted, I'll put together a more concrete proposal that includes 
> which errors we'll ignore, etc.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8a2a9003-fd6a-4638-bfd1-d766904c7a9c%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal to end the war with flake8 warnings

2013-10-09 Thread Juan Pablo Martínez 
+1 hip hip cleanup!

On Wed, Oct 9, 2013 at 4:38 PM, Tim Graham  wrote:

> things a





-- 
juanpex

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABPLwmAGhzE%2B6mWUE97bY-XCsehM8nYQtvyKO6T-Y%2BeXPNsuYw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Proposal to end the war with flake8 warnings

2013-10-09 Thread Tim Graham 
I'd like to propose cleaning up Django's codebase so that we can run flake8 
(with some rules ignored) as a presubmit check (for example, hooked into 
pull request submissions).

Our docs currently state: "Note, however, that patches which only remove 
whitespace (or only make changes for nominal PEP 8 conformance) are likely 
to be rejected, since they only introduce noise rather than code 
improvement. Tidy up when you’re next changing code in the area." I 
somewhat disagree, I think it's better to make cleanups in separate commits 
so that when looking at a commit, you don't need to figure out what changes 
are stylistic and what changes are needed for the fix.

The benefit of doing the cleanup now is that we could automate these style 
checks afterward which will make code review more efficient. As Alex wrote 
in his blog post on code 
review: 
"Don't use humans to check for things a machine can. This means that code 
review isn't a process of running your tests, or looking for style guide 
violations."

A drawback is that it will introduce some noise in the commit history in 
the short term and make git blame less efficient. I believe the long term 
benefit of not being at war with these issues is worth this trade-off.

If accepted, I'll put together a more concrete proposal that includes which 
errors we'll ignore, etc.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6c55f4a2-3875-4fd1-9c3e-891fa789d0e2%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.