Re: Change executed raw mysql queries to return timezone aware datetimes.

Also to directly answer the question, I'm talking abour cursor.execute() On Thursday, April 28, 2016 at 3:48:21 PM UTC-7, Bryce Drennan wrote: > > I'm wondering if we're using the term "global" slightly differently. > > Yes, prior to the changes removing converters, Django had these converters

Re: Change executed raw mysql queries to return timezone aware datetimes.

I'm wondering if we're using the term "global" slightly differently. Yes, prior to the changes removing converters, Django had these converters globally applied to all mysql connections that it created. However, they didn't apply to mysql connections created outside of django, nor did django

unique_together does not work as expected with nullable fields

I just got bitten by this today, finding a duplicate row where I didn't expect one. I haven't been able to find an existing Django bug. It's a popular topic on stack overflow: http://stackoverflow.com/questions/17510261/django-unique-together-constraint-failure

Re: is_authenticated as property

On Thursday, April 28, 2016 at 10:48:02 PM UTC+2, Shai Berger wrote: > > The problem with these suggestions is that they create a user object > during > checks, and that might be an obstacle for some users (side effects and > required > initializer parameters are the two most obvious

Re: is_authenticated as property

On Thursday, April 28, 2016 at 8:07:36 PM UTC+2, Markus Holtermann wrote: > > I haven't read the entire thread, did you account for custom user models > that don't inherit from AbstractBaseUser? Do the system checks stil > work? A Metaclass certainly would not, would it? Yeah, we probably

Re: is_authenticated as property

Right, right and right. Tim, I somehow missed that suggestion. It is certainly workable. Markus, Custom user classes which do not inherit AbstractBaseUser are a point I hadn't considered, and in fact they make my suggestions problematic, leaving _only_ the checks approach. However,

Re: Should Template.render() return a safe string?

> On 28 Apr 2016, at 20:37, Carl Meyer wrote: > > I don't have a clear enough sense of the use-cases for > autoescape-off to know what the behavior should be in that case. If the > primary use case is "rendering a template that isn't destined for the > browser anyway, so

Re: Should Template.render() return a safe string?

On 04/28/2016 11:46 AM, Aymeric Augustin wrote: >> On 28 Apr 2016, at 19:30, Aymeric Augustin >> wrote: >> >> It seems reasonable to assume that the result of rendering with >> autoescaping enabled is HTML-safe — that’s the reason why >> autoescaping exists. >

Re: is_authenticated as property

I haven't read the entire thread, did you account for custom user models that don't inherit from AbstractBaseUser? Do the system checks stil work? A Metaclass certainly would not, would it? Cheers, /Markus On Thu, Apr 28, 2016 at 10:56:37AM -0700, Florian Apolloner wrote: Are errors silence

Re: is_authenticated as property

Are errors silence able via SILENCED_SYSTEM_CHECKS? If yes, I am against it -- this has to be an hard unrecoverable error for security reasons or fully backwards compatible (I am leaning towards the latter if possible in any way). On Thursday, April 28, 2016 at 5:01:04 PM UTC+2, Tim Graham

Re: Should Template.render() return a safe string?

> On 28 Apr 2016, at 19:30, Aymeric Augustin > wrote: > > It seems reasonable to assume that the result of rendering with > autoescaping enabled is HTML-safe — that’s the reason why > autoescaping exists. Scratch that and let me try again: It seems

Re: Should Template.render() return a safe string?

Hi Carl, > On 28 Apr 2016, at 19:08, Carl Meyer wrote: > > Given that both templating > languages allow turning off autoescaping (or bypassing it in other > ways), there's no a priori reason to believe that a string resulting > from rendering a template is necessarily a safe

Re: Should Template.render() return a safe string?

Hi Aymeric, On 04/28/2016 11:02 AM, Aymeric Augustin wrote: > I just stumbled upon an interesting difference between Jinja2 and the > Django template language. > > |Template.render()| returns a safe string in Django. It's likely an > accident of the implementation more than a design choice. It

Should Template.render() return a safe string?

Hello, I just stumbled upon an interesting difference between Jinja2 and the Django template language. Template.render() returns a safe string in Django. It's likely an accident of the implementation more than a design choice. It happens because NodeList.render() calls mark_safe() on its

Re: is_authenticated as property

Do you think my suggestion of a system check to flag this is unacceptable? diff --git a/django/contrib/auth/checks.py b/django/contrib/auth/checks.py index d1b0a44..347ad75 100644 --- a/django/contrib/auth/checks.py +++ b/django/contrib/auth/checks.py @@ -73,6 +73,14 @@ def

Re: is_authenticated as property

On Monday 11 April 2016 20:13:02 Florian Apolloner wrote: > On Monday, April 11, 2016 at 6:57:46 PM UTC+2, Tim Graham wrote: > > I cannot think of much we could do besides monkey-patching the > > custom-user model. > > I would not call checking and rewriting the class in __new__ >

Re: is_authenticated as property

On Thursday, April 28, 2016 at 8:37:09 AM UTC+2, Sven R. Kunze wrote: > > Am Montag, 25. April 2016 10:38:23 UTC+2 schrieb Florian Apolloner: >> >> Absolutely not, what are you basing your justification on? >> > > The fact that I know real cases where this was a security issue. I'd > rather have

Re: is_authenticated as property

Am Montag, 25. April 2016 10:38:23 UTC+2 schrieb Florian Apolloner: > > Absolutely not, what are you basing your justification on? > The fact that I know real cases where this was a security issue. I'd rather have a backwards incompatibility than a security hole. But that may just be me. One