Question about support dates

[Wim Feijen]

Hi,

The release notes of Django 5.0 state:
"Third-party library support for older version of Django¶

Following the release of Django 5.0, we suggest that third-party app 
authors drop support for all versions of Django prior to 4.2. At that time, 
you should be able to run your package’s tests using python -Wd so that 
deprecation warnings appear. After making the deprecation warning fixes, 
your app should be compatible with Django 5.0."

However, Django 3.2 is supported until April 2024. Would it not be 
recommendable for third-party packages to support Django 3.2 as well? 

My proprosal is to remove the above warning entirely from the release 
notes, or to change the first line to "From April 2024 on, we suggest that 
..."

Secondly, it would help me if end dates of both mainstream and extended 
support were set to specific dates. This hold true for all end dates in the 
release schedule on https://www.djangoproject.com/download/ . 
For example, the end date of extended for Django 5.1 ends either in 
December 2025 or per 1st of January 2026, which is not clear to me. I 
believe this difference to be relevant for organizations scheduling updates.

Thanks for considering this, and for the awesome work on making Django 
better and better!

Warm regards,
Wim

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/38ace698-489b-4a66-86d6-bb755e932008n%40googlegroups.com.

Re: Feature request: making gettext more robust

[Wim Feijen]

Hi Gergely,

What helps for me is Django rosetta, https://django-rosetta.readthedocs.io/ 
. It makes filtering on untranslated or fuzzy translations very easy.

Best regards, Wim

PS Sorry for the late response.

Op zaterdag 17 juni 2023 om 16:01:04 UTC+2 schreef Shai Berger:

> Hi Gergely,
>
> On Fri, 16 Jun 2023 16:46:31 +0200
> Gergely Kalmár  wrote:
>
> > 
> > I'm still thinking that it should be possible for Django to wrap
> > gettext in a way that allows us to raise exceptions. It seems silly
> > to me that we could not control this core aspect of the process.
> > 
>
> I think indeed it is possible. Take a look at the code in
> django/utils/translation/trans_real.py and in particular, the
> TranslationCatalog class; I _think_ you should be able to insert a
> "fallback" catalog which raises some non-KeyError exception in its
> `__getitem__()`, and that should give you what you want.
>
> Note that it may be a little complex -- the mechanism there is built to
> handle not only fallback languages (i.e. "en-US => en"), but a set of
> catalogs for each language (i.e. collecting the translations into one
> language from different apps), and further, the translations in each
> language need to be kept separate because each may have its own
> pluralization formula (in English, last I checked, there is only
> one rule -- if the number is not 1, it's plural -- but if you specify
> this rule in the .po file, the formula you get is technically distinct
> from the default. Other languages sometimes have actually different
> rules in different files, mostly for historical reasons).
>
> I'm explicitly not expressing an opinion about whether this is
> desirable :).
>
> HTH,
> Shai.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a47b62e0-e047-4625-9a28-e326f7d59761n%40googlegroups.com.

Re: Django security releases issued: 4.0.4, 3.2.13, and 2.2.28

[Wim Feijen]

Hi, 

Thanks for the release!

This has not directly to do with the security release, but I have a 
question about this remark: "Django 2.2 has reached the end of extended 
support. The final security release (2.2.28) was issued today. "

As I understood it, Django 2.2 will be supported until the end of April, 
meaning the 30th of April will be the last day of support. Because the 
Django release cycle is once every eight months, and years are divided into 
four parts, so the support windows runs up to 1 May. Am I correct in this? 
Our internal update policies are based on this assumption, so it matters a 
lot to us. 

Thanks for your clarification,

Wim

Op maandag 11 april 2022 om 09:57:16 UTC+2 schreef Mariusz Felisiak:

> Details are available on the Django project weblog:
>
> https://www.djangoproject.com/weblog/2022/apr/11/security-releases/
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1e932359-0072-4ba0-96ae-a76bbbc25245n%40googlegroups.com.

Re: Replacing the contrib.sites Site model with a setting?

[Wim Feijen]

Hi all,

I'm in favour of defining the sites in settings. In addition, it would ease 
transferring db dumps from live to test servers and it would prevent db 
queries.

I wonder, because we define sites in ALLOWED_HOSTS as well, whether we can 
combine these settings. 

For scheme, what are expected values here? As we are moving from http to 
https environments, I wonder: do we still want to define schemes? I prefer 
following server configuration here.

Wim


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/bdde6046-1e4a-40c2-b772-436e9c7ddc82%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: change commit message format to present tense?

[Wim Feijen]

I agree with Reinout and on the use of the present tense, so a commit 
message would read:
"Adds password validation to prevent the usage of ..."

My mind finds this way easier to understand than: "Add password validation 
..."

Wim

On Monday, 27 June 2016 13:55:54 UTC+2, Daniele Procida wrote:
>
> On Mon, Jun 27, 2016, Reinout van Rees  
> wrote: 
>
> >Op 26-06-16 om 05:31 schreef Kevin Christopher Henry: 
> >> If anyone's put off by the hectoring tone of the imperative mood, it 
> >> might be better to think of it as the indicative mood. That is: 
> >> 
> >> (This will) "add password validation to prevent the usage of...". 
> >> 
> >> rather than 
> >> 
> >> (You must) "add password validation to prevent the usage of..."! 
> > 
> >"It might be better to think of it as...": it is exactly this extra 
> >thinkwork that everyone reading the messages has to do. We write it once 
> >and read it many times: what should we optimize for? 
> >In our source code, the answer is clearly that you should optimize for 
> >readability. 
> >Why is it suddenly different for commit messages? 
>
> I'm inclined to agree with Reinout that a descriptive message makes more 
> sense and is easier to understand than one written in the form of an 
> instruction. 
>
> Why would a log record be written as an imperative? 
>
> "Updated gnools" tells you what has happened (and even "Updates gnools" is 
> a label saying what the thing it's attached to will do). 
>
> "Update gnools" would make sense as the label for an interface button, but 
> not really as a record in a log. 
>
> Apart from consistency with Git's own messages, I don't really see the 
> advantage. 
>
> Daniele 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/88486c72-c77e-4bc8-89bc-9f87132e99aa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django website ssl-certificate expired

[Wim Feijen]

Hi guys,

Apologies if I am posting in the wrong group, but the certificate of 
djangoproject.com expired today (4 May).

Wim

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e44c883b-41fc-4afb-8717-15c0f0f5dae2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making max_length argument optional

[Wim Feijen]

Hi Florian,

Can you please elaborate why the current situation is better? In practice, 
most people add max_length=255 everytime by hand. I value your opinion but 
I fail to understand your reasoning. Could you please explain further (if 
you have time)?  

Wim 


On Saturday, 27 February 2016 14:01:52 UTC+1, Florian Apolloner wrote:
>
> -1 on adding an arbitrary default like 100/128… If people choose a 
> CharField the should set max_length manually. In that sense I am for option 
> 3.
>
> Cheers,
> Florian
>
> On Saturday, February 27, 2016 at 1:55:23 PM UTC+1, Wim Feijen wrote:
>>
>> Hi guys,
>>
>> I'd like to reach consensus about 
>> https://code.djangoproject.com/ticket/14094
>>
>> In the discussion, I saw three options:
>>
>> 1. Adding a default max_length = None, which may in practice differ per 
>> database backend.
>> 2. Adding a default max_length of a value which can be used across 
>> databases. Lengths which have been mentioned are: 100, 128, 191 and 255 
>> characters and 4000 bytes.
>> 3. Keep everything as is, being as explicit as possible.
>>
>> Option 1 does not allow for apps and data to be reused across several 
>> apps and several core developers do not support this idea.
>>
>> I'm in favour of option 2, because it makes for shorter code and more 
>> importantly, it helps programmers choose a value which actually can be 
>> reused across multiple databases (I didn't know about the possible limit of 
>> 191 characters on mysql! Did you?).
>>
>> I dislike how it is now (option 3), and I don't think it is beneficial 
>> here to force people to be explicit, because people are now using arbitrary 
>> values anyway. 255 is commonly used, the poll app of the Django tutorial 
>> uses 200. Actually I believe it is a big mess in practice, I see defaults 
>> of 100, 200, 255, 300, 1000 seemingly randomly used. For example, try 
>> searching for CharField in your favourite apps or CMSes.
>>
>> In addition, adding a default for max_length still allows to be explicit 
>> when it matters. And it makes life simple when it doesn't matter, and 
>> simple is better than complex.
>>
>> What would be a good default then? I am in favour of making it as big as 
>> possible while still working on all databases, which would either be 191 of 
>> 255 in order to support mysql.
>>
>> Wim
>>
>>
>>
>> On Wednesday, 23 September 2015 19:02:20 UTC+2, Tom Christie wrote:
>>>
>>> I'm with Tom here.
>>> Forcing `max_length` to always be set on CharField feels like the right 
>>> decision. Having a default there seems unnecessary obscure, and more likely 
>>> to lead to untested/unnoticed failure cases.
>>> It *could* be that we'd allow `max_length=None` to explicitly turn off 
>>> the validation, but I'm not sure if that's better than forcing developers 
>>> who want unvalidated lengths to use TextField.
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/871a631d-7e0e-4f14-9f90-ec629d8de26f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making max_length argument optional

[Wim Feijen]

Hi guys,

I'd like to reach consensus about 
https://code.djangoproject.com/ticket/14094

In the discussion, I saw three options:

1. Adding a default max_length = None, which may in practice differ per 
database backend.
2. Adding a default max_length of a value which can be used across 
databases. Lengths which have been mentioned are: 100, 128, 191 and 255 
characters and 4000 bytes.
3. Keep everything as is, being as explicit as possible.

Option 1 does not allow for apps and data to be reused across several apps 
and several core developers do not support this idea.

I'm in favour of option 2, because it makes for shorter code and more 
importantly, it helps programmers choose a value which actually can be 
reused across multiple databases (I didn't know about the possible limit of 
191 characters on mysql! Did you?).

I dislike how it is now (option 3), and I don't think it is beneficial here 
to force people to be explicit, because people are now using arbitrary 
values anyway. 255 is commonly used, the poll app of the Django tutorial 
uses 200. Actually I believe it is a big mess in practice, I see defaults 
of 100, 200, 255, 300, 1000 seemingly randomly used. For example, try 
searching for CharField in your favourite apps or CMSes.

In addition, adding a default for max_length still allows to be explicit 
when it matters. And it makes life simple when it doesn't matter, and 
simple is better than complex.

What would be a good default then? I am in favour of making it as big as 
possible while still working on all databases, which would either be 191 of 
255 in order to support mysql.

Wim



On Wednesday, 23 September 2015 19:02:20 UTC+2, Tom Christie wrote:
>
> I'm with Tom here.
> Forcing `max_length` to always be set on CharField feels like the right 
> decision. Having a default there seems unnecessary obscure, and more likely 
> to lead to untested/unnoticed failure cases.
> It *could* be that we'd allow `max_length=None` to explicitly turn off the 
> validation, but I'm not sure if that's better than forcing developers who 
> want unvalidated lengths to use TextField.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a2cfad14-4384-4118-bc28-d89099433ca5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: structural & functional review of django documentation

[Wim Feijen]

Hi Doug,

I get lost regularly in Django's docs as well, so you are not alone there. 

I think it is a good proposal to add:
 "find what you were looking for" or "was this page helpful" or "rate this 
page on its organization, clarity, brevity, etc." data on every single 
existing page of the documentation. 

I think it is a good thing to accumulate data. And if some page turns out 
to be really bad or not helping, we have a choice to act on it.

For me, that would be a good ticket which I would definitely accept, 
because the scope is small and clear and it is something we agree on. The 
best way to proceed in my opinion is to create an new ticket, to keep it 
clear. Do you want to create this ticket?

I have some other ideas on how to improve the documentation and layout as 
well, but that is for another time.

Bye, Wim 

 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/39421256-8911-4fc7-800d-93d29a091d92%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Proposal: by default, don't populate a modelformset with all model instances.

[Wim Feijen]

By default, when you create a formset from a model, the formset will use a 
queryset that includes all objects in the model (e.g., Author.objects.all()
). 

In most use cases, people will want to use a specific subset of data and 
will construct queryset by hand. Or they want to use an empty queryset, 
just to add data.

In my opinion it would be better to set the empty queryset as a default. 

Do you agree?

Then I will make a ticket and maybe add a patch.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8f172935-bacf-4882-b668-01b001ae467a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Password validation in Django revisited

[Wim Feijen]

Hi Markus and Aymeric,

In my opinion, it is very safe and consistent to use password validation in 
all instances and places. It definitely prevents people from using 
admin/admin and markus/markus as a login, which sounds safe to me. 

If you don't want that, you can change the validators depending on DEBUG in 
your settings; or disable them in your local_settings. In addition, you can 
change the password using the shell as you suggested.

I don't agree that we should allow unsafe passwords in some cases and I 
don't think we should. 

I apologize for differing in opinion,

Wim

On Saturday, 5 September 2015 19:27:07 UTC+2, Aymeric Augustin wrote:
>
> Well, I would prefer asking for confirmation ;-) but not enough to write 
> the code myself.
>
> -- 
> Aymeric.
>
>
>
> On 5 sept. 2015, at 10:54, Markus Holtermann  > wrote:
>
> Hey Aymeric,
>
> I think I'd prefer "downgrade the message to a warning and proceed" for 
> DEBUG=True and list all validation errors, much like for forms. Sticking to 
> the current implementation for DEBUG=False is fine with me. For example:
>
> $ python manage.py createsuperuser
> Username (leave blank to use 'markus'):
> Email address: 
> Password:
> Password (again):
> The passwords do not match.
> Password:
> Password (again):
> You used a password that doesn't fulfill all validation requirements:
>   - This password is too short. It must contain at least 8 characters.
>   - The password is too similar to the email address.
>
> Superuser successfully created
>
> Cheers,
>
> /Markus
>
> On Saturday, September 5, 2015 at 5:14:16 PM UTC+10, Aymeric Augustin 
> wrote:
>>
>> Hello,
>>
>> Indeed, this will be annoying for development.
>>
>> I don’t find the “admins don’t need rules, they know what they’re doing” 
>> argument compelling. The cobbler children’s go barefoot… Besides, if admins 
>> know the rules, having validation enabled won’t hurt :-)
>>
>> I’m in favor of implementing an escape hatch when DEBUG = True:
>>
>> - either downgrade the message to a warning and proceed
>> - or ask the user if they want to proceed with the invalid password 
>> (--no-input would skip this step and proceed silently)
>>
>> -- 
>> Aymeric.
>>
>>
>>
>> On 5 sept. 2015, at 01:56, Markus Holtermann  
>> wrote:
>>
>> Hey,
>>
>> while I like the idea of having the validation in all places to not 
>> forget one that might be user facing, I was surprised by the fact that the 
>> validation also happens in dev environments when you create the superuser 
>> (this whole mail applies to the changepassword command, too):
>>
>> $ python manage.py createsuperuser
>> Username (leave blank to use 'markus'):
>> Email address: 
>> Password:
>> Password (again):
>> This password is too short. It must contain at least 8 characters.
>> Password:
>> Password (again):
>> The password is too similar to the email address.
>> Password:
>>
>>
>> This is a bit annoying for me, given that I normally use "markus" or 
>> "admin" as username and password for the superuser and u1:u1, as 
>> username:password combination for additional users.
>>
>> There are a few solutions to that behavior I'd like to see revisited for 
>> 1.9:
>>
>>1. Disable password validation when DEBUG=True -- I don't think we 
>>really want that
>>2. Don't have password validation for createsuperuser/changepassword: 
>>I personally don't see the benefit for that in the command anyways.
>>   1. In production environments I would expect the admins having 
>>   access to the management command to know their regulations (after all, 
>> they 
>>   need to configure them) and to know what good passwords are. 
>>   2. As somebody who is able to run the "createsuperuser" command I 
>>   figure I can also run "shell", giving me unlimited access to the 
>> password 
>>   field of users, allowing me to set a password that doesn't match the 
>>   requirements.
>>   3. It breaks backwards compatibility with tools like Expect (
>>   https://en.wikipedia.org/wiki/Expect -- yes, I had to use that in 
>>   the past)
>>3. Disable validation when passing --no-validate or 
>>--no-validate-password to createsuperuser, though this is still backwards 
>>incompatible and a lot to type -- I'd better of with having a valid 
>>password -- or the other way around, passing --validate / 
>>--validate-password, but this feels pointless
>>
>> My preference is definitely (2), though I'm sorry for not bringing this 
>> up earlier when the issue was created.
>>
>> The original issue: https://code.djangoproject.com/ticket/25089
>> Respective PR: https://github.com/django/django/pull/5073
>>
>> Cheers,
>>
>> /Markus
>>
>> On Thursday, July 9, 2015 at 6:13:18 PM UTC+10, Alex Becker wrote:
>>>
>>> Hi Erik,
>>>
>>> I've written such a patch, which also fixes an html escape bug and adds 
>>> validation to the auth management commands.
>>> The 

Re: @csrf_protect annoying on django.contrib.auth.views.login

[Wim Feijen]

Hi,

We are experiencing the same problem when a user changes his language. We 
are using a post form for that, see: https://roominreturn.nl . 

1. What is annoying is that the csrf Forbidden page is a yellow page and is 
shown to the end user. We would never want to confront a visitor with a 
yellow Forbidden page with techy remarks. Our default 400-page would be ok 
though.
2. Actually, I am not that handy with js and we don't understand Collin's 
solution. How do we refresh the csrf-token? Implementing the code literally 
gives csrf-errors.

For my first point, should I make a ticket for that? What I would really 
want is that I know about the error and that data is sent to me, so I can 
act on it.
For the second point, any help is appreciated. 

Regards, Wim  

On Thursday, 2 July 2015 17:09:12 UTC+2, md...@pdx.edu wrote:
>
> I was not aware of that kind of attack. It's pretty clever.
>
> Thanks for the info and the workaround JS.
>
> On Wednesday, July 1, 2015 at 4:29:32 PM UTC-7, Collin Anderson wrote:
>>
>> Hi,
>>
>> This is the best reason I could find:
>>
>> http://security.stackexchange.com/questions/62769/must-login-and-logout-action-have-csrf-protection
>>
>> One thing that's going on here is that the csrftoken changes every time 
>> someone logs in, so the old login page now has a stale token. The changing 
>> csrf token has bitten me a bunch of times. I've gotten around it by using 
>> javascript to correct the token when submitting the form.
>>
>> $(document).on('submit', 'form[method=post]', function() { 
>>   $(this.csrfmiddlewaretoken).val(document.cookie.match(
>> 'csrftoken=([a-zA-Z0-9]{32})')[1])
>> })
>>
>> Collin
>>
>> On Wednesday, July 1, 2015 at 7:13:42 PM UTC-4, md...@pdx.edu wrote:
>>>
>>> Is there a reason django.contrib.auth.views.login should be decorated 
>>> with csrf_protect? It results in annoying behavior, in the following 
>>> scenario:
>>>
>>> In a browser window (Window1), go to the login page.
>>> In another browser window (Window2), go to the login page, and actually 
>>> login, then logout.
>>> Back in Window1, fill in your credentials, and try to login. You get a 
>>> 403.
>>>
>>> It seems like django.contrib.auth.views.login should be decorated with 
>>> csrf_exempt instead. Are there any major security implications?
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To 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/a5d79e02-ca6e-47ac-a1da-bc220419a230%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Idea/request for help: Django Developers Community Survey

[Wim Feijen]

Hi,

"How often would you like to see new major version of Django released?"
currently lists three options, which are close to one another. I would like 
to have: 12 months, as well as an open option. Is it an idea to add those? 
Detailed release schedules are not necessary, in my opinion.

"I follow Django development through:"
I would like to add "Newsletter" as an option. Lincoln Loop has a really 
nice newsletter I can recommend. 

Best regards,

Wim



On Sunday, 26 April 2015 08:34:15 UTC+2, Shai Berger wrote:
>
> Hi, 
>
> On Saturday 25 April 2015 15:29:30 Tim Graham wrote: 
> > Aymeric and I put together a draft: 
> > 
> > 
> https://docs.google.com/forms/d/1Owv-Y_beohyCm9o2xPamdBnvjreNYoWai3rDloKZxW 
> > w/viewform 
> > 
> > All questions are optional so you can just click through it to view the 
> > questions. We'll probably clear any responses before its finalized 
> anyway. 
> > 
> > Let us know if you think we should make any additions or changes. 
> > 
>
> This looks great, thanks for putting it together. There are only a few 
> things 
> I'd like to add. 
>
> First of all, a question I find interesting about the general use pattern: 
> "Do 
> you use Django mainly for one big project, or many small ones?" I'm not 
> sure 
> what's the best way to phrase it, but I think it may be important for 
> interpreting other answers (e.g. larger projects will probably tend to 
> move 
> slower w.r.t releases, will tend to use more contrib and 3rd-party apps, 
> etc). 
>
> In "components": Request processing (URLs, middleware, view decorators). 
> Also, while not a "component" per se, Django's documentation is often 
> cited as 
> a valuable resource, and a lot of effort goes into it; I'm not sure adding 
> it 
> as a component adds value, but perhaps we should ask about topic guides 
> vs. 
> reference or something of the sort. 
>  
> In the question about "contrib" apps, should we include the removed apps 
> (comments, markup, formtools, localflavor)? 
>
> In the list of 3rd-party backends: I'm not sure what are the criteria for 
> being in this list; two other 3rd-patyr backends I'm aware of are django- 
> pyodbc-azure (which I've used) and the proprietary mxODBC-django. 
>
> Again, thanks for the initiative, 
>
> Shai. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To 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/f4a58426-bdf8-47b4-9077-befc243c828b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Two phase cleaning of models/forms

[Wim Feijen]

Great proposal and I'd love it on forms. I'm not sure about models, though. 
I always use forms for sanitization. 

On Wednesday, 25 March 2015 10:37:43 UTC+1, guettli wrote:
>
> Up to now the validation/cleaning of a attribute can not access the 
> value of an other attribute. 
>
> The work around is to override the clean() method of the form/model. 
>
> A team mate and I talked about it, and we asked ourself, if 
> a two phase cleaning would help here. 
>
> Our idea: 
>
>   - The first clean phase works like the current implementation 
>
>   - The second clean phase is optional and does nothing except the user 
> implements it. 
>
>   - In the second clean phase your are allowed to peek into 
> the results of the first clean phase. 
> The clean method for the second phase would need to get the other 
> values passed in. 
>
>
> I would like to have this on model level, not only for forms. 
>
> Example: 
>
> class Issue(models.Model): 
>  state=models.CharField(choices=[('in_progress', 'In progress'), 
> ('wait_until_due_date', 'Wait until due date')]) 
>  due_date=models.DateField(null=True) 
>
>
> We want to implement this constraint: 
>
>   - due date must be set, if the state is "wait_until_due_date". 
>   - due date must not be set, if state is different from 
> "wait_until_due_date". 
>
> We know that we can use the clean() method of the model, but a field based 
> solution would 
> be more preferred. 
>
> class Issue(models.Model): 
>  state = models.CharField(choices=[('in_progress', 'In progress'), 
> ('wait_until_due_date', 'Wait until due date')]) 
>  due_date = models.DateField(null=True, 
> validators2=[check_state_and_due_date_match]) 
>
> def check_state_and_due_date_match(due_date, all_fields): 
>  state = all_fields['state'] 
>  if due_date: 
>  if state != 'wait_until_due_date': 
>  raise ValidationError('If due date is set, state must be 
> "wait_until_due_date"') 
>  return 
>  if  state != 'wait_until_due_date': 
>  raise  ValidationError('If no due date is set, state must be 
> "wait_until_due_date") 
>
>
> Open questions: I am unsure if this should be used only for validation, or 
> if it should be possible 
> to alter values, too. 
>
> What do you think? 
>
> Other solutions or improvements? 
>
> Regards, 
>Thomas Güttler 
>
>
>
> -- 
> Thomas Güttler 
> http://thomas-guettler.de/ 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To 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/e499191b-1b18-4c08-b097-48b689ae585c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: improving debug logging in development

[Wim Feijen]

This may sound stupid, but I actually use Logbook for logging because I 
find it easy to use.

On Monday, 23 March 2015 18:48:26 UTC+1, Tim Graham wrote:
>
> The alternative to a new setting would be to revert the "merging" behavior 
> of the django.utils.log.DEFAULT_LOGGING and settings.LOGGING entirely. This 
> original design was proposed by Claude in 
> https://code.djangoproject.com/ticket/18993#comment:7, but now we realize 
> disable_existing_loggers=True doesn't work as expected in that proposal. 
> I also find that writing a nice configuration that uses 
> disable_existing_loggers=False and that merges nicely with Django's 
> defaults to be difficult (for example, in trying to output all log entries 
> to the console, some as simple as the config below [1] won't work because 
> Django's DEFAULT_LOGGING has handlers for 'django.request' and 
> 'django.security' which don't propagate their entries (I couldn't tell the 
> reason for this from 
> https://github.com/django/django/commit/f0f327bbfe1caae6d11fbe20a3b5b96eed1704cf#diff-246800ac266982b8ad12f505352a662eR63
> )
>
> I would like to ask if anyone who is using settings.LOGGING could share 
> their config so we can get a sense of different use cases?
>
> [1] An attempt to write a LOGGING config that outputs all entires to 
> stdout, but doesn't entirely work as stated above.
>
> LOGGING = {
> 'version': 1,
> 'handlers': {
> 'console': {
> 'level': 'DEBUG',
> 'class': 'logging.StreamHandler',
> },  
> },
> # A catch-all root logger.
> 'root': {
> 'handlers': ['console'],
> 'level': 'DEBUG',
> },
> }
>
> On Monday, March 23, 2015 at 12:31:06 PM UTC-4, Carl Meyer wrote:
>>
>> On 03/22/2015 08:23 PM, Carl Meyer wrote: 
>> > The first, more complex and more important question is: how do we fix 
>> > Django's logging config process to be less broken, so that the best 
>> > advice for getting it to do what you what isn't "disable Django's 
>> > interference entirely and do it yourself."? I don't have a 
>> > fully-packaged solution ready to propose here; someone will need to dig 
>> > into it. Probably the biggest sticking point to get around will be 
>> > backwards compatibility. 
>> > 
>> > I'm pretty sure that a good solution will include an optional way to 
>> > prevent Django from ever installing its default logging config in the 
>> > first place, since it seems there's no way to tell logging to "clear 
>> out 
>> > everything and start fresh" once some configuration has been set. 
>> > 
>> > And I think it will also mean that we stop ever recommending the use of 
>> > "disable_existing_loggers" (and probably even include a callout in our 
>> > docs warning users against it). It seems that 
>> "disable_existing_loggers" 
>> > is a bad feature with surprising behavior, and our current docs were 
>> > written based on a misunderstanding of what it does. 
>>
>> After giving this a bit more thought, I think at least the first step of 
>> a better solution may not be too hard, and could be integrated 
>> immediately along with the doc changes. 
>>
>> The problem is that the current system always installs the default 
>> logging config, and expects that you can use `disable_existing_loggers: 
>> True` to undo that if you want, but `disable_existing_loggers: True` 
>> doesn't do the right thing at all. So really we just need a way to skip 
>> installing Django's default logging config, if you don't want it. I 
>> think the simplest solution is to just add a `LOGGING_SKIP_DEFAULTS` 
>> setting which can be set to `True` to prevent Django from ever 
>> installing its default logging config. Aside from that, the rest of the 
>> `LOGGING_CONFIG/LOGGING` system is functional and fine as is, I think. 
>>
>> The harder problem is figuring out how to have new projects default to 
>> good in-development console logging in DEBUG mode, without breaking 
>> back-compat for older projects. But I don't think we should hold up 
>> incremental improvement while waiting for a solution to that -- having a 
>> proper way to bypass Django's default logging, and fixing our 
>> documentation to be accurate, would be a big step forward. 
>>
>> Carl 
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To 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/677e8b67-286e-4533-b0b1-b420e5652c4a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Psycopg2 version support

[Wim Feijen]

Hi, 

I am definitely in favor of just one version requirement in order not to 
complicate things. So then the minimum version would be either 2.5; or 
2.4.5 and write special cases in contrib.postgres to deal with that.

Regards, Wim

On Monday, 16 February 2015 16:04:50 UTC+1, Tim Graham wrote:
>
> How about this plan:
> * Document 2.4.3 as the minimum if you don't want to use contrib.postgres
> * Recommend 2.5+ and document it as the minimum to use contrib.postgres
> * Require 2.5+ for Django's test suite to avoid having to add conditional 
> imports/test skipping.
>
> On Monday, February 16, 2015 at 9:20:51 AM UTC-5, Gert Van Gool wrote:
>>
>> In CentOS 6, you can't run Django 1.8 anyway. It ships Python 2.6.
>>
>> So if you want to run Django 1.8 on CentOS 6, you need to compile Python 
>> yourself. In that case I don't think they'll complain about having to build 
>> psycopg2 separately as well.
>>
>> In the RHEL/CentOS universe, anyone who wants to run Django 1.8 needs 
>> either SCL's (software collections that are installed next to system 
>> binaries) or has access to psycopg2 2.5.
>>
>> So my point for CentOS/RHEL 6 can be ignored.
>>
>> -- Gert
>>
>> Mobile: +32 498725202
>> Twitter: @gvangool 
>> Web: http://gertvangool.be
>>
>> On Mon, Feb 16, 2015 at 3:10 PM, Thomas Stephenson  
>> wrote:
>>
>>> My mistake, sorry.
>>>
>>> So, to get the conversation back on track, is `2.4.5` acceptable as the 
>>> minimum version, even if users who
>>>
>>> - use CentOS 6
>>> - install dependencies via the OS package manager
>>> - don't have sudo/root
>>> - can't request the sysadmin to install dev packages; and
>>> - keep django at the latest version
>>>
>>> don't have a valid upgrade path?
>>>
>>> Thomas
>>>
>>>
>>> On Tuesday, February 17, 2015 at 12:36:11 AM UTC+11, Florian Apolloner 
>>> wrote:

 Not exactly, cause installing psycopg2 via the OS package manager 
 should __not__ require dev packages at all.

 On Monday, February 16, 2015 at 11:57:01 AM UTC+1, Thomas Stephenson 
 wrote:
>
> > Installing psycopg2 does require development tools, while Django 
> does not
>
> Installing psycopg2 2.0.0 requires exactly the same `postgres-*-dev` 
> libraries that 2.5 does as far as I know. If it is possible to install 
> psycopg2 via the OS package manager then 2.5 can be installed via pip.
>
> On Monday, February 16, 2015 at 11:18:56 AM UTC+11, Xof wrote:
>>
>>
>> On Feb 15, 2015, at 4:14 PM, Tim Graham  wrote: 
>>
>> > Is there a scenario where you could pip install Django but not pip 
>> install psycopg2? 
>>
>> Installing psycopg2 does require development tools, while Django does 
>> not.  I'm not offering this as a compelling argument for anything, just 
>> an 
>> observation. 
>>
>> -- 
>> -- Christophe Pettus 
>>x...@thebuild.com 
>>
>>  -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to django-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/4efc59f0-0b97-4ed9-bbce-bd1b124ea978%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To 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/ebbc6603-82d9-4bd8-aa4d-b39db66254a8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: User.username max_length 254

[Wim Feijen]

Hi Collin,

I would like that, good idea! 

Wim

On Saturday, 7 February 2015 02:10:02 UTC+1, Collin Anderson wrote:
>
> Hi All,
>
> I was reminded by:
> Allow shadowing of abstract fields 
> https://groups.google.com/d/msg/django-developers/6zUfnElOIks/8uwXji559EsJ
> and https://code.djangoproject.com/ticket/24288 (Custom User Models for 
> small tweaks).
>
> Could we reopen https://code.djangoproject.com/ticket/20846 and increase 
> User.username max_length to 254?
>
> Personally, that's the only thing I've ever needed to change about my User 
> class. I just need it long enough to hold email addresses. I've seen many 
> other people wanting the same thing.
>
> In 1.8 we migrated the length of EmailField from 75 to 254, so it should 
> be almost™ as easy to change the username field.
>
> If needed, we could keep the 30-character limit on UserCreationForm and 
> UserChangeForm for backwards compatibility. The limit in the database is 
> the real killer :) Though, consistency is also nice.
>
> Thanks,
> Collin
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To 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/dbef176f-d643-46fb-853a-5cbc070c9e8a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Storage engine aliases?

[Wim Feijen]

Hi Jannis, although much work, I would find that brilliant.

On Thursday, 2 October 2014 08:47:13 UTC+2, Jannis Leidel wrote:
>
>
> "If something like that were be tried I would also recommend to fix the 
> ambiguity with regard to “media” and “static” by renaming the first to 
> “uploads”." 
>
> Jannis 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To 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/0c0f15cf-22e8-4266-9696-d053388985dd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: The greatest proposal yet: rename this damn group

[Wim Feijen]

Hi Russell,

Is this an issue we should solve? 

Because I believe technology can help here. For example, by posing a 
question when a user is creating a ticket. Ask if it deals with security; 
then present two clear buttons: "Report a security issue" or "Report 
something else". (There might be better wordings). That will probably help 
a lot. 

Don'ts are probably not helpful, f.e. don't think of a yellow lemon.

Wim 

On Wednesday, 10 September 2014 01:56:43 UTC+2, Russell Keith-Magee wrote:
>
>
> On Tue, Sep 9, 2014 at 11:40 PM, Thomas Leo  > wrote:
>
>> +1 for @Wim Feijen's rewording but...
>>
>> I think the wording of the Group description isn't the issue, my guess is
>> that people who make the mistake of asking django-user's questions in the
>> django-developers mailing list didn't read the description to begin with.
>>
>> > They are almost all from people whose first language is clearly not 
>> English,
>>
>> I haven't been following this mailing list for a particularly long time, 
>> but I
>> can recall a number of cases where users were simply noobies looking for 
>> help,
>> and didn't reading the description of this mailing list before asking 
>> their
>> question.  Whether they are native English speakers or not, clearer 
>> wording
>> would mitigate the issue for everyone.
>>
>
> Let me dispel this illusion for you.
>
> If you go to Django's new ticket page:
>
> https://code.djangoproject.com/newticket
>  
> You are greeted with the following text:
>
> Please read this first:
> Please don't report security issues here! Contact 
> secu...@djangoproject.com  instead.
>
> This text is in bold, and is a hyperlink to a page describing Django's 
> security processes in detail.
>
> And yet, every couple of months, we get someone opening a ticket that 
> starts "I think I've found a security/DDOS issue in Django". The report 
> will be written in reasonably good english, so it isn't a language barrier 
> issue.
>
> This is what I meant when I said you can't solve a social problem with 
> technology. Yes, we might be able to improve the number of errors by 
> improving the text, but at some level, it doesn't matter how large you make 
> the "PLEASE DON'T PUSH THIS BUTTON" sign, someone is going to push the 
> button. It is folly to believe that the problem is that we just haven't 
> found the right descriptive text.
>
> 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/98e09e4b-7a8d-46e2-83e4-7b2d2ed10854%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: The greatest proposal yet: rename this damn group

[Wim Feijen]

Hi Russell,

Did you manage to speak to the technical board about renaming the group?

Wim

On Tuesday, 9 September 2014 03:49:21 UTC+2, Russell Keith-Magee wrote:
>
>
> On Mon, Sep 8, 2014 at 11:24 PM, Carl Meyer  > wrote:
>
>> On 09/08/2014 08:56 AM, Aymeric Augustin wrote:
>> > 2014-09-08 16:21 GMT+02:00 Thomas Leo > > >:
>> >
>> > +1 for django-contributors
>> >
>> >
>> > That would be "Django Contributors" since we're talking about changing
>> > the display name of the group, not its email address.
>> >
>> > It's a good proposal.
>>
>> I agree. I don't see any reason not to try this.
>>
>> Who has access to the Google Groups admin?
>>
>
> I do. 
>
> As a matter of formality, I'd like to put this through the technical board 
> so that it isn't just a fiat decision by the handful of people motivated to 
> participate in this discussion.
>
> Russ %-)
>  
>

-- 
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/a8c35fa3-20cb-4eb5-98bd-9791332630d5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Loading timezone naive data into your test database with USE_TZ = True

[Wim Feijen]

Hi Robert, 

Timezones confuse me, maybe Aymeric can answer this one if he has time?

Off topic, your question might be a better fit for the django-users mailing 
list, but perhaps you posted to django-developers intentionally, because 
you are thinking of a bug report?

Wim


On Wednesday, 17 September 2014 01:54:13 UTC+2, Robert Rollins wrote:
>
> I have a legacy database from which my Django application must migrate 
> data into a Django database. The relevant dates fields are actually 
> TIMESTAMP columns in the database, but something (perhaps Django, or 
> python's MySQL driver?) loads these columns as timezone naive datetime 
> objects, rather than integers. So I wrote my migration code under the 
> assumption that the dates coming out of the legacy database are timezone 
> naive.
>
> Unfortunately, now that I'm trying to write tests for this migrator, I 
> can't find any way to load timezone naive datetimes into my test legacy 
> database. I can't use integer timestamps, because the DateTimeField doesn't 
> accept that kind of input (I get a JSON serialization error when I try), so 
> I'm using datetime strings like this: "2014-08-01T00:00:00" in my fixture. 
> But 
> regardless of whether or not I include a UTC offset in the string, the 
> datetime objects that come out of the database during my tests are somehow 
> timezone aware. This causes my code to crash because it calls make_aware(), 
> which throws ValueError('Not naive datetime (tzinfo is already set)'). 
>
> It seems like having USE_TZ = True is forcibly making my fixture dates 
> timezone aware, which I don't want. But USE_TZ will be True during the 
> actual migration, so I can't just turn it off during the tests. So how can 
> I load timezone naive dates into my test database?
>

-- 
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/f25965c5-88e9-4f4c-9433-e996ef50611a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Should reverse() return a Unicode string?

[Wim Feijen]

Please do. :) 

- Wim

On Thursday, 18 September 2014 22:01:21 UTC+2, Jon Dufresne wrote:
>
> What do you think? If others agree, I can file a bug and create a pull 
> request to fix this. 
>  
>

-- 
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/0ed81719-e0f4-4c22-a3c0-2fdcacc9f05b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Unifying locale time formats

[Wim Feijen]

Hi everyone,

I wonder if we should unify the time format which is sometimes displayed as 
G:i and sometimes as H:i, where hours are displayed with or without a 
leading zero. For the same reasons as stated above I think it nicer to be 
consistent here. I would prefer G:i (hour without leading zero). 

Or is that a problem in some languages?

@Malte Your pull request looks good to me! Can you add a line to the 
release notes? Then I will mark it as Ready for checkin.

Wim


On Thursday, 11 September 2014 14:48:49 UTC+2, Malte wrote:
>
> Cheers, Collin! That worked
>
> On Thursday, September 11, 2014 2:17:24 PM UTC+2, Collin Anderson wrote:
>>
>> If you did "git add .", you should be fine without the -a flag, just 
>> use git commit -m “Removed seconds from all locales.”
>>
>

-- 
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/bf8387ac-f994-4395-b200-5d6e170c7771%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Unifying locale time formats

[Wim Feijen]

Hi Malte, 

Sounds like a good idea to remove the seconds. Aymeric says the same.

Can you open a ticket and if you want create a pull request?

Wim

On Wednesday, 10 September 2014 18:26:11 UTC+2, Malte wrote:
>
> Hi Aymeric,
>
> Yes, I agree. And backwards compatibility is a concern I share. But as it 
> is right now, time output is not very useful if it includes seconds.
>
> Few people will state:
> "Posted on 10.9.2014 20:45:29".
>
>

-- 
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/02006f86-fc27-4f41-a861-e41c883264ad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: The greatest proposal yet: rename this damn group

[Wim Feijen]

Hi Daniel,

An idea we spoke about earlier in this tread is to rename the group to 
Django Contributors, and the slug (and url) to remain django-developers in 
order to preserve links.

Wim

On Tuesday, 9 September 2014 22:04:30 UTC+2, Daniel Pyrathon wrote:
>
> Hi,
>
> I think that changing the name the community on google will create many 
> broken links, this will be a huge loss.
> What we can do instead, is create 2 domains (or subdomains) such as 
> core-development.djangoproject.com and community.djangoproject.com that 
> will serve as the official URLs to publicise on blogs, official sites and 
> IRC. These ULRs will redirect to the related google forums.
>
> Dan
>
> On Tuesday, September 9, 2014, Erik Romijn  > wrote:
>
>> I think it would also be a great improvement if we all adopted a standard 
>> response for these kind of mails - because no matter what we do, some will 
>> still end up here.
>>
>> Almost entirely based on Daniele's previous responses, how about we use:
>>
>> > The best place to get answers to your questions is the django-users 
>> email list,  - the web interface is <
>> https://groups.google.com/forum/#!forum/django-users>.
>> >
>> > The list you've posted to is django-developers, an email list is for 
>> the discussion of the development of Django itself.
>> >
>> > You might also find helpful the #django IRC channel on irc.freenode.net
>> .
>> >
>> > I hope that helps,
>>
>> This focuses first on helping them get to the right place, with easily 
>> readable language, and then explains their error in a friendly way. In the 
>> past, we've occasionally sent somewhat more harsh replies, focusing more on 
>> how they did something wrong. Although I'm sure such replies were 
>> absolutely sent with the best intentions, it's not a pleasant first 
>> experience.
>>
>> Not sure what the best place is to keep this template easily accessible 
>> for anyone though. The wiki might be the most suitable.
>>
>> Erik
>>
>> --
>> 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/07EC2CEB-A0AC-4624-874C-6D8FBD9D594C%40solidlinks.nl
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> -- 
> *
>
> PirosB3
>
> https://github.com/PirosB3
>
>

-- 
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/8ce347c2-79f0-4615-a684-9031fabaa48c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: The greatest proposal yet: rename this damn group

[Wim Feijen]

Hi,

Good thing to change the group name. For the description, another wording 
could be:

Discussion group for contributing to the Django source code and 
documentation. Here we discuss new features and updates of the Django 
project. 

Wim


On Tuesday, 9 September 2014 10:52:09 UTC+2, Robert Grant wrote:
>
> Totally agree Daniele. I don't know how other people experience the group, 
> but I actually didn't see the email address, and didn't even look at the 
> URL. If we can find where the email is exposed (say on a website) and 
> change things to hide it as much as possible, e.g.: 
>
> Instead of : Email the Django Contributors group here: 
> django-d...@googlegroups.com 
> Say : Email the Django Contributors group .
>
> That might help. Maybe a note in the description to say that for 
> historical reasons, if you want to email a new topic to the group the email 
> address is django-d...@googlegroups.com ?
>
> On Tuesday, 9 September 2014 10:03:45 UTC+2, Daniele Procida wrote:
>>
>> On Tue, Sep 9, 2014, Russell Keith-Magee  wrote: 
>>
>> >As a matter of formality, I'd like to put this through the technical 
>> board 
>> >so that it isn't just a fiat decision by the handful of people motivated 
>> to 
>> >participate in this discussion. 
>>
>> By the way, there are three related pieces of information (in Manage > 
>> Information > General information): 
>>
>> Group name: Django developers 
>>
>> Group email address: django-developers (can't be changed) 
>>
>> Group description: Discussion group for Django developers. This group is 
>> used for discussion of developing Django itself, not user questions; Please 
>> use django-users for issues regarding using the framework, questions for 
>> the Django user community outreach, etc. 
>>
>>
>> The description's the easy one, but I don't think it's going to make a 
>> huge amount of difference. I doubt it's what catches people's attention. 
>> I'd suggest something shorter like: 
>>
>> Discussion group for the development of Django and contribution to 
>> the 
>> project. For questions about and help with Django, please use 
>> django-users. 
>>
>> The group name is the problematic one. If it matches the email address; 
>> it's misleading; if it doesn't, it's confusing. 
>>
>> 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/bf7ba047-d45f-49f1-9a16-ac4b54423894%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: The greatest proposal yet: rename this damn group

[Wim Feijen]

Or Django contributors?

On Friday, 5 September 2014 10:20:51 UTC+2, Tom Christie wrote:
>
> Options?...
>
> * Django core
> * Django core development
>
> For comparison the Rails folks have "Ruby on Rails: Talk 
> " and "Ruby on 
> Rails: Core "
>
>  - Tom
>
> On Friday, 5 September 2014 08:58:19 UTC+1, Robert Grant wrote:
>>
>> I am one of the happy few who read the line about what this group is for 
>> before I started posting. 
>>
>> However, that line, and the endless supply of people who think this is 
>> for Django developers (see also: Java developers are generally considered 
>> to be people* who develop in Java, not who develop Java), might be symptoms 
>> of the fact that this group has a funny name for something that is both 
>> *developed* and *developed in*.
>>
>> Can we rename it 
>> ?
>>  
>> :) Some semi-serious suggestions (because I can't think of an obvious 
>> alternative) :
>>
>> Django Masters
>> Django Private
>> Django Debate
>> Django Internals
>> Aymeric And Friends
>>
>>
>>
>>
>>
>> * Yes, they're still people.
>>
>

-- 
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/48073b9c-6193-4b93-b2ea-93c927ef0d4e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Requiring GitHub login for actions on Trac

[Wim Feijen]

Nice :)

On Saturday, 9 August 2014 21:22:07 UTC+2, Aymeric Augustin wrote:
 

> > Uhmm... but I see you moved forward and already did it? 
>
> Yes, I did. 
>
> -- 
> 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/0dae599b-afcf-4a41-8c2b-75fead33754b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Requiring GitHub login for actions on Trac

[Wim Feijen]

>
> Hi Aymeric,


Thanks for your proposal and your work on this! 

I am in favour of *adding* github as an authentication tool. We would 
benefit immensily for making it easier for new people to log in and 
contribute. Would it be possible to add that to Trac, so people who have 
moral constraints against using github, could use the trac login?

In practice, almost all my contributions are made anonymous because that is 
faster for me, and I would definitely benefit from having a github oauth.

Uhmm... but I see you moved forward and already did it?

Wim 

-- 
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/e166ce09-e5db-470e-8535-943977dd248e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Regression in ValidationError in 1.7

[Wim Feijen]

Hi Russ,

Good point and thanks for testing! For me, this should definitely be listed 
in the release notes and we should provide people a hint of how to fix it 
as well.

IMO we do not need to support a non-documented feature.

Wim



On Friday, 27 June 2014 07:58:27 UTC+2, Russell Keith-Magee wrote:
>
> Hi all,
>
> I've just done some testing of 1.7 against my 'day job' code base. The 
> good news is that everything has pretty much worked out of the box without 
> any problems.
>
> However, I did find one regression, which I've opened as #22915 [1]. Full 
> details are on the ticket; the short version is that the API for 
> Validation.update_error_dict() has changed in very subtle way. The change 
> was introduced by [2], which introduced Form.add_error() [3].
>
> The catch here is that ValidationError is definitely stable API, but 
> update_error_dict isn't documented - so it isn't clear to me whether this 
> should be considered a regression in a stable API that must be fixed, or a 
> "backwards compatibility gotcha" that is worth some documentation, but not 
> a code change.
>
> I caught the problem running the test suite for my "day job app". I'm 
> doing some moderately complex form error handling, and in the `clean()` 
> method for a form, I'm raising an error against a specific field on the 
> field. This appears to be the exact use case that the `Form.add_error()` 
> API is designed to satisfy, so the regression has been introduced by adding 
> a formal API for something that people (including myself) would have been 
> doing previously in an ad-hoc fashion. 
>
> The question here is whether we need to continue to support the ad-hoc 
> usage in a backwards compatible way.
>
> Thoughts?
>
> Yours,
> Russ Magee %-)
>
> [1] https://code.djangoproject.com/ticket/22915
> [2] 
> https://github.com/django/django/commit/f563c339ca2eed81706ab17726c79a6f00d7c553
> [3] https://code.djangoproject.com/ticket/20867
>

-- 
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/841bccb0-3251-47e1-bc53-27413d052506%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add support for get_or_none?

[Wim Feijen]

Hi Cal,

When we proposed to add get_or_none() , we actually ended up adding a 
first() -method. The primary motives were to have a clearer name and to 
stay in line with other existing api's.

In my opinion, get_or_none is too much a duplicate of first and I am 
therefore -1 of it being added. 

For those interested, I will copy the message of BDFL Jacob here:

Hi! 

After thinking a bit, I'm +1 on the idea, and I think 
`Queryset.first()` is the right name (which implies we should probably 
have a `last()` for completion). 

This mirrors the name used by a few other ORM/collection APIs that I 
think have really nice APIS: 

* SQLalchemy 
(http://docs.sqlalchemy.org/en/rel_0_7/orm/query.html#sqlalchemy.orm.query.Query.first)
 
* Storm 
(http://people.canonical.com/~therve/storm/storm.store.ResultSet.html#first) 
* Backbone (http://backbonejs.org/#Collection-Underscore-Methods / 
http://documentcloud.github.com/underscore/#first) 

If someone produces a patch I'll review it and commit it. 

Jacob 

This was written as a response to Anssi's message:

For the record, I still do like this idea, specifically .get_or_none().

It seems there is significant support for this idea. I do think this method 
is Pythonic. There are cases where no match from get() isn't exceptional, 
and in such cases try-except just feels wrong.

The counter argument is that this is API bloat, and this will set an 
example for more API bloat.

In the end this is a decision with almost no technical considerations and a 
lot of "good taste" considerations. So, this seems like BDFL area.

If there are no signs from BDFL that .get_or_none() is acceptable, then 
lets bury this one. If it is acceptable, then I am willing to do all the 
work to get this committed.

 - Anssi

The whole thread is here:
https://groups.google.com/forum/#!searchin/django-developers/get_or_none$20jacob$20first/django-developers/3RwDxWKPZ_A/KNzxgP8L-V0J

Regards, Wim

On Wednesday, 26 March 2014 13:19:47 UTC+1, Cal Leeming [Simplicity Media 
Ltd] wrote:
>
>
>
>
> On Tue, Mar 25, 2014 at 11:40 PM, Russell Keith-Magee <
> rus...@keith-magee.com > wrote:
>
>>
>> On Thu, Mar 20, 2014 at 9:31 PM, Florian Apolloner 
>> > > wrote:
>>
>>> On Thursday, March 20, 2014 2:01:25 PM UTC+1, Cal Leeming [Simplicity 
>>> Media Ltd] wrote:

 I'll give it a couple more days for a BDFL to gives the thumbs up/down.

>>>  
>>> Well, we don't have BDFLs anymore and Shai already said he is -0 on it, 
>>> count me in with a relatively strong -0 too. I'd be a bit more open to it 
>>> if you could a better name. That said I generally agree with Shai about the 
>>> validation, eg this should be handled by the database constraints already 
>>> -- otherwise selecting via get doesn't make much sense imo.
>>>
>>  
>> Count me as a -0 as well. I simply don't see the problem with catching 
>> exceptions. Changing the name doesn't modify my objections.
>>
>
> Then why did first() [1] get added? The only difference is that first() 
> adds a reference to [0], but it still saves the equal amount of code and is 
> still there for the same reasons of convenience, no?
>
> [1] 
> https://docs.djangoproject.com/en/dev/ref/models/querysets/#django.db.models.query.QuerySet.first
>  
>
>>
>> I'm probably a true neutral 0 on a django.shortcuts method mirroring 
>> get_object_or_404 (which, BTW, is what the way-back-in-2007 thread was 
>> proposing). I still don't see the point, but at least it's in a shortcuts 
>> module, and clearly labelled as such, not a method on a manager duplicating 
>> existing functionality.
>>
>> 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-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/CAJxq84_rYfpfSGicAKFDrLdtTKW9q1tr%2BM03xXx_qRCi4usTEw%40mail.gmail.com
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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/1ef75fc6-90c2-4d70-9aa0-d2c1cac25c49%40googlegroups.com.
For more options, visit 

Re: #20824 - Email-based auth contrib module; some help required

[Wim Feijen]

Hi Tilman,

Thanks for bringing this up. I lowercase my e-mail addresses every time - 
and when I forget I am wading through a pile of shit. (excusez le mot)

Your solution looks neater, because it maintains user input. I have had 
users who used stefan.joos...@gmail.com once and later on: 
stefan.joos...@gmail.com to log in. (not using his actual name)

In addition, we would need a proper form error when we try to create a user 
having a case-insensitive duplicate e-mail.

Wim 


On Wednesday, 26 February 2014 09:39:53 UTC, Tilman Koschnick wrote:
>
> Hi Russell, 
>
> On Wed, 2014-02-26 at 15:33 +0800, Russell Keith-Magee wrote: 
>
> > The idea here is that we just ship a normal auth.User, but with email 
> > identification rather than username. 
>
> I have just implemented an email based User model as well, and was 
> wondering about case sensitivity in the local part of the address. 
>
> Most if not all final MTAs treat email addresses as case insensitive, 
> e.g. User.Name@... ist handled the same way as user.name@..., and some 
> users might not take care or notice of which form they used during 
> registration. A common recommendation is to preserve but subsequently 
> ignore case. 
>
> I am handling this by using iexact lookups for users: 
>
> def get_by_natural_key(self, username): 
> return self.get(email__iexact=username) 
>
> In the database, uniqueness is enforced by an expression index: 
>
> CREATE UNIQUE INDEX app_user_email_key ON app_user (upper(email)) 
>
> I am not sure if DBMSs other than PostgreSQL support expression indexes; 
> either way, there is not Django support (yet). 
>
> I don't know if this is of only theoretical concern, or a real world 
> issue - maybe others using email based users could share their 
> experience (my project is not deployed yet). 
>
> Kind regards, Til 
>
>
>

-- 
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/fab46e55-7dad-4d7d-be55-ea13b606431d%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

allow list_display in admin to traverse onetoonfields and foreign key relations

[Wim Feijen]

Hello,

Right now I have a School model containing a OneToOne-relation to User.

In the admin, in search_fields, I can use double underscores to search in 
related fields, for example:
search_fields = ('place__name', 'school__name')

But in list_display, I can't. For example,
list_display = ['school', 'school__user', 'place', ]
gives an error.

I find this totally confusing. More people do.

A ticket has been made six years ago and was eventually closed as won't 
fix. Currently, the proposed solution is to write a custom method or 
callable. I'd like to raise a discussion to reopen that ticket.

For reference, see:
https://code.djangoproject.com/ticket/5863
https://groups.google.com/forum/#!topic/django-developers/eQSEv74bQh8

My arguments to allow such a syntax are:

1. allowing 'school__user' in list_display is consistent with the behaviour 
of search_fields, list_filter in the admin, and get() and filter() query 
syntax in general.
2. it saves many people duplicating two to four lines of custom code, and 
in my opinion, allows for a more concise yet extremely easy to understand 
notation.
3. ideally, a solution would use select_related in order to save database 
queries and thus be longer than two to four lines of code.
4. the need is common, and in onetoonefields specifically. Many people have 
expressed their interest in this feature, and a core developer initially 
accepted it.
5. a long time has passed since then and our policy of accepting tickets 
has changed.

Thanks for reading! I'd love to hear your response.

Regards, Wim

-- 
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/e384693f-72a9-4aba-bcaa-e0590dcfcbbe%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: ValidationError for fields

[Wim Feijen]

Hi Loic,

That's nice! It looks very powerful, saving lines of code and being more 
clear. 

How about:

form.add_errors(dictionary)

? Because then we can either add one or more errors at the same time.

Wim


On Wednesday, 21 August 2013 02:31:07 UTC+2, Simon Litchfield wrote:
>
> An improvement for sure. Any reason it can't be a little more pythonic, ie 
> using optional kwargs etc?
>
> My only concern is in having two ways of achieving the same thing. If the 
> latter is simpler and more flexible, does this place our entire 
> ValidationError approach to handling form and model errors in question? 
> Hmmm. Maybe we can come back to that later :-/
>
>
> On Tuesday, 20 August 2013 14:11:44 UTC+10, Loic Bistuer wrote:
>>
>> There is a ticket with a PR to address the issue of targeting specific 
>> fields when raising errors; I'm awaiting feedback on what should be the 
>> documented API. 
>>
>> https://code.djangoproject.com/ticket/20867. 
>>
>> This patch enables two patterns: 
>>
>> - Raising ValidationError({'field': 'error'}) from `Form.clean()`. 
>>
>> - Calling Form.add_errors('field', 'error') from anywhere. 
>>
>> The former is actually something that existed for a long time; only it 
>> couldn't be used from `Form.clean()`. This pattern allows targeting 
>> specific fields from the `Model` layer (see #16986). 
>>
>> The later has been proposed by @akaariai and @mjtamlyn, it's easier to 
>> use for the simple cases and it's accessible from outside the form, from a 
>> view for example. 
>>
>> The current patch only documents the dict construct for `ValidationError` 
>> since `Form.add_errors` was a private method in my original patch; should 
>> both be documented or only `Form.add_errors`? 
>>
>> -- 
>> Loic 
>>
>> On Aug 20, 2013, at 7:58 AM, Simon Litchfield  
>> wrote: 
>>
>> > Lack of clean control over field-specific form errors is an issue that 
>> has been raised and discussed many times over the years, but still the 
>> solution seems pretty inadequate. We're even directing people hack around 
>> with _errors and making excuses for it in the documentation. 
>> > 
>> https://docs.djangoproject.com/en/dev/ref/forms/validation/#form-subclasses-and-modifying-field-errors
>>  
>>
>>

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

Proposal: remove triage stage someday/maybe

[Wim Feijen]

Hi,

When triaging tickets I came across the triage stage Someday/Maybe. The 
docs say I shouldn't use it. :) I think they are right. 

For me triaging tickets is all about making a decision. I make a choice 
between either: "yes, good idea", or "no, we definitely don't want that". 
Someday/maybe seems like not a good choice here, because it leaves things 
in the uncertain. 

Therefore, I'd like to propose to remove this triage stage, like we did 
with design decision needed.

Currently, there are 47 tickets marked as someday/maybe. Looking over them, 
it seems to me that:
1. most can be marked as Accepted. A solution may or may not be hard to 
find but we accept that django could improve here.
2. some should actually be marked as won't fix but weren't out of 
hospitality. 

What is your opinion?

Wim

-- 
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: Revisiting multiline tags

[Wim Feijen]

Hi Jacob and Adrian,

Reading this long thread with many +1s makes me think of truncatechars 
which is not a good feeling. 

I wondered if you are using internationalisation? If so have you run into 
the same problems or is it easy to circumvent for you?

Or am I missing something and are all these programmers plainly doing it 
wrong?

Wim

On Monday, 15 July 2013 23:41:25 UTC+2, Jacob Kaplan-Moss wrote:
>
> On Mon, Jul 15, 2013 at 1:34 PM, Daniel Ellis  > wrote:
>
>> Is it considered gauche to revive old topics such as this?  
>
>
> It's not, but my opinion hasn't changed -- I'm still -1, and so's Adrian. 
> So unless you've got something really convincing, an argument that hasn't 
> been presented yet that is totally going to change both of our minds -- 
> it's probably not worth your time.
>
> Jacob
>

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

Proposal: rename django-developers to django-contributors

[Wim Feijen]

Hi all,

Many people post django-users questions to this group by accident. I find 
the name of our group to be misleading: it seems to refer to people who 
develop in django, but actually it is meant for people contributing to 
django.

To limit confusion, my proposal is to rename django-developers to 
django-contributors. 

In addition, maybe django-users can be renamed as well, because the concept 
of a User in django is different from a django programmer.

Regards,

Wim

-- 
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: Ticket #13910: Generator based rendering (streaming) of templates

[Wim Feijen]

Hi Roger,

Probably the best way to get some love is to do a 5 for 1. Did you hear of 
that before?

It means that if you look into five tickets and/or patches from other 
people, that you state here: I did a five for one. In my experience, core 
contributors are very willing to give a hand then. (many explicitly 
promised to do so)

Thanks for your good work so far and good luck,

Wim

On Thursday, 27 June 2013 07:41:14 UTC+2, Roger Barnes wrote:
>
> Hi all,
>
> I picked up on earlier work done for generator based template rendering, 
>> brought it up to master and improved a little on it with tests and a 
>> StreamingTemplateView class.
>>
>> I've created the following pull request for consideration: 
>> https://github.com/django/django/pull/1037
>>
>> Feedback welcome either here, on the pull request, or on the ticket.
>> https://code.djangoproject.com/ticket/13910
>>
>
> I'm hoping to get some love for this ticket and pull request. I got 
> feedback on one problem with it when I first posted that has since been 
> rectified. Any further thoughts?
>
> Cheers,
> - Roger Barnes
>

-- 
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 runfcgi umask: what is it meant to do and why?

[Wim Feijen]

Hi Juan,

Thanks for your detailed examination and report. The best way to proceed is 
definitely to create a ticket in trac: 
https://code.djangoproject.com/newticket . 

Then, if you are willing and like to become a contributor, you can either 
add a patch or create a pull request on github.

Thanks for your work!

Wim

On Sunday, 30 June 2013 18:13:59 UTC+2, gilberto dos santos alves wrote:
>
> yes. i agree. my tests in hostgator.com shared host show this. tests 
> in my ubuntu 12.04 amd64 shows same problem. using django 1.5 and 
> 1.6a, 16b. 
>
> 2013/6/30 Juan Luis Boya : 
> > They talk about there was a os.umask(0) and they created that option in 
> > order to change it. 
> > 
> > But I would like to know then, why was that `os.umask(0)` there in the 
> first 
> > place? What was it purpose? 
> > 
> > On the other hand there is the confusion this option brings. Many people 
> > think the option is intended to set the socket umask. Just in that bug 
> > report there is a user saying "umask=0111 creates a socket with 
> umask...". 
> > Even Django documentation recommends you to use separate users for 
> increased 
> > security and tells you to set umask argument in order for them to 
> > communicate. 
> > 
> > These are wrong! Setting that umask does not only not work if runfcgi is 
> not 
> > daemonized, but also gives write permissions to all files created by 
> Django 
> > to any user in its group (often the web server), potentially breaking 
> > isolation with other applications (i.e. PHP scripts being run as the 
> server 
> > user). 
> > 
> > - Juan Luis 
> > 
> > -- 
> > 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. 
> > 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.

Re: Improving ForeignKeyRawIdWidget (raw_id_fields in admin)

[Wim Feijen]

Hi Richard,

Thanks for your rationale. Sounds like a good feature to me. 

Probably the best way to proceed is to make a ticket at: 
https://code.djangoproject.com/newticket , attach a patch or pull request 
and then we go forward.

Best regards,

Wim

On Wednesday, 12 June 2013 19:33:31 UTC+2, ric...@richard.ward.name wrote:
>
> I think that the usability of ForeignKeyRawIdWidget could be vastly 
> improved if the representation part of the widget (the object name, in 
> bold) were to be updated when a new object gets chosen. I think this could 
> be done relatively easily with a small change introducing little extra 
> complexity.
>
> At present the original representation remains, which is confusing to 
> users and could lead to mistakes being made.
>
> I think this can't be done simply by a 3rd party app without some 
> seriously dirty monkey patching. The only way I can think of I to do it 
> without monkey patching would be to make ajax requests to get the new 
> representation of the chosen object - substantially more awkward both for 
> the developer and the person installing the app.
>
> I appreciate some people will have used ForeignKeyRawIdWidget outside 
> admin and used a custom dismissRelatedLookupPopup function so ideally any 
> change would not break their code. This means that the function signature 
> of dismissRelatedLookupPopup should remain the same (unfortunately, as 
> this would be the most obvious and easiest place to include representation).
>
> My proposal would be for the string representation of the object to be 
> included somewhere in the popup - for example as an html attribute called 
> data-object-representation on the anchor with the onclick handler. If this 
> anchor was also given an id (say choose-object-X where X is the object's 
> pk) then it would be easily accessible to the dismissRelatedLookupPopup, 
> which could extract it and update the representation on the calling page. 
> The  elem containing the representation might also benefit from 
> having a unique id as RelatedObjectLookups.js seems to be written so as 
> not to require jQuery.
>
> Hope that all makes sense. Naturally I'm prepared to write a patch for 
> this assuming it doesn't meet with disapproval.
>
> Thanks,
> Richard
>
> P.S. Hope I'm putting this in the right place, and I couldn't find 
> anything existing on the django issues list, and i got the impression that 
> this list was the place to start with such things.

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Wim Feijen]

Hi Selwin,

Considering "There should be one-- and preferably only one --obvious way to 
do it", I definitely prefer to rely on order_by to do the ordering, not on 
first. 

.order_by('name').first()

is clear and readable in my opinion.

Wim

On Sunday, 12 May 2013 06:55:04 UTC+2, Selwin Ong wrote:
>
> Hi everyone,
>
> I opened a new pull request implementing Shai's suggestions (I didn't 
> overwrite the current branch so we can still compare the two 
> implementations if needed).
>
> I initially modeled "first()" and "last()"'s behaviors to mimic 
> "latest()", but in this new pull request, you can pass multiple field names 
> into "first()" and "last()" so it behaves like "order_by()". It's more 
> flexible and requires less typing, but I wonder if we should just get rid 
> of the optional field arguments and rely on "order_by" for ordering. "There 
> should be one-- and preferably only one --obvious way to do it".
>
> Thoughts?
>
> The new pull request is here: https://github.com/django/django/pull/1056
>
> Best,
> Selwin
>
> On Sunday, May 12, 2013 4:23:33 AM UTC+7, Shai Berger wrote:
>>
>> Hi Selwin, 
>>
>> On Saturday 11 May 2013, Selwin Ong wrote: 
>> > Hi everyone, 
>> > 
>> > I submitted a pull request implementing "first()" and "last()" here: 
>> >  https://github.com/django/django/pull/1054 
>> > 
>> > Comments welcome! 
>> > 
>> You implemented the "order_by" parameter as taking only one field name; 
>> this is 
>> inconsistent with the way ordering is done elsewhere  -- both the 
>> queryset 
>> order_by() method, and the model meta ordering option, take a list of 
>> field 
>> names, each optionally prefixed by "-". 
>>
>> While I can see reason in going for a simpler implementation, I think it 
>> is 
>> much preferable to have a consistent API; and even if the simpler 
>> implementation is preferred, you should take care of a more friendly 
>> error 
>> message for someone who would call qset.first("a","b") or even 
>> qset.last("-a") 
>> [the latter may seem to make no sense -- "if that's what you want, call 
>> qset.first('a')" -- but may reasonably arise in situations where the 
>> ordering 
>> field is received as an argument]. 
>>
>> Shai. 
>>
>

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

reconsider re-opening ticket 901

[Wim Feijen]

Hi,

Following up on the discussion on:
https://groups.google.com/forum/?fromgroups=#!topic/django-developers/DUQtBrM2iTs

I'd like to start a clear discussion about re-opening ticket 901.
https://code.djangoproject.com/ticket/901 

Ticket 901 was marked 7 years ago as won't fix and has been subject of 
debate since.

I must say that I for myself was looking for such a method until I found 
that foo = Foo.objects.get(id=foo.id) would work; which did not seem 
obvious to me then and now.

Brandon put forward an argument, which is: 
reload() would cover an important use case that did not get a hearing in 
the above discussion: that you might already have handed the object off to 
some other library, which is keeping a reference from somewhere deep in its 
data structures for use when you make a final call to it. If one or more 
data structures that are being built already hold the object, then it is 
not reasonable to have to track down the object and try to swap in a new 
copy everywhere. There should be a simple way to have the existing object's 
attributes update in-place.

and Anssi thinks it is a good idea to implement this.

My question is, can we please re-open this ticket and/or discuss here what 
are the benefits and drawbacks of having a method reload() ?

For clarity, this question is in no way meant to be offensive. And if you 
want to discuss personal views about this ticket or the behaviour of django 
community in general, I politely request you to do so at: 
https://groups.google.com/forum/?fromgroups=#!topic/django-developers/DUQtBrM2iTs

Best regards, Wim

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Perception of attitude in tickets

[Wim Feijen]

Hi Simon, Luke and Aymeric,

Simon, first of all, thanks for your feedback. 

Core developers, I think Simons comment is a thing we should take 
seriously. A ticket was closed and people didn't understand the process and 
re-opened it. I believe we could have explained more clearly:
1. our decision 
2. the workaround 
3. how exactly the mailing list works.

Instead this ticket ended up into an argument about re-opening this ticket, 
where people apparently weren't familiar with the process and did not know 
the proper steps to raise this to the e-mailing list which was of course 
the best step to get this ticket any further. 

For me, the best way to proceed seems to raise this ticket to the mailing 
list and I will do so in a separate thread. 

Core devs, Aymeric, Luke, know that I have high esteem for the django 
community and especially for you. I thank you for your time and dedication 
to Django, your responsiveness and willingness to help newcomers and 
discuss even trivial details, which I truely admire; and the friendly 
atmosphere and openess and willingness to take seriously almost every 
remark a know-nothing like me can make, which I value highly.

Simon, the "jacob" you are speaking about is Jacob Kaplan-Moss, one of the 
founders of django and since then our benevolent dictator, who has spent so 
much time on django and made this community as it is. In this case, maybe 
he could have spent a bit longer on his answer; but maybe he was triaging a 
hundred tickets and therefor a bit in a rush.

Best regards,

Wim 



On Saturday, 11 May 2013 00:41:12 UTC+2, Luke Plant wrote:
>
> Hi Simon, 
>
> > I feel that the general attitude expressed in some of the tickets is 
> > poor. The one which prompted this post 
> > is https://code.djangoproject.com/ticket/901. I think comment 20 
> >  is a good 
> > demonstration of my point. A couple of users were getting frustrated at 
> > the lack of discussion/progress which resulted in a fairly sanctimonious 
> > rant. 
>
> I'm afraid I really couldn't disagree more with your characterisation of 
> this situation. 
>
> If you just read the ticket, you'll find that different core developers 
> asked people to move discussion to the mailing list *3 times*, and quite 
> politely. 
>
> Everyone who comments after that point either hasn't read or has decided 
> to ignore *3 requests* about how to get the ticket to progress. And to 
> add insult to the injury of having wasted people's time already, some 
> start adding comments about how feature requests for Django are a waste 
> of time. 
>
> This is the height of rudeness, and if all they got was a sanctimonious 
> reply, they got better than they deserved. 
>
> I'm not claiming that we couldn't do better in terms of our clarifying 
> our processes and so on, but I think you picked an example that 
> demonstrates exactly the opposite of what you claimed. 
>
> Best regards, 
>
> Luke 
>
> -- 
> "God demonstrates his love towards us in this, that while we were 
> still sinners, Christ died for us." (Romans 5:8) 
>
> Luke Plant || http://lukeplant.me.uk/ 
>

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Wim Feijen]

Hi all,

We struggled to get a proper definition for a first() and last() method vs. 
earliest() and latest() . I'd like to make one proposal. After that, I 
really like your opinion on which syntax you prefer.

First, let me give you a lenghty introduction. We discussed several use 
cases on this mailing 
list.
 
Then, I realized that:

.filter(last_name__startswith='b').order_by('last_name').first()
is an acceptable compromise for me to use in stead of:
.first(last_name__startswith='b').order_by('last_name')

Last weekend Aymeric explained to me that earliest can actually accomplish 
the same:
.filter(last_name__startswith='b').earliest('last_name')

Then, I find "earliest" an inappropriate name, because it does not describe 
functioning well.

Therefore, my proposal is, if we are going to implement the earliest and 
latest method, we should definitely rename them to: first and latest.

After that, there is only one question left:

Which style do you prefer?

.filter(last_name__startswith='b').order_by('last_name').first()# clear 
and long
.first(last_name__startswith='b').order_by('last_name')# first method 
has filter syntax.
.filter(last_name__startswith='b').first('last_name')   # first method has 
order_by syntax.

So, what do you think?

Best regards,

Wim

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Future feature?] Viewsets

[Wim Feijen]

Hi,

Just wanted to draw your attention to a proposal made by Zachary Voase, 
which you might be unaware of. It has no code, but is just a proposal, 
having a very clean api IMHO.

http://zacharyvoase.com/2013/01/22/django-objviews/

Cheers, Wim

On Saturday, 26 January 2013 04:04:57 UTC+1, Bertrand Bordage wrote:
>
> Hi,
>
> This is my first message here, though I am using Django every day since 
> two years.
>
> Yesterday I read a Ruby on Rails tutorial and this gave me an idea of what 
> could IMO be a nice feature: viewsets.
> I therefore started a tiny project, 
> django-viewsets 
> (djangonauts 
> have weird reflexes… ^^).  *Everything is explained there.*
>
> What do you think?  Could this be an interesting feature?  “The next level 
> of class-based views”?  A *contrib* application?
>
> Regards,
> Bertrand
>

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Form.set_data method

[Wim Feijen]

Interestingly enough, it reminds me of the pattern proposed by Daniel 
Greenfeld and Miguel Araujo, who used a pattern:

form = MyForm(request.POST or None)

http://blip.tv/djangocon/advanced-django-form-usage-5573287

Wim

On Thursday, 31 January 2013 07:08:52 UTC+1, Shai Berger wrote:
>
> On Thursday 31 January 2013, Byron Ruth wrote: 
> > Here is the ticket: https://code.djangoproject.com/ticket/19668 and the 
> > pull request https://github.com/django/django/pull/674 
> > 
> > One user commented on the ticket raising a concern that it could 
> possibly 
> > be misused if the data is set after it had been used. It is certainly a 
> > valid concern, however it should be made clear in the docs when to use 
> it 
> > and/or raise an exception if `is_valid` has already been called. 
> > 
> > Thoughts? 
>
> While this is backwards-compatible per se, using it in views is generally 
> not 
> backwards-compatible with user form classes (you can't tell what they do 
> in 
> their initializers); thus, generic views (and also some not-generic views) 
> are 
> forced to keep using the "old way" unless the (user) form code is altered. 
> Which means, you'll have two ways to do the same thing (in views), without 
> a 
> clear preference between them. 
>
> So if you want this judged as a backwards-compatible change, I'm -1. 
>
> As a non-backwards-compatible change, I'd like it, but I don't think it's 
> worth the disruption, so I'm -0. 
>
> Either way, I'm not a core dev. 
>
> Shai. 
>
>

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: BigAutoField

[Wim Feijen]

Hi Steve,

Django is an open source product made and improved by many volunteers.

Probably you are reffering to: 
https://code.djangoproject.com/ticket/14286

What needs to get done to get the patch accepted in Django, is that 
somebody (really anybody - could be you) looks at the latest patch 
provided. maybe makes some improvements for suggestions and if all is well, 
it can be marked: Ready for checkin.

After that, it is a core developers "job" (again, it is voluntary) to 
either implement, or give constructive feedback on why not. Some tickets 
are easy and some are hard.

The best way to get a core developers attention is to do a 5 for 1, which 
means if you check 5 patches of other people, a core developer is willing 
to look at your patch / the patch you would like to have in Django.

More information on contributing to Django is here:
https://docs.djangoproject.com/en/dev/internals/contributing/

Good luck!

Wim

On Wednesday, 23 January 2013 15:09:29 UTC+1, SteveB wrote:
>
> Hi,
> Can anybody provide an update on the request to define a BigAutoField in 
> Django?
> We could really use this model field type without having to do workarounds 
> and customizations.
> Can any of the Django developers comment on when this will be released?
>
> Thanks,
> Steve

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

Re: A.objects.getdefault

[Wim Feijen]

Hi Selwin and Anssi,

Anssi, thanks for improving the patch and getting it ready for commit! 

Selwin, you are right that .filter() and .first() are very similar. 
Rationale for .first() is to get rid of the pattern 
try: 
instance = ModelX.objects.get 
except ObjectDoesNotExist:
instance = None
, which is a very common pattern so an exception seems out of place. Using 
filter to get the first result or none would still require three lines. 
Other alternative patterns are in this thread.

For me, example use cases would be Address.objects.first() which would 
return the first address in a list, when browsing through all addresses in 
detail view, or page.music_files.first() where we just have one music file 
per page or none. MusicFile.objects.first(page=page) should work too.

Indeed, .earliest('timestamp') could be expressed as 
.order_by('timestamp').first() , and latest similarly. In my opinion these 
are consistent with .filter() and .get().

Default ordering by id if no order is specified is the same behaviour as in 
the admin, so I would argue not to raise an exception when no ordering is 
specified, but to keep it like it is and order by id. Thanks for adding 
that Anssi!

Looking forward to other input,

Best regards,

Wim


On Sunday, 20 January 2013 12:18:22 UTC+1, Selwin Ong wrote:
>
> Hi Anssi,
>
> Shouldn't first() and last() raise an exception if no ordering is 
> specified? This keeps it consistent with latest() which requires the user 
> to explicitly specify what field it wants to use as ordering.
>
> Also, like you mentioned, IMHO these APIs are too similar (first, 
> earliest, last and latest) in name, yet the usage is completely different, 
> with latest() expecting a field name, the other filter args. What I also 
> don't like is that the filter_args expected by last() and first() are:
> 1. Doesn't allow exclude arguments
> 2. We already have .filter() method which does the same thing (filters a 
> queryset with passed kwargs)
>
> So if I may suggest, I think a better option would be to change the 
> methods first() and last() to behave more like latest(), but they should 
> return None when the query returns no result. Example usage:
>
> User.objects.exclude(a=b).filter(c=d).first('id') # Returns None if 
> there's no match
>
>  
>
> user = User.objects.exclude(a=b).filter(c=d).last('id')
> if user:
># do things...
>
>
> If last() and first() are introduced, perhaps we can also deprecate 
> latest() in the future because they're very similar.
>
> What do you guys think?
>
> Best,
> Selwin
>
> On Sunday, January 20, 2013 1:51:27 PM UTC+7, Anssi Kääriäinen wrote:
>>
>> On 10 tammi, 09:27, Wim Feijen <wimfei...@gmail.com> wrote: 
>> > Hi, 
>> > 
>> > Ticket 19326 has been marked as ready for check-in for some time. Can 
>> > some-one have a look at it? 
>> > 
>> >  https://code.djangoproject.com/ticket/19326 
>> > 
>> > Thanks, 
>> > 
>> > Wim 
>>
>> I did some more polish to the patch. There is now also .last() method, 
>> and if there is no ordering in the queryset, then it will be 
>> automatically ordered by the primary key. 
>>
>> I didn't commit the patch yet, as I wonder if there will be confusion 
>> about .latest(by_field), .last(filter_args). earliest(by_field) 
>> and .first(filter_args)? 
>>
>> Currently, the usage is this: 
>> a = 
>> Article.objects.order_by('headline').first(pub_date__year=2005) 
>> which will return first article by headline if any found or None if no 
>> match. .last() will just change the ordering by first 
>> calling .reverse() on the qs. 
>>
>> The patch is 100% ready for commit as far as I am concerned (cursory 
>> check of the changes doesn't hurt, of course). So, if one of the BDFLs 
>> sees the API as fine just go and commit the patch. 
>>
>> Patch available from 
>> https://github.com/akaariai/django/compare/ticket_19326. 
>>
>>  - Anssi 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/V8ZQdJ2cGlUJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: FloatField, localize and Django settings

[Wim Feijen]

Hi Michael, sounds very reasonable to me. Could you please file a bug 
ticket for that at https://code.djangoproject.com/newticket ?

On Tuesday, 22 January 2013 21:30:09 UTC+1, Michael Anckaert wrote:
>
> Hello everyone
>
> I came across an issue where my CBV and an automatic ModelForm gave me 
> some headaches with localization. 
>
> The project is localized so a float is 3,2 instead of 3.2 (comma instead 
> of dot) but the CBV UpdateView didn't handle the localization of the float. 
> After tracking through the sources I noticed that the attribute localize 
> of FloatField has to be set manually. 
>
> Wouldn't it be sensible to localize the FloatField according to the 
> project settings instead of having to manually set it in a custom form? 
>
> Kind regards
> Michael Anckaert 
> michael@sinax.be 
> http://www.sinax.be 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/BFrsjaJD0hMJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

cycle in nested loops

[Wim Feijen]

Hi,

Quoting ticket 5908 :

"Under the following example, I would expect the cycle tag's internal 
counter to be reset after leaving the inner loop. That way it'd be 'nesting 
safe' :-) 

{% for group in grouped %}
  {% for item in group.list %}
   ... {% cycle row1,row2,row3 %} ...
  {% endfor %}
{% endfor %}

"
Actually, the current behaviour is not to reset between loops. Is that 
intentional? 

A patch to ticket 5908  adds a 
reset_cycle tag, which resets the cycle-loop. I am wondering if it is the 
right way to solve this problem, or whether it would be better to modify 
cycle's current behaviour to reset the loop after each endfor; or maybe if 
we want another kind of cycle which allows for setting both options?

What do you think? 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/ijbkyiGiKykJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Shouldn't Textarea be CamelCased as TextArea?

[Wim Feijen]

Hi guys,

I was just wondering, and maybe my English language skills are 
insufficient. 

Django defines several widgets, like:
TextInput
PasswordInput
HiddenInput
DateInput
DateTimeInput
TimeInput
Textarea

Why isn't Textarea CamelCased: TextArea, like the other widgets? It seems 
inconsistent. But maybe I am missing something?

-- Wim

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/1V71BI3iUBQJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: A.objects.getdefault

[Wim Feijen]

Hi,

Ticket 19326 has been marked as ready for check-in for some time. Can 
some-one have a look at it?

 https://code.djangoproject.com/ticket/19326

Thanks,

Wim


Op donderdag 29 november 2012 23:45:38 UTC+1 schreef Wim Feijen het 
volgende:
>
> Hi Anssi,
>
> When I thought about it, the most prominent usecase seemed to me of 
> getting one of a set of many and expecting just one result. In that case, 
> get_or_none would suffice. However, as a method name, I prefer first() for 
> being concise. 
>
> For me it is ok to just have the first() method without last(). For 
> example, sqlalchemy defines first() but not last(). Although jquery does 
> define both.
>
> I agree that ordering should be applied and in case no ordering is 
> specified on the model, I really would like to use ordering by pk. Doesn't 
> filter provide results by default in that order? Unfortunately, I was not 
> able to comprehend the workings of clone so I am not sure.
>
> Regards, Wim
>
> Op donderdag 29 november 2012 08:12:28 UTC+1 schreef Anssi Kääriäinen het 
> volgende:
>>
>> On 29 marras, 01:13, Wim Feijen <wimfei...@gmail.com> wrote: 
>> > Hi, the patch has been updated and now works. 
>> > 
>> > Still, feedback would be appreciated. So, Anssi, Jacob? 
>>
>> Apart of some whitespace errors the patch looks good to me. 
>>
>> There isn't last() method in the patch. Implementing one is going to 
>> be a little more challenging as one needs to change the direction of 
>> all the ordering clauses. Do we want one in the same patch? 
>>
>> A bigger problem might be that we already have .latest() which does 
>> something a bit different. I wonder if having both .last(filter_args) 
>> and .latest(by_field) is going to be confusing. 
>>
>> Another API issue is that should .first() check for some ordering? 
>> This could add some protection. In testing conditions things might 
>> work, but when updates are done to the rows the expected ordering 
>> suddenly changes. One option is to do automatic ordering on PK if 
>> there isn't any other ordering present. 
>>
>> I still like the idea of .get_default() mainly for the added "if 
>> multiple objects returned, then throw an error" protection it gives. 
>> From implementation/maintenance perspective these are really easy 
>> additions, from API bloat perspective maybe not... 
>>
>>  - Anssi 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/KNzxgP8L-V0J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: A.objects.getdefault

[Wim Feijen]

Hi Anssi,

When I thought about it, the most prominent usecase seemed to me of getting 
one of a set of many and expecting just one result. In that case, 
get_or_none would suffice. However, as a method name, I prefer first() for 
being concise. 

For me it is ok to just have the first() method without last(). For 
example, sqlalchemy defines first() but not last(). Although jquery does 
define both.

I agree that ordering should be applied and in case no ordering is 
specified on the model, I really would like to use ordering by pk. Doesn't 
filter provide results by default in that order? Unfortunately, I was not 
able to comprehend the workings of clone so I am not sure.

Regards, Wim

Op donderdag 29 november 2012 08:12:28 UTC+1 schreef Anssi Kääriäinen het 
volgende:
>
> On 29 marras, 01:13, Wim Feijen <wimfei...@gmail.com> wrote: 
> > Hi, the patch has been updated and now works. 
> > 
> > Still, feedback would be appreciated. So, Anssi, Jacob? 
>
> Apart of some whitespace errors the patch looks good to me. 
>
> There isn't last() method in the patch. Implementing one is going to 
> be a little more challenging as one needs to change the direction of 
> all the ordering clauses. Do we want one in the same patch? 
>
> A bigger problem might be that we already have .latest() which does 
> something a bit different. I wonder if having both .last(filter_args) 
> and .latest(by_field) is going to be confusing. 
>
> Another API issue is that should .first() check for some ordering? 
> This could add some protection. In testing conditions things might 
> work, but when updates are done to the rows the expected ordering 
> suddenly changes. One option is to do automatic ordering on PK if 
> there isn't any other ordering present. 
>
> I still like the idea of .get_default() mainly for the added "if 
> multiple objects returned, then throw an error" protection it gives. 
> From implementation/maintenance perspective these are really easy 
> additions, from API bloat perspective maybe not... 
>
>  - Anssi 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/I3QQzpiFaZYJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: A.objects.getdefault

[Wim Feijen]

Hi, the patch has been updated and now works. 

Still, feedback would be appreciated. So, Anssi, Jacob?

- Wim

Op maandag 19 november 2012 22:48:36 UTC+1 schreef Wim Feijen het volgende:
>
> Hi,
>
> I do like the first() method and went ahead and *tried* to implement it.
>
> Ticket:
> https://code.djangoproject.com/ticket/19326
>
> Patch, including tests and doc changes:
> https://code.djangoproject.com/attachment/ticket/19326/19326.diff
>
> Unfortunately, tests fail. Probably ordering is wrong, or I am making a 
> stupid mistake.
>
> Can somebody experienced at db/models/query.py have a look at my patch? 
>
> Thanks!
>
> Wim
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/kJZjTBzqQzAJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Redesign of djangoproject.com?

[Wim Feijen]

Oops sorry Dana! Thanks Jacob, that's good to hear!

Op dinsdag 9 oktober 2012 23:26:42 UTC+2 schreef Dana Woodman het volgende:
>
> Glad you like the design, but I'm a he. :)
>
> On Tuesday, October 9, 2012 11:58:58 AM UTC-7, Wim Feijen wrote:
>>
>> Hi Jacob, 
>>
>> I was wondering whether there were any entries and whether a decision has 
>> been taken to appoint a benevolent redesigner? 
>>
>> Personally I really liked Dana's proposal, marketing-wise, and 
>> considering she raised the question, I would certainly support her. 
>>
>> My apologies if I missed a conversation on the mailing list.
>>
>> Best regards,
>>
>> Wim
>>
>> Op donderdag 24 mei 2012 19:14:36 UTC+2 schreef Jacob Kaplan-Moss het 
>> volgende:
>>>
>>> Hi folks -- 
>>>
>>> Thanks so much to everyone who's participated in this thread; I feel 
>>> like there's a lot of useful discussion and brainstorming going on. 
>>>
>>> The DSF board met yesterday and discussed the effort --  we're 
>>> determined to get this done soon. Unfortunately, we ultimately think 
>>> that this collaborative effort isn't working: there's a lot of great 
>>> ideas, but some of the discussion is veering closer to "design by 
>>> committee", and nobody's really empowered to move things forward. 
>>>
>>> Ultimately and sadly, though, great design is at odds to a community 
>>> process: the only way we know to get something we *love* is to find 
>>> someone awesome and let them do their thing. 
>>>
>>> So here's the plan: in the next month we're do exactly that: find 
>>> someone awesome, and give them carte blance on the redesign. We'll of 
>>> course give feedback, and touch base with the community a few times, 
>>> but ultimately we're going to put this thing into one person's hands. 
>>>
>>> If you'd like to become the Benevolent Dictator For This Redesign, 
>>> then please send a proposal to <found...@djangoproject.com>. This 
>>> doesn't need to be formal; we just need to know two things: 
>>>
>>> 1. Can you deliver? Convince us that you'll actually be able to get 
>>> this done: show us a track record of shipping, and explain why you'll 
>>> have time to work on this. We'd like to see this land before DjangoCon 
>>> US in September; can you hit that? 
>>>
>>> 2. Are you awesome? Convince us that your design will rock. This can 
>>> come in the form of a mockup, or previous work, or whatever. Again we 
>>> don't need formal stuff here, and we certainly don't expect spec work. 
>>> We just want to make sure your aesthetic matches ours. 
>>>
>>> A few further notes: 
>>>
>>> * I want to stress the informality of this. We don't need or want a 
>>> full formal proposal like you would for a real client; we just want to 
>>> know that you're awesome and can deliver. If you can prove that to us 
>>> in a few words, do it! 
>>>
>>> * You don't have to do this all yourself; we have quite a few 
>>> volunteers. Importantly, we have *plenty* of people who can help on 
>>> the backend (natch), so really all we need is someone who's great at 
>>> the design side. How much of the actual coding you do is up to you. If 
>>> you've got weaknesses that's complete fine, just tell us what help you 
>>> need and we'll fill it in. You'll be in charge visually and 
>>> aesthetically, but we'll encourage you to delegate as much as you can. 
>>>
>>> * We don't currently have a budget assigned; we're thinking this'll be 
>>> volunteer work. However, the DSF *does* have some funds, and if money 
>>> makes the difference we'll spend it. So if you need money to make it 
>>> happen, tell us. We won't penalize you if you need to get paid (but at 
>>> the same time we hope you recognize we probably can't afford market 
>>> rates). 
>>>
>>> * The deadline is Sunday, June 17th, and we'll aim to make a decision 
>>> that week. 
>>>
>>> Thanks everyone! 
>>>
>>> Jacob 
>>>
>>> PS: I'm deliberately burying this down in the thread instead of 
>>> posting this more publicly. I'd like to avoid this becoming a general 
>>> call; I'm more interested in reaching people who're *already* paying 
>>> attention to this effort. I'd appreciate it, then, if you'd keep this 
>>> call off Reddit, Hacker News, etc. However, if you know someone who 
>>> you think *should* be interested, please forward it onto them! 
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/b_HxYxv4CgwJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Redesign of djangoproject.com?

[Wim Feijen]

Hi Jacob, 

I was wondering whether there were any entries and whether a decision has 
been taken to appoint a benevolent redesigner? 

Personally I really liked Dana's proposal, marketing-wise, and considering 
she raised the question, I would certainly support her. 

My apologies if I missed a conversation on the mailing list.

Best regards,

Wim

Op donderdag 24 mei 2012 19:14:36 UTC+2 schreef Jacob Kaplan-Moss het 
volgende:
>
> Hi folks -- 
>
> Thanks so much to everyone who's participated in this thread; I feel 
> like there's a lot of useful discussion and brainstorming going on. 
>
> The DSF board met yesterday and discussed the effort --  we're 
> determined to get this done soon. Unfortunately, we ultimately think 
> that this collaborative effort isn't working: there's a lot of great 
> ideas, but some of the discussion is veering closer to "design by 
> committee", and nobody's really empowered to move things forward. 
>
> Ultimately and sadly, though, great design is at odds to a community 
> process: the only way we know to get something we *love* is to find 
> someone awesome and let them do their thing. 
>
> So here's the plan: in the next month we're do exactly that: find 
> someone awesome, and give them carte blance on the redesign. We'll of 
> course give feedback, and touch base with the community a few times, 
> but ultimately we're going to put this thing into one person's hands. 
>
> If you'd like to become the Benevolent Dictator For This Redesign, 
> then please send a proposal to . 
> This 
> doesn't need to be formal; we just need to know two things: 
>
> 1. Can you deliver? Convince us that you'll actually be able to get 
> this done: show us a track record of shipping, and explain why you'll 
> have time to work on this. We'd like to see this land before DjangoCon 
> US in September; can you hit that? 
>
> 2. Are you awesome? Convince us that your design will rock. This can 
> come in the form of a mockup, or previous work, or whatever. Again we 
> don't need formal stuff here, and we certainly don't expect spec work. 
> We just want to make sure your aesthetic matches ours. 
>
> A few further notes: 
>
> * I want to stress the informality of this. We don't need or want a 
> full formal proposal like you would for a real client; we just want to 
> know that you're awesome and can deliver. If you can prove that to us 
> in a few words, do it! 
>
> * You don't have to do this all yourself; we have quite a few 
> volunteers. Importantly, we have *plenty* of people who can help on 
> the backend (natch), so really all we need is someone who's great at 
> the design side. How much of the actual coding you do is up to you. If 
> you've got weaknesses that's complete fine, just tell us what help you 
> need and we'll fill it in. You'll be in charge visually and 
> aesthetically, but we'll encourage you to delegate as much as you can. 
>
> * We don't currently have a budget assigned; we're thinking this'll be 
> volunteer work. However, the DSF *does* have some funds, and if money 
> makes the difference we'll spend it. So if you need money to make it 
> happen, tell us. We won't penalize you if you need to get paid (but at 
> the same time we hope you recognize we probably can't afford market 
> rates). 
>
> * The deadline is Sunday, June 17th, and we'll aim to make a decision that 
> week. 
>
> Thanks everyone! 
>
> Jacob 
>
> PS: I'm deliberately burying this down in the thread instead of 
> posting this more publicly. I'd like to avoid this becoming a general 
> call; I'm more interested in reaching people who're *already* paying 
> attention to this effort. I'd appreciate it, then, if you'd keep this 
> call off Reddit, Hacker News, etc. However, if you know someone who 
> you think *should* be interested, please forward it onto them! 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/BIpmPoJtjvMJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: A.objects.getdefault

[Wim Feijen]

For me, get_or_none would prevent a lot of boilerplate code in my views, so 
I am in favor of adding the method.

Wim

Op dinsdag 9 oktober 2012 19:15:55 UTC+2 schreef ptone het volgende:
>
> Unsurprisingly - this has come up before:
>
> Earlier discussion
>
> https://groups.google.com/forum/?fromgroups=#!topic/django-developers/Saa5nbzqQ2Q
>
> tickets:
> https://code.djangoproject.com/ticket/17546
> https://code.djangoproject.com/ticket/2659
> https://code.djangoproject.com/ticket/11352
>
> All the ticket's were wontfixed
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/_nHUoZZICcQJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: prevent brute force attacks by acting on several failed logins, for example by using a captcha

[Wim Feijen]

Hi Paul,

Thanks for your review and remarks. I will think on it more, and will
write a longer response later.

For the moment just this quick reponse:

I was thinking of adding a recaptcha implementation, based on the work
of others, if that would work with licenses. But probably that choice
would indeed introduce an external (unwanted) dependency.

About ticket 16860, I believe that to be over my head for now. In your
opinion, is that ticket tied to the User discussion, about a more
flexible/abstract User model (ticket 3011)?

And/Or do you believe we have to deal with database migration first?

Wim

On Oct 2, 9:21 am, Paul McMillan  wrote:
> My sense is that you're conflating 2 kinds of protection here because
> you haven't made a decision. Do you want to propose rate limiting, or
> a captcha? Answers to your points depend on that.
>
> Prior to more specific work on this matter (and before anything can be
> included in core), we need to address the issues in 16860. The generic
> groundwork must be done first. It would be helpful to examine this
> proposal in light of those concerns. What hooks does Django need to
> provide to allow this to be implemented cleanly as a third-party
> installable?
>
> This needs to be pluggable because (no matter what we include), it
> won't meet the requirements for a sizable subset of Django's users
> (many of whom have very explicit requirements).
>
> > Points 1-3
>
> Our protection should be on by default if we include it in Django at
> all. This means that the default configuration will be universal
> enough that it doesn't get in the way for most installations.
>
> > 4. After x failed login attempts, protection kicks in. x is a
> > configurable amount of times, which by default is 3?
>
> 3 is too few for a default on a general user-facing site. Brute force
> attempts try hundreds of passwords. If normal users see this
> protection with any regularity, people will turn it off.
>
> > 5. Failed logins are either stored in a database (which works well for
> > small systems and protects against slow distributed attacks), or in
> > memory (for large systems). Default: use the database? Because most
> > users operate on small systems?
>
> Probably the database. An extra column on users would be the most
> obvious place, but it's a no-go because we don't have migrations and
> this functionality should be separately pluggable anyway. We would
> need to ship with a default set to off in the base settings file, and
> explicitly set it on for new projects. If it adds database columns,
> that might be an argument for shipping with it disabled.
>
> > 6. We protect against the following scenarios:
> >    a. Login attempts coming from many IP-addresses and targeting a
> > single user account;
> >    b. From a single IP-address, targeting a single user;
> >    c. Single IP-address, more than one user.
> >    Case 6a and - in a lesser extent - 6b are strong indicators for a
> > brute force attack. Case 6c might be brute force, but might also be
> > triggered by many users behind a proxy.
>
> These are all attack vectors. There's also multiple IP multiple
> account slow brute force, and many other variations. Any of these
> options is going to need to be quite configurable to work for most
> Django users.
>
> > 7. Protection may consist of:
> >    a. denying access for x minutes for a given user or IP-address. x
> > is configurable, and by default: 5 minutes?
>
> Rate limiting is more user friendly than a hard cutoff like this. The
> hard cutoff is easier to explain to a user, though. This allows a DoS
> attack against specific users.
>
> >    b. adding a sleeptime to login requests (mentioned several times,
> > but sounds very weak to me, because it can be easily passed by opening
> > a new connection?).
>
> Absolutely no. Adding sleep() anywhere in Django opens nasty DoS
> avenues. Sleep ties up workers for no reason.
>
> >    c. logging it, and/or notifying the admin
> >    d. adding a captcha to login form
>
> Which captcha do you propose? Is there a good one which does not add
> external dependencies? We can't require compiled dependencies like PIL
> out of the box.
>
> > 8. Protection should be configurable as well. By default: use a
> > captcha? Using a captcha prevents an attacker from using the denial
> > trigger for a DoS-attack.
>
> Captchas do that. They also introduce usability issues. Do you have a
> pure-python captcha which is also ADA compliant? How do you recommend
> we balance the difficulty (for both humans and robots) of the captcha?
>
> > 9. Rate limitors should be generably applicable, to all views.
>
> Yes. This is why they are probably best viewed as a separate feature.
>
> > 10. Final question:
> > Should this be in Django contrib? I argue in favor, in order to
> > protect the innocent and keep everyone safe.
>
> I agree that Django should ship some form of login protection.
>
> >  django.contrib.security
> > seems a proper place to me.
>
> 

filter users by group in the admin user_list

[Wim Feijen]

Hello,

When using groups, it would be handy to filter users by group.

Ticket #16835 proposes to add this to the admin by default.

Do we need to limit the number of groups displayed, if there are many
many groups? (I am not sure if people are using groups that way, I use
them primarily to manage privileges, but if I am not sure, there
probably are many users :)).

Can somebody review this ticket, comment on it and tell what needs to
be done?

(Should I do a 5-1?)

Wim

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: django messages framework

[Wim Feijen]

Using render_to_string, you can use a template, and it is backwards
compatible. Would that work?

Wim

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: prevent brute force attacks by acting on several failed logins, for example by using a captcha

[Wim Feijen]

Hello,

Thanks for the pointers. Based on the previous discussion and the
comments at Simon Willison's blog on ratelimitcache, here is a first
draft of my proposal:

1. Considering that Django's admin and default login schemes are
currently unprotected against brute force attacks by default, and
2. Many users implement Django out of the box with an admin open to
brute force attacks,
3. We aim to protect Django users and to make their projects safe by
supplying an optional brute force protection mechanism. Which by
default is: on? Or off?
4. After x failed login attempts, protection kicks in. x is a
configurable amount of times, which by default is 3?
5. Failed logins are either stored in a database (which works well for
small systems and protects against slow distributed attacks), or in
memory (for large systems). Default: use the database? Because most
users operate on small systems?
6. We protect against the following scenarios:
a. Login attempts coming from many IP-addresses and targeting a
single user account;
b. From a single IP-address, targeting a single user;
c. Single IP-address, more than one user.
Case 6a and - in a lesser extent - 6b are strong indicators for a
brute force attack. Case 6c might be brute force, but might also be
triggered by many users behind a proxy.
7. Protection may consist of:
a. denying access for x minutes for a given user or IP-address. x
is configurable, and by default: 5 minutes?
b. adding a sleeptime to login requests (mentioned several times,
but sounds very weak to me, because it can be easily passed by opening
a new connection?).
c. logging it, and/or notifying the admin
d. adding a captcha to login form
8. Protection should be configurable as well. By default: use a
captcha? Using a captcha prevents an attacker from using the denial
trigger for a DoS-attack.
9. Rate limitors should be generably applicable, to all views.
10. Final question:
Should this be in Django contrib? I argue in favor, in order to
protect the innocent and keep everyone safe. django.contrib.security
seems a proper place to me. There are several rate-limiting
implementations in the wild, but unfortunately they are not often
used. For example, compare the numbers on django-packages for django-
axes, brutebuster and ratelimitcache against a commonly used
application like south or django-debug-toolbar.

I would be very glad to hear your comments. Please let me know of
anything else I did not cover and should have, and please let me know
your answers to the many questions I raised.

Thanks for your help! Goodnight to you,

Wim

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: prevent brute force attacks by acting on several failed logins, for example by using a captcha

[Wim Feijen]

Thanks guys for the support.

For reference, there is a previous thread "Brute force attacks", here:
http://groups.google.com/group/django-developers/browse_thread/thread/71877ef02fb7c054/0b44e048b5bf4b77

Which does not mention captcha's btw.

Luke, I'll think about it, but it will take some time; thanks for the
guidance.

Wim

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

prevent brute force attacks by acting on several failed logins, for example by using a captcha

[Wim Feijen]

Hello,

Would it be a good idea to write a ticket and patch to stop brute
force attacks, either by requiring people to fill in a captcha after
several failed login attempts; or by setting a time delay?

Mozilla Secure Coding Guidelines recommend in doing so, see:
https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines#Easy_Quick_Wins

Google uses a captcha and I favor that approach.

Would it be a good idea to create a ticket for this, and write a
patch?

Best regards,

Wim

---

>From the Mozilla Secure Coding Guidelines:

Account Lockout and Failed Login
Account Lockouts vs login failures should be evaluated based on the
application. In either case, the application should be able to
determine if the password being used is the same one over and over, or
a different password being used which would indicate an attack.

The error message for both cases should be generic such as:

Invalid login attempts (for any reason) should return the generic
error message

 The username or password you entered is not valid

Logging will be critical for these events as they will feed up into
our security event system and we can then take action based on these
events. The application should also take action. Example would be in
the case that the user is being attacked, the application should stop
and/or slow down that user progress by either presenting a captcha or
by doing a time delay for that IP address. Captcha's should be used in
all cases when a limit of failed attempts has been reached.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

gunicorn in docs

[Wim Feijen]

Hello,

After watching glyphs talk [1], do we want to add a gunicorn
installation instruction to the installation docs? What is your
opinion?

Wim

[1]: http://blip.tv/djangocon/keynote-glyph-lefkowitz-5573264

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Should user passwords be more strict?

[Wim Feijen]

Having just finished a discussion on security, I'd like to raise a
concern of mine.

By default, users can have a one-character password.

When their accounts get hacked, we suffer the consequences as well.

Should we be more strict in that?

Wim

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: please reopen ticket 15567

[Wim Feijen]

Ladies and gentlemen,

Thanks for all the feedback, a patch is in ticket 16837:
https://code.djangoproject.com/ticket/16837

Feel free to try and review the patch.

Best regards and for now, good night.

Wim

On 13 sep, 23:42, Jacob Kaplan-Moss  wrote:
> Hi folks --
>
> I agree 100% with what Russ had to say on the ticket: leaking
> information about admin accounts isn't OK, and we won't change that.
>
> If someone would like to submit a patch with different wording that
> covers all cases -- "this is an invalid user/password for admin
> access" or somesuch -- that's fine. Please open a new ticket for it so
> we don't get confused though. But having one and only one error
> message here is by design.
>
> Thanks!
>
> Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: please reopen ticket 15567

[Wim Feijen]

Hi, thanks for your quick responses!

Flavio, Jan and Florian, it only "gives away information" when an
attacker guesses both the username and the password right.

But if he can guess those right, he could already access the users
information using the normal login! So giving this message does not
change the danger. On the other hand, it would prevent lots of
confusion.

But we are repeating arguments here, so could you please read:

http://groups.google.com/group/django-developers/browse_thread/thread/df19241a0b1a04ef

before responding?

Thanks!

Wim


On 13 sep, 19:23, Flávio Amieiro  wrote:
> On Tue, Sep 13, 2011 at 2:16 PM, Cal Leeming [Simplicity Media Ltd]
>
>  wrote:
> > +1, if the user/pass is entered, that user is entitled so know what its own
> > permissions are.
> > The error should give "You have insufficient access to this page" or
> > something like that.
>
> The thing is: if someone does a brute force attack on '/admin/' and
> gets this message back, they know there's a user with that
> login/password in the system. Since brute force attacks using common
> login/password pairs in this kinds of urls is so common, I think this
> exposes your user more than necessary.
>
> -1

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

please reopen ticket 15567

[Wim Feijen]

Hello,

When a user tries to login on the admin, with correct username &
password, but is_staff is set to False, the error message is
misleadingly wrong:

"Please enter a correct username and password. Note that both fields
are case-sensitive."

Ticket 15567 deals with this and is currently marked as wont fix.
After a lenghty discussion on

http://groups.google.com/group/django-developers/browse_thread/thread/df19241a0b1a04ef

the general consensus seems in favor of changing the error message and
thus to re-open the ticket.

Could the ticket please be reopened?

Thanks,

Wim

Ticket 15567:
https://code.djangoproject.com/ticket/15567

A patch:
https://code.djangoproject.com/attachment/ticket/16834/admin_not_allowed.diff

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: plea for re-opening ticket 13125 marked as won't fix

[Wim Feijen]

Hi Florian,

Then again, the default behaviour now is as you describe. That's why I
would call it a security leak.

Unfortunately, it is not only my system, it is the system of any
unaware Django programmer.

Wim

On Sep 11, 10:24 pm, Florian Apolloner <f.apollo...@gmail.com> wrote:
> On Sunday, September 11, 2011 8:52:03 PM UTC+2, Wim Feijen wrote:
>
> > 3. Because the user is still logged in, (maybe for two weeks, or for
> > whatever expiration time the developer has set)
>
> Imo in that case the developer should write a middleware that logs the user
> out on the next request. I see your problem, but imo your system needs a bit
> of tweaking if you allow inactive users to browse your site till their
> session expires (which with SAVE_EVERY_REQUEST +  a high timeout) could as
> well be never…

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: plea for re-opening ticket 13125 marked as won't fix

[Wim Feijen]

Paul,

On further thinking, I do believe that the current behaviour of
login_required should be considered a bug.

Wim

On 10 sep, 02:03, Paul McMillan  wrote:
> No. Django makes an incredibly strong promise about backwards
> compatibility to its users. Security releases are the ONLY reason we
> modify behavior in backwards incompatible fashions, and we try very
> hard to avoid that.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: plea for re-opening ticket 13125 marked as won't fix

[Wim Feijen]

The case is as follows:

1. An active user is logged in and has a valid session.
2. The user is inactivated by a system admin, who wants to disable the
user.
3. Because the user is still logged in, (maybe for two weeks, or for
whatever expiration time the developer has set), he passes the
login_required decorator, and still can see those pages which we
naively thought were being protected by the login_required decorator,
because that decorator doesn't check for is_active.

This patch is a patch for that problem.

Wim


On 10 sep, 23:09, Florian Apolloner  wrote:
> Stupid question, but why do you let inactive users login at all? I mean is
> this really a problem of the decorator and not of the login system you use?!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

https://www.djangoproject.com/download/ is down!

[Wim Feijen]

The download page for Django is down.

I also filed a ticket, so this is a duplicate message.

Wim

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal for a new templatetag definition syntax

[Wim Feijen]

Hi Alex,

Probably I am thinking way too simple, but if you gave me a free
choice of how to write templatetags in my code, I would prefer:

def mytag(foo, bar):
 # some code
 return output

or:

class MyTag(Tag):
def __init__(self, foo, bar):
self.foo = foo
self.bar = bar

and

def mytag(src, limit=1, offset=10, ??)

or:

class MyTag(Tag):
def __init__(self, limit=1, offset=10, ??):
self.limit = limit
self.offset = offset

   def render(self):
   """do some nasty stuff to limit and offset and return something."""

Just kick me if I am talking non-sense, that's ok.

Wim

On 10 sep, 02:29, Alex Gaynor  wrote:
> Hello all,
>
> For many years, writing templatetags has been among the most hilariously
> complicated things we Django developers did. Anyone who has written parsing
> for
> templatetags, over and over, shares this pain. Further, the current syntax
> present a tremendous problem for Armin Ronacher's GSOC towards template
> compilation: template tags define a ``render()`` method, which takes the
> current context (a stack of dictionaries) and perform some behavior which is
> opaque to the caller. This is a problem because one of the core objectives
> of
> the template compilation infrastructure is to store the template context in
> Python local variables, rather than in dictionaries. For all these reasons,
> several of us (myself, Idan, Russ, Carl Meyer, Andrew Godwin, Jonas Obrist,
> Chris Beaven) just sat down (we actually stood, mostly) and tried to iron
> out a
> proposal that solves these problems, taking inspiration from the plethora of
> libraries that exist today.
>
> We ultimately created two possible solutions, one inspired primarily by
> django-classy-tags and django-templatetag-sugar, the other mostly inspired
> by
> django-ttags. We came to a fragile agreement on the first. We primarily
> evaluated two cases for these, one very simple, the other more complex, and
> compared the resulting implementations.
>
> The first case we considered was a templatetag which takes two, required,
> arguments. Invocation looks like ``{% mytag foo bar %}``.  The two
> definitions
> look like:
>
>     class MyTag(Tag):
>         args = [
>             Argument("foo"),
>             Argument("bar"),
>         ]
>
>     class MyTag(Tag):
>         foo = Argument()
>         bar = Argument()
>
> the second case we considered was a tag which has one required, positional,
> argument, and two optional, keyword arguments, which can occur in any order,
> followed by a final, optional keyword argument, meaning any of the following
> invocations are valid:
>
>     {% mytag src limit 1 offset 10 %}
>     {% mytag src limit 1 offset 10 with foo %}
>     {% mytag src limit 1 %}
>     {% mytag src offset 10 limit 1 %}
>     {% mytag src %}
>
> and the two implementations were:
>
>     class MyTag(Tag):
>         args = [
>             Argument("source"),
>             Unordered(
>                 NamedArgument("limit", required=False),
>                 NamedArgument("offset", required=False),
>             ),
>             NamedArgument("as", required=False, resolve=False)
>         ]
>
>     class MyTag(Tag):
>         source = Argument()
>         limit = NamedArgument(required=False)
>         offset = NamedArgument(required=False)
>         as_ = BasicArgument(required=False)
>
>         class Meta:
>             ordering = (
>                 ('source',),
>                 Unordered('limit', 'offset'),
>                 ('as_',)
>             )
>
> The general consensus was that the second implementation was *very* slightly
> preferable in the simple case, however it was significantly more complicated
> in
> the second case, and thus the first implementation was preferable overall.
>
> We notable did *not* discuss what the syntax for defining the output was, at
> this stage we were only concerned with the syntax definition. This is
> because
> the actual ``render()`` equivalent will be orthogonal to the parsing stage
> equivalent.
>
> For your consideration,
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your right to
> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: plea for re-opening ticket 13125 marked as won't fix

[Wim Feijen]

I added an active_login_required decorator. See:

https://code.djangoproject.com/ticket/16797

Is it a good name? It is a good patch? Or is it stupid?

Thanks, Wim

On 10 sep, 02:27, Wim Feijen <wimfei...@gmail.com> wrote:
> Thanks Paul,
>
> I like the idea of the additional decorator! Let's do that.
>
> Wim
>
> On 10 sep, 02:03, Paul McMillan <p...@mcmillan.ws> wrote:
>
>
>
>
>
>
>
> > > I'd like to make a case to re-open ticket 13125.
>
> > Thanks for taking this to the mailing list rather than arguing in trac.
>
> > > I understand that changing the current behaviour is backwards-
> > > incompatible and therefor very unwanted. But, I'd say the current
> > > implementation is forward-incompatible: meaning that current and
> > > future users will stumble on something counter-intuitive and be amazed
> > > that an inactive user can pass a login_required.
>
> > No. Django makes an incredibly strong promise about backwards
> > compatibility to its users. Security releases are the ONLY reason we
> > modify behavior in backwards incompatible fashions, and we try very
> > hard to avoid that.
>
> > > For me, the current behaviour is contrary to most peoples expectation,
> > > and my proposal would be to make the backwards-incompatible change to
> > > make django more consistent (I might even say: more logical), which I
> > > think is a good thing.
>
> > Yeah, I agree that the current behavior is counter intuitive. It is an
> > oddity and a wart that exists.
>
> > > My proposal is also to add an active_or_inactive_login_required
> > > decorator (a better name is welcome) which just checks whether a user
> > > is authenticated; and then people could import that as login_required.
>
> > I wouldn't be opposed to an additional decorator which makes better
> > grammatical sense and does explicitly what you want. We just can't
> > change the behavior of the current one. If you can come up with two
> > new ones that make better sense there might be an argument for slowly
> > deprecating the existing one.
>
> > > The consequence is that some people would need to make a change to
> > > keep their code working in Django 1.4 , but it is my belief that this
> > > is only a small part of the Django population who have the skills to
> > > adapt and that it will have a benificial effect to most current and
> > > all future users.
>
> > No. We do not do this. Otherwise every release would end up stuffed
> > full of dozens of "tiny easy changes" which means nobody would bother
> > updating.
>
> > Regards,
> > -Paul

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: ticket 13125 is waiting for a design decision for 18 months

[Wim Feijen]

Gert, do you want an inactive user to be able to see login_required
views?

On 9 sep, 12:19, Gert Van Gool <gertvang...@gmail.com> wrote:
> Well, we - and I imagine many others - are actively using this behavior.
> So our use-case is simple: a user registers, the user remains inactive
> until they click on a link in their mailbox.
> That is the behavior is "defined" by django-registration.
>
> -- Gert
>
> Mobile: +32 498725202
> Twitter: @gvangool
> Web:http://gertvangool.be
>
>
>
>
>
>
>
> On Fri, Sep 9, 2011 at 07:24, subs...@gmail.com <subs...@gmail.com> wrote:
> > Could anyone provide a use case where I want a de-activated user to
> > remain authenticated? Who is this option for? Why is it default?
>
> > When I originally reported this ticket I did so because this is a
> > plain security risk--non-technical users uncheck 'is active' when they
> > want to lock someone out of access. They don't realize that the
> > session remains active and I believe this to be an oversight within
> > the original design, not a design preference.
>
> > On Sep 8, 2:11 am, Vladimir Kryachko <v.kryac...@gmail.com> wrote:
> >> I think it has been done on purpose, and should not be changed.
> >> Because different authentication backends may choose to support
> >> inactive users or not. And the default (ModelBackend) supports
> >> inactive users which is expressed in
> >> ModelBackend.supports_inactive_user = True. So I would suggest you
> >> write a custom decorator.
>
> >> On Fri, Sep 2, 2011 at 6:49 AM, Wim Feijen <wimfei...@gmail.com> wrote:
> >> > I'd like to draw attention to an open ticket which needs a design
> >> > decision.
>
> >> > Description:
> >> > "The login_required decorator is not checking User.is_active, as
> >> > staff_member_required does. If an authenticated user is deactivated
> >> > (via setting is_active to False), the user is still able to browse
> >> > login_required-protected views."
>
> >> > For probably most people, the expected and (most likely) wanted
> >> > behavior would be not to let inactive users have access to
> >> > login_required files.
>
> >> > Wim
>
> >> > --
> >> > You received this message because you are subscribed to the Google 
> >> > Groups "Django developers" group.
> >> > To post to this group, send email to django-developers@googlegroups.com.
> >> > To unsubscribe from this group, send email to 
> >> > django-developers+unsubscr...@googlegroups.com.
> >> > For more options, visit this group 
> >> > athttp://groups.google.com/group/django-developers?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Django developers" group.
> > To post to this group, send email to django-developers@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://groups.google.com/group/django-developers?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

plea for re-opening ticket 13125 marked as won't fix

[Wim Feijen]

Jakob, thanks for looking into 13125 and taking action on it.

I'd like to make a case to re-open ticket 13125.

I understand that changing the current behaviour is backwards-
incompatible and therefor very unwanted. But, I'd say the current
implementation is forward-incompatible: meaning that current and
future users will stumble on something counter-intuitive and be amazed
that an inactive user can pass a login_required.

For me, the current behaviour is contrary to most peoples expectation,
and my proposal would be to make the backwards-incompatible change to
make django more consistent (I might even say: more logical), which I
think is a good thing.

My proposal is also to add an active_or_inactive_login_required
decorator (a better name is welcome) which just checks whether a user
is authenticated; and then people could import that as login_required.

The consequence is that some people would need to make a change to
keep their code working in Django 1.4 , but it is my belief that this
is only a small part of the Django population who have the skills to
adapt and that it will have a benificial effect to most current and
all future users.

Sorry that I raise this question again, but it is my strongest belief
that it will make Django better.

Wim

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: authentication by email

[Wim Feijen]

For the record and as an answer to the previous question, I'd like to
quote Russell who wrote the following in reponse to a ticket of mine:

" The core-endorsed ticket for this problem is #3011. The patch on
that
 ticket isn't endorsed, but it points at the real problem - a need to
be
 able to specify a custom User model. There have been several
discussions
 directed at this problem, and I'm hoping to get a posse discussing
this at
 the upcoming DjangoCon sprints. If you want background on some
approaches
 that might work (and some that won't) search the archives for Lazy
Foreign
 Key. "

Thanks Russell and I wish you good luck in the Django sprints!

- Wim

On Aug 26, 5:23 pm, Wim Feijen <wimfei...@gmail.com> wrote:
> Hello,
>
> In the past hour, I did some research on authenticating by email and I
> believe Django users would benefit a lot if email authentication was
> included in contrib.auth .
>
> Many people have been working on it, and the latest code I could find
> is here:https://gist.github.com/586056. I am not a very good Googler,
> so there may be better patches.
>
> Anyway, there are several problems to solve besides this:
> 1. the default AuthenticationForm does not accept usernames longer
> than 30 characters
> 2. UserCreationForm and possibly the UserChangeForm need to have Email
> counterparts or become more flexible
> 3. User emails should be unique. My first thought is to add a unique
> constraint depending on an optional AUTHENTICATE_BY_EMAIL setting
> which defaults to False. I find this problem the hardest to solve.
>
> I am really open to any suggestions, so please do.
>
> Luke Plant, Julien Phalip, I know you have looked into this before and
> I am really hoping you can share your thoughts as well.
>
> https://gist.github.com/586056:
>
> from django.contrib.auth.backends import ModelBackend
> from django.contrib.auth.models import User
>
> class EmailBackend(ModelBackend):
>
>     def authenticate(self, **credentials):
>         if 'username' in credentials:
>             return super(EmailBackend,
> self).authenticate(**credentials)
>
>         try:
>             user = User.objects.get(email=credentials.get('email'))
>             if user.check_password(credentials.get('password')):
>                 return user
>         except User.DoesNotExist:
>             return None

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

authentication by email

[Wim Feijen]

Hello,

In the past hour, I did some research on authenticating by email and I
believe Django users would benefit a lot if email authentication was
included in contrib.auth .

Many people have been working on it, and the latest code I could find
is here: https://gist.github.com/586056. I am not a very good Googler,
so there may be better patches.

Anyway, there are several problems to solve besides this:
1. the default AuthenticationForm does not accept usernames longer
than 30 characters
2. UserCreationForm and possibly the UserChangeForm need to have Email
counterparts or become more flexible
3. User emails should be unique. My first thought is to add a unique
constraint depending on an optional AUTHENTICATE_BY_EMAIL setting
which defaults to False. I find this problem the hardest to solve.

I am really open to any suggestions, so please do.

Luke Plant, Julien Phalip, I know you have looked into this before and
I am really hoping you can share your thoughts as well.


https://gist.github.com/586056:

from django.contrib.auth.backends import ModelBackend
from django.contrib.auth.models import User

class EmailBackend(ModelBackend):

def authenticate(self, **credentials):
if 'username' in credentials:
return super(EmailBackend,
self).authenticate(**credentials)

try:
user = User.objects.get(email=credentials.get('email'))
if user.check_password(credentials.get('password')):
return user
except User.DoesNotExist:
return None

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Forced password reset in django-admin

[Wim Feijen]

Hi Bejamin,

Sounds like a cool feature: probably when you build such a thing, it
will be used by dozens (or thousands). I noticed that I am making a
lot of use of custom registration processes. Most of the time, I use
django-registration as a solid basis, are you familiar with that?

Best regards,

Wim

On 30 jun, 12:08, benjaoming  wrote:
> Hello again!
>
> > What you have suggested here **is** an invasive change, because it
> > requires changes to existing code paths.
>
> I think the way to measure "invasive" is by means of backwards
> compatibility. We do not change required arguments, return value or
> model fields... The view normally responds with an
> HttpResponseRedirect object, and that's also the case here.
>
> > A setting is not a good way to
> > make something configurable here. A keyword argument here *would* be an
> > acceptable solution.
>
> You're right. Keywords argument is a good idea!
>
> > However, I don't think it would be that useful, because if it was off by
> > default, and controlled by a keyword argument, then the admin login view
> > wouldn't use it. I think this needs more thought.
>
> True! Actually this speaks against the use of a keyword argument as
> sole option.
>
> Keyword option: Local per-view behavior
> Setting variable: Project-wide behavior used when there is no kwarg
> present
>
> > Again, I should mention that features like this get implemented by the
> > community. If you need it, the way to do it is to build it, and then
> > persuade us to use it - not to try to persuade *us* to build it :-)
>
> I'm actually trying to persuade myself to build it in case there's
> enough support+discussion for it.
>
> > BTW - this doesn't actually force the password reset - it logs them in
> > and then asks them to change their password. If they don't they are
> > still logged in.
>
> Yup, that needs more thought!
>
> all the best,
> Benjamin

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django Error Display Page

[Wim Feijen]

For me, it would definitely be a good idea to change the error page a
bit, so at least the actual error message is not in grey but in black,
and bigger. People tend not to see it right now, because it looks
unimportant.

Wim

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Sprints DjangoCon Europe

[Wim Feijen]

More news about the sprints!

During the sprints we will have access to the Dialogue Cafe in de Waag
building (see: http://www.dialoguecafe.org/). Dialogue Cafe offers
facilities for video conferencing. Wouldn't it be great if we could
sprint all over the world? Actually, up to now, two locations outside
of Amsterdam have been opened, namely Lisbon (Portugal) and Rio de
Janeiro (Brazil). In addition, Ramallah (India) will probably open in
june, so maybe in time maybe not for the sprints.

My question right now is: do you know any programmers in (the vicinity
of) Lisbon, Rio de Janeiro or Ramallah? Who would be willing to attend
to the sprints and possibly help in organizing the local communities?

Please let me know. You can respond here or by private mail as well.

Thanks!

Wim

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: switch to HTML5 for bundled templates

[Wim Feijen]

+1. All major browsers now support html5 and by the time django 1.4
will be released we will be right on time though a bit late.

In response to Gabriel, in my opinion, legacy problems should not be
addressed by not moving forward, but they can be resolved by either 1.
updating or 2. staying on a legacy django both of which are legitimate
options.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: ANN: Django 1.3 release candidate available

[Wim Feijen]

Great work!

As the final release has not yet been announced, did something go
wrong?

Could you please post a small status update?

Thanks,

Wim

On Mar 4, 7:00 am, James Bennett  wrote:
> Tonight we're proud to announce the first release candidate for Django
> 1.3; if all goes well, the final release will happen in about a week.
>
> Details for the release candidate are available on the official Django weblog:
>
> http://www.djangoproject.com/weblog/2011/mar/03/13-rc/
>
> --
> "Bureaucrat Conrad, you are technically correct -- the best kind of correct."

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Benevolent Dicta^H^H^H Designer for Life

[Wim Feijen]

Hi Idan,

Those are two great topics, congratulations to you and to us :) and
good luck!

Wim

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

a default max_length

[Wim Feijen]

Hi,

How do you feel about having a default max_length value for a
models.CharField, so we can use it like:
class MyModel(models.Model):
example = models.CharField()
?

What are the pros and cons?

Wim

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: An idea to eliminate {% csrf token %}

[Wim Feijen]

Hi Luke,

Thanks for your quick response.

I've read the discussions about CSRF and SafeForm, in fact I already
did before posting my message. Because of your excellente wiki the
threads were easy to find.

I am not talking about SafeForm. I am sorry I wasn't clear before, but
in fact, what I want to propose is to include the lines:

by default when rendering a form with {{ form }}.

Would that be possible? I know of several unwanted side-effects, which
I believe we will be able to deal with using the reasoning in my first
post, but please correct me if I overlooked any loopholes.

I am looking forward to your response.

Thanks,

Wim


On Dec 31 2009, 2:29 am, Luke Plant  wrote:
> Hi Wim,
>
> Your suggestion sounds something like Simon's SafeForm.  While some
> elements of that proposal may end up in Django, it turns out that
> implementing SafeForm as the default solution requires *bigger*
> changes to existing code than adding the csrf_token, because you would
> need to pass additional info from the request to Form for it to be
> able to do the CSRF checks.  It also only works if you are using
> Django Forms and rendering them via {{ form }} (instead of field-by-
> field, for instance).
>
> If you want to see how we got to where we are, have a look at this
> thread:http://groups.google.com/group/django-
> developers/browse_thread/thread/3d2dc750082103dc/f3beb18c27fb7152
>
> (OK, that was a nasty trick - the thread is huge, we discussed this
> nearly to death, but that's why I'm not going to repeat all the
> arguments here).
>
> Also, you can use CsrfResponseMiddleware as an interim measure to stop
> your code from breaking, so the change to require csrf_token isn't
> quite so bad.
>
> Thanks,
>
> Luke
>
> --
> "It is a truth universally acknowledged, that a single man in
> possession of a good fortune, must be in want of a wife." (Jane
> Austen)
>
> Luke Plant ||http://lukeplant.me.uk/

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

idea for using RequestContext by default

[Wim Feijen]

Hello,

In the discussions on CSRF there have been several proposals to
include RequestContext by default in render_to_response or in a
similar function. As a side note to my previous post, I'd like to
mention my favorite way to do this: render_to , see:

http://www.djangosnippets.org/snippets/821/

Best regards,

Wim Feijen

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

An idea to eliminate {% csrf token %}

[Wim Feijen]

Hello,

For the past two days, I've been reading up on CSRF on the groups and
on the excellent wiki by Luke Plant, and giving it a lot of thought.
CRSF-protection should be on by default, that is clear.

What I want to talk about is whether we can make the implementation a
little bit less intrusive.

At the moment, (and please correct me if I am wrong), every form
template needs a {% csrf_token %} and RequestContext passed to it. As
I understand it, forms from existing, not yet upgraded applications
stop functioning. And every new form template written needs to include
the same extra variable {% csrf_token %} in the template.

Personally, I'd like to find a solution which requires less work by
the programmer and by default, handles all common cases, while any
rare cases still require conscious effort of the programmer. I really
recommend reading "Less is more", by 37 signals. My proposal for such
a solution is:

1. CSRF protection should be on by default.
2. Rendering {{ form }} should include the token by default.
3. When rendering a form "by hand", the token should be inserted by
the programmer. This works like rendering a formset; and I don't find
it beautiful, but workable.

Benefits are:
1. Old code works.
2. Writing a new template stays as simple as it is.

Drawbacks:
1. Public forms shouldn't be protected. In my views, when I render a
non-public form it is always preceded by either a login_required or a
permission_required decorator and I was thinking in the line of using
that as a trigger.
2. Forms which post to other sites should not leak the token.
Therefore, each Form should definitely have a optional argument
(enable_csfr = False). So the default is protect and the programmer
doesn't need to do anything about it, and there is an option to
disable the token on the form level. So, what happens if a programmer
forgets to disable the token? The form will leak the token. Now I'd
like to make some assumptions and these are:
a) most Django forms post to their own site.
b) when I post to a foreign site, I apparently trust the site and am
looking forward to cooperate with it. I consider it higly unlikely
that this site will intercept my token and use it for ill.
So in the case the programmer makes a mistake and forgets to disable
the token, it still is unlikely he endangers his site.

I really hope this may inspire you and help in implementing a less
intrusive way of CSRF-safe forms. As you, I am looking for a solution
which benefits us most and at the same time, has the least drawbacks.
Please correct me if I am wrong and take this message in the spirit it
is meant, that is: to describe an idea.

Best regards,

Wim Feijen

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django releases

[Wim Feijen]

Jacob, I am very glad this discussion is being held, and with such
good arguments.

My vote is +1, because I think Django needs another stable release
right now. Fortunately, the trunk is stable (thank you!). Rob says
that it is good for a software project to have regular releases on a
half-year basis and I totally agree. This gives everyone the
opportunity to use a recent version of Django. Right now,
unfortunately, people with strong demands on stability, have to revert
to an outdated Django 0.96 or take a risk using Django trunk, which
feels like a choice between two wrongs.

Personally, I would be very happy to use a Django 1.0, with or without
newforms, just as it happens. And considering the posts, just having
this discussion already seems to motivate people into action! :)

Wim

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---