Fellow Report - April 2, 2016

2016-04-02 Thread Tim Graham 


Triaged

---

https://code.djangoproject.com/ticket/26413 - Abstract model inheritance 
regression with string model references in 1.9 (accepted)

https://code.djangoproject.com/ticket/26418 - models.URLField does not 
validate with an rtmp:// url (wontfix)

https://code.djangoproject.com/ticket/26424 - Allow URLValidator to skip 
schemes validation (created)

https://code.djangoproject.com/ticket/26422 - Django email validator does 
not support parentheses (duplicate)

https://code.djangoproject.com/ticket/26423 - Make EmailValidator use HTML5 
validation rather than more complicated regular expressions (created)

https://code.djangoproject.com/ticket/26432 - X/Y inverted when using 
numpy.reshape() on a GDALRaster's GDALBand (accepted)

https://code.djangoproject.com/ticket/26431 - translate_url() creates an 
incorrect URL when optional named groups are missing in the URL pattern 
(accepted)

https://code.djangoproject.com/ticket/26428 - Add support for relative path 
redirects to the test Client (accepted)

https://code.djangoproject.com/ticket/26435 - GeoIP2 return raw exception 
from geoip2 package (wontfix)

https://code.djangoproject.com/ticket/26436 - Error Reporting Howto should 
link to the sensitive keywords in the settings files (fixed)

https://code.djangoproject.com/ticket/26439 - ModelForm.save() should 
accept the "using" keyword argument (wontfix)

Authored



https://github.com/django/django/pull/6365 - Fixed #26428 -- Added support 
for relative path redirects in assertRedirects()

Reviewed/committed

--

https://github.com/django/django/pull/6348 - Fixed #21734 -- Handled 
ProtectedError on POST to admin's delete_selected action.

https://github.com/django/django/pull/6350 - Fixed #26415 -- Allowed 
deleting nodata value on GDALBands.

https://github.com/django/django/pull/6356 - Fixed #26417 -- Allowed 
setting GDALBand data with partial values.

https://github.com/django/django/pull/6355 - Fixed #26384 -- Fixed renaming 
the PK on a model with a self-referential FK on SQLite. 

https://github.com/django/django/pull/6346 - Fixed #11560 -- Allowed proxy 
model multiple-inheritance from the same concrete base model.

https://github.com/django/djangoproject.com/pull/648 - Added a language 
switcher for the documentation.

https://github.com/django/django/pull/6372 - Fixed #22268 -- Documented 
values_list() behavior for multivalued relations.

https://github.com/django/django/pull/6380 - Fixed #25699 -- Allowed using 
the test client if 'django.contrib.sessions' isn't in INSTALLED_APPS.

Reviews of core dev work



https://github.com/django/django/pull/6342 - Fixed #25532 -- Properly 
redisplayed invalid JSONField form input values.

https://github.com/django/django/pull/6347 - Fixed #10532 -- Relaxed 
hard-type checking in get_object/list_or_404 shortcuts

https://github.com/django/django/pull/6257 - Fixed #19567 -- Made 
javascript_catalog and json_catalog class-based views.

https://github.com/django/django/pull/6353 - Fixed #26413 -- Fixed a 
regression with abstract model inheritance and explicit parent links.

https://github.com/django/django/pull/6351 - Fixed #21446 -- Allowed the 
set_language() view to return HTTP 204 on AJAX requests.

https://github.com/django/django/pull/6215 - Fixed #19670 -- Applied 
CachedFilesMixin patterns to specific extensions

https://github.com/django/django/pull/4726 - Refs #3254 -- Added full text 
search to contrib.postgres.

https://github.com/django/django/pull/6292 - Fixed #26351 -- Added database 
check about MySQL sql_mode variable
https://github.com/django/django/pull/6369 - Fixed #26441 -- Added model 
Field.db_check() method.

-- 
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/49ef6734-32b7-4f5f-876e-23cc2ff7f82b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add HTML5 required attribute on form widgets

2016-04-02 Thread Jon Dufresne 
On Wed, Mar 30, 2016 at 7:01 AM, Alex Riina  wrote:

> What's the plan for formsets with extra?
>
> I could see the required only getting applied to the first min forms but
> I'm not sure there is an actual workable case there. It seems like it will
> get too messy with adding and deleting at the same time.
>
> If can_delete is false and extra is 0, it seems like the required
> attribute could at least be used. Because of this, I think it should
> probably be an initialization argument, default to false, or be overridden
> when constructing forms in formsets.
>
> https://github.com/gregmuellegger/django-floppyforms/issues/75
>
>
Thanks for highlighting this.

I'll investigate implementing the suggestion "If can_delete is false and
extra is 0, it seems like the required attribute could at least be used.
Because of this, I think it should probably be an initialization argument,
default to false, or be overridden when constructing forms in formsets."
Thanks.

I think with this concern, this feature can't be solved entirely by
template-base widgets as something other then Field.required is necessary
for the formset case.

Cheers,
Jon

-- 
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/CADhq2b5G_Bif-EB5C_XcQmLR_XZZboXOxmrc_Ja92rfEXfwydQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: geodjango.org status

2016-04-02 Thread Tim Graham 
I'm not sure if that domain is under the control of the Django Software 
Foundation. It might be registered by Justin Bronn, the original author of 
GeoDjango. It looks like Justin works at Counsyl, which explains the last 
retweet on the Twitter account.

On Saturday, April 2, 2016 at 10:12:22 AM UTC-4, Sylvain Fankhauser wrote:
>
> Hello,
>
> I'm working on issue #22274  
> and as part of this ticket I stumbled upon the domain geodjango.org 
> website. I don't think this adds any value to GeoDjango, and in fact this 
> is more a risk to confuse users by having an external website for a feature 
> that's part of Django. Also the Twitter account 
>  linked by this website doesn't really 
> seem active, not to mention the last tweet that's a bit weird.
>
> My proposal would be to keep the current domain and make it redirect to 
> the official GeoDjango docs, and add a link to the mailing list in the 
> official docs in a "Getting help" box, just like it's done in the Django 
> docs.
>
> What do you people think?
>
> Cheers,
> Sylvain
>

-- 
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/c16acf0e-82ea-4de5-b65c-e34e7a685c35%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Deprecating User.is_anonymous ?

2016-04-02 Thread Jon Dufresne 
> Do we know of any custom user models with this unconventional behaviour?

FWIW, I have a project with the following code snippet:

---

class AuthenticatedAnonymousUser(AnonymousUser):
def is_authenticated(self):
return True


class AnonymousAuthenticationMiddleware(AuthenticationMiddleware):
def process_request(self, request):
response = super().process_request(request)
if not response and not request.user.is_authenticated():
if check_api_auth():
request.user = AuthenticatedAnonymousUser()
else:
response = HttpResponseForbidden()
return response

---

This is a small, internal, private project. Users can access the app though
HTML pages by logging in (traditional web app) or through a user-less API.
Many scripts use the API.

This allows views to check user.is_authenticated(). This passes for the
AuthenticatedAnonymousUser, but the user is still treated as anonymous.

While I find this convenient, I could easily solve this some other way. But
I wanted to point out that this use exists.

Cheers,
Jon

-- 
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/CADhq2b4wYyGzND916rJdqYkMTAC%3DaJyzZXpOCP%3DbiWcEqMMp1A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Deprecating User.is_anonymous ?

2016-04-02 Thread Raffaele Salmaso 
On Sat, Apr 2, 2016 at 4:19 PM, Tim Graham  wrote:

> My concern is that if a project doesn't see the deprecation warnings
>
What about having a new property like User.authenticated (or
User.anonymous)?
User.is_anoymous and User.is_authenticated can be deprecate and removed
from docs, leaving them in place for longer (django 3).

-- 
| Raffaele Salmaso
| https://salmaso.org
| https://bitbucket.org/rsalmaso
| https://github.com/rsalmaso

-- 
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/CABgH4Ju981Ht-wpMZ1kyesGxCd7K6OhD5oNew8PSq8bdPR-SWw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Deprecating User.is_anonymous ?

2016-04-02 Thread Tim Graham 
Did you look into why both methods exist in the first place? I didn't know 
the reason.

is_anonymous() preceded is_authenticated(). The concern was that template 
code like this:

{% if not user.is_anonymous %}Content for logged in users.{% else %}Content for 
non-logged in users.{% endif %}


would show authenticated user content to anonymous users if the user 
variable didn't get put in the template context somehow [0]. 
User.is_authenticated() was added in Django 1.0 to mitigate this [1].

My concern is that if a project doesn't see the deprecation warnings and 
doesn't have adequate tests, they may not catch the fact that template code 
like:

{% if user.is_anonymous %}
Anonymous content
{% else %}
Authenticated content
{% endif %}

will start showing authenticated content to anonymous users after the 
method is removed. I think it's hard to argue that removing the method is 
work this risk. Maybe there's room to reduce confusion by deemphasizing 
usage of is_anonymous(). This might include removing its usage within 
Django itself and undocumenting it.

[0] http://thegarywilson.com/blog/2006/is_authenticated-vs-is_anonymous/
[1] https://github.com/django/django/commit/51705f60b1

On Saturday, April 2, 2016 at 9:37:38 AM UTC-4, Jeremy Lainé wrote:
>
> I have been working on solving #25847 (making User.is_authenticated a 
> property), and in the process I was wondering whether we want to keep 
> User.is_anonymous at all in the long run. 
>
> My reasoning is: 
>
> - the documentation makes it quite clear you should use 
> request.user.is_authenticated instead of request.user.is_anonymous 
>
> - there is no guarantee that request.user.is_authenticated != 
> request.user.is_anonymous. This means a custom user model could make a 
> User both anonymous and authenticated (or neither) and we would end up 
> with rather surprising results depending on how authentication is 
> checked (using is_authenticated or is_anonymous). 
>
> Do we know of any custom user models with this unconventional behaviour? 
>
> Incidentally I found there is only one place were we django uses 
> .is_anonymous internally : django.contrib.auth.backends.ModelBackend, 
> all other places use user.is_authenticated as recommended in the 
> documentation. 
>
> Thanks in advance for your insights! 
> Jeremy 
>
>

-- 
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/7726d8f7-210c-4a45-b52c-6d64fb60304a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

geodjango.org status

2016-04-02 Thread Sylvain Fankhauser 
Hello,

I'm working on issue #22274 
and as part of this ticket I stumbled upon the domain geodjango.org
website. I don't think this adds any value to GeoDjango, and in fact this
is more a risk to confuse users by having an external website for a feature
that's part of Django. Also the Twitter account
 linked by this website doesn't really seem
active, not to mention the last tweet that's a bit weird.

My proposal would be to keep the current domain and make it redirect to the
official GeoDjango docs, and add a link to the mailing list in the official
docs in a "Getting help" box, just like it's done in the Django docs.

What do you people think?

Cheers,
Sylvain

-- 
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/CAAXOc44isZJwbn6foPkP3eZhO-aYaeyat5RKh9%3DpGVE_dAjB%3Dw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Annotate date intervals or ranges

2016-04-02 Thread Shai Berger 
On Monday 07 March 2016 12:20:59 Josh Smeaton wrote:
> FYI I'm implementing date_trunc based transforms in this
> patch: https://github.com/django/django/pull/6243
> 
> Since the transform names "__month" "__year" etc are already taken by the
> Extract based transforms I've not yet implemented a lookup_name so that
> they can be used on the left hand side of filters
> (.filter(created__monthtrunc=..). If there is a decent proposal for trunc
> based lookup names, it'll be very easy to add them on.
> 
I find the name "trunc" is SQL-technical and opaque; and there's a need to 
explain the difference between, say, the extract transform (where 'year' gives 
an integer) and the trunc transforms which all give dates and datetimes, 
corresponding to the start of the named period.

So, I suggest we use "start".

birthdate__yearstart (midnight, january first on the birth date's year)

event__daystart (midnight before the event)

etc.

Re: Override the default form field for a model field

2016-04-02 Thread James Pic 
On Sat, Apr 2, 2016 at 10:44 AM, Florian Apolloner
 wrote:
> Yeah, I am also mostly worried about this. formfield for me is a quick
> shortcut, if you want to customize it, do it at the form level imo.

Does this mean we can close #26369 ?

-- 
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/CALC3Kadk0RGFPi%3DVqhdsTxsMP52mGheYie_DuG%3Dw4LkH34YOdg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Help needed & Status of DEP0005 (middleware handling)

2016-04-02 Thread Florian Apolloner 
Hi,

so here is a short update for DEP0005: I've moved from a branch on my 
private repository to a branch named dep0005 on Django to make it easier 
for core developers to push there and to allow others to easily make pull 
requests against it. The code as is works fine, the remaining tasks are 
basically to update tests and make sure that the middlewares Django ships 
work with both (old and newstyle middlewares) [oh, and docs, lot of docs 
;)]. If you want to work on any of the items, please pick one in 
https://github.com/django/django/pull/6371 and say so.

Thanks & cheers,
Florian

-- 
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/0888ccbf-6a58-4594-aecb-09bb39073279%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Override the default form field for a model field

2016-04-02 Thread Florian Apolloner 


On Thursday, March 17, 2016 at 2:17:40 PM UTC+1, Tim Graham wrote:
>
> It seems useful, but I'm not sure if it increases the coupling between 
> model and forms in an undesirable way?
>

Yeah, I am also mostly worried about this. formfield for me is a quick 
shortcut, if you want to customize it, do it at the form level imo.

-- 
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/7b9fe33f-b2e4-424e-bedc-426c1519068f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Value of tightening URLValidator/EmailValidator regular expressions?

2016-04-02 Thread Shai Berger 
On Saturday 02 April 2016 09:44:54 Josh Smeaton wrote:
> For what reason Zach? 

There is only one reason for which a strict and accurate validation is 
required, as far as I can see, and that is if your application is not just 
using existing email addresses (i.e. sending mail to users) but actually 
manages them (i.e. creates mail addresses).

Such applications are few and far between...

> Without a canonical regex implementation to copy or
> include, we're stuck poorly reimplementing a bunch of esoteric rules to
> what end? The main purpose of email validation is to provide relevant
> feedback to the user, and to guard against obviously bad or malicious data.
> "Looks vaguely like an email address" is probably too loose to be useful, I
> admit. The proposal to copy the regex from the html5 email input widget
> seems like a fine compromise to me.
> 
> We should also err on the side of allowing incorrect addresses rather than
> rejecting correct addresses. I'd much rather have bad signups that need to
> be done again rather than users that can't sign up with their valid
> addresses.
> 

...and their needs should not imply a high burden of maintenance on the rest 
of the community; they can and should implement their own validation.

+1 everything Josh said.

Shai.

Re: Value of tightening URLValidator/EmailValidator regular expressions?

2016-04-02 Thread Josh Smeaton 
For what reason Zach? Without a canonical regex implementation to copy or 
include, we're stuck poorly reimplementing a bunch of esoteric rules to 
what end? The main purpose of email validation is to provide relevant 
feedback to the user, and to guard against obviously bad or malicious data. 
"Looks vaguely like an email address" is probably too loose to be useful, I 
admit. The proposal to copy the regex from the html5 email input widget 
seems like a fine compromise to me.

We should also err on the side of allowing incorrect addresses rather than 
rejecting correct addresses. I'd much rather have bad signups that need to 
be done again rather than users that can't sign up with their valid 
addresses. 

On Saturday, 2 April 2016 05:07:38 UTC+11, Zach Borboa wrote:
>
> -1 on less strict validation. Saying we need less strict validation 
> because emails are usually confirmed by sending an email to it, is akin to 
> saying urls are only valid if the url can be fetched. "Looks vaguely like a 
> url" would not be enough for validation purposes. I believe we should 
> strive to keep a reasonably strict and correct email validator.
>

-- 
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/1cc42853-f289-40a3-ac88-5ff3cfc26f04%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.