Most of the classes used by Django wouldn't be able to support
eval(repr(obj)) anyway, because nearly everything accepts complex types.
You'd have to recursively implement strict repr methods all the way up the
stack such that repr becomes too unwieldy for effective debugging.
If there are type
Report for week ending August 29, 2015:
Triaged
---
https://code.djangoproject.com/ticket/25296 - Failed Manager.create() could
pollute related models cache (accepted)
https://code.djangoproject.com/ticket/25305 - BIGINT auto field and related
(duplicate)
https://code.djangoproject.com
I'm going to fix ticket #23242 by adding an option to approximate the
date_hierarchy options instead of calculating them exactly. The
implementation is straightforward but I'm not sure what the interface
should be.
The basic idea is instead of doing `SELECT DISTINCT date_trunc('year',
created_at)
Yeah, that was why I pointed out django-registration already does this.
Last time I looked at user-signup apps, it seemed that was the common
practice, and also non-Django-powered sites I've used tend to do this.
Allowing variations in case to be different users raises a lot of problems
of potentia
The suggested change is to not allow a new user if there's a
username__iexact match.
On Saturday, August 29, 2015 at 2:56:14 PM UTC-4, James Bennett wrote:
>
> On Sat, Aug 29, 2015 at 1:54 PM, Florian Apolloner > wrote:
>
>> Which is? Following the ticket I do not see any clear consenus at all.
On Sat, Aug 29, 2015 at 1:54 PM, Florian Apolloner
wrote:
> Which is? Following the ticket I do not see any clear consenus at all. Imo
> Registration apps should handle that, which is not something Django ships
> with. I am -0 on changing the admin to disallow such users.
>
For what it's worth,
On Saturday, August 29, 2015 at 7:05:37 PM UTC+2, Tim Graham wrote:
>
> On the pull request, Fábio has raised the argument, "the __repr__ method
> should be unambiguous and eval(repr(obj)) == obj"
>
While the python docs (?!) recommend that, I hardly ever see any object
where you could eval t
On Saturday, August 29, 2015 at 7:08:45 PM UTC+2, Tim Graham wrote:
>
> I can't think of a reason not to make the suggested change. It seems like
> an odd requirement if a site *requires* allowing new usernames to be
> case-sensitive.
>
Which is? Following the ticket I do not see any clear con
On Saturday, August 29, 2015 at 7:32:44 PM UTC+2, Alex_Gaynor wrote:
>
> I would say no: this does _so_ little, and it's completely implementable
> outside of Django. Moreover, adding the middleware doesn't change any
> behavior, you still have to do a bunch of work in your app to actually
> i
On 29 août 2015, at 19:32, Alex Gaynor wrote:
> Moreover, adding the middleware doesn't change any behavior, you still have
> to do a bunch of work in your app to actually implement the not-tracking
> logic.
Indeed I’m afraid that people will believe that the middleware makes them
compliant,
I have been able to knock down the "Patches needing review" queue [1] to
about 10 tickets (excluding my own) and would like to make an offer:
If anyone submits a patch that makes a good effort to meet the patch review
checklist requirements [2] by Friday, September 4, I will do my best to
give
I would say no: this does _so_ little, and it's completely implementable
outside of Django. Moreover, adding the middleware doesn't change any
behavior, you still have to do a bunch of work in your app to actually
implement the not-tracking logic.
Alex
On Sat, Aug 29, 2015 at 1:17 PM, Tim Graham
from the ticket: DoNotTrack (DNT) is a HTTP request header, a proposed W3C
standard http://www.w3.org/TR/tracking-dnt/#dnt-header-field which is used
by the browsers to communicate user's preference on server-side profiling
or tacking. There is a number of 3rd party Django middlewares that add
It seems like a nice idea if the implementation is simple.
On Friday, August 28, 2015 at 9:11:27 AM UTC-4, Nick Sarbicki wrote:
>
> This takes the conversation back a ways...
>
> But I like the idea of being able to customise the admin scheme. Enforce a
> default of course, but maybe have some op
I can't think of a reason not to make the suggested change. It seems like
an odd requirement if a site *requires* allowing new usernames to be
case-sensitive.
On Saturday, August 29, 2015 at 12:27:39 PM UTC-4, Daniel Stanton wrote:
>
> Following the end of https://code.djangoproject.com/ticket/2
On the pull request, Fábio has raised the argument, "the __repr__ method
should be unambiguous and eval(repr(obj)) == obj".
Is this something we should strive for?
On Friday, August 28, 2015 at 9:18:04 PM UTC-4, Josh Smeaton wrote:
>
> Right, I agree with you in the case then. But I think the ge
Following the end of https://code.djangoproject.com/ticket/2273 over a year
ago, could this be reconsidered please?
By using username__iexact when checking for uniqueness for new usernames,
this wouldn't affect any usernames that already exist, and it's then up to
the administrators to decide i
17 matches
Mail list logo
