Re: Consistent ordering of database Booleans

[Josh Smeaton]

I thought I'd responded to that ticket with a similar suggestion but I must 
have clicked away before submitting.

Yes, providing a transform would be ideal. Unfortunately order_by does not 
support __lookup syntax. Adding __lookup syntax support to F() is tracked 
here https://code.djangoproject.com/ticket/24747.

It shouldn't be a difficult ticket to solve, and that will provide 
everything needed to solve boolean consistent ordering.

Cheers

On Thursday, 3 December 2015 10:58:24 UTC+11, Shai Berger wrote:
>
> Hi, 
>
> A ticket[1] that was wontfix'd almost three years ago says, 
>
> """ 
> When using a model with a boolean field, you can retreive a QuerySet and 
> order 
> it on the boolean field. In Postgres, the true comes first, in SQLite, 
> false 
> comes first. 
> """ 
>
> The reason to wontfix was that this difference between database behaviors 
> would 
> require a lot of work for a relatively unimportant use-case -- a developer 
> switching between databases. 
>
> Since then, three things happened: 
>
> 1) A further comment on the ticket noting a more important use-case -- 
> pluggable apps; 
>
> 2) Since Django 1.7, it is easy to add transforms to the ORM, even ones 
> which 
> behave differently on different backends; 
>
> 3) Lately, in an additional comment on the ticket, user felipeochoa 
> suggested 
> a workaround (assume a model `Transaction` with a BooleanField 
> `submitted`): 
>
> Transaction.objects.annotate( 
> submitted_as_0_1=Case(When(submitted=True, then=Value(1)), 
>   default=Value(0), 
>  
>  output_field=PositiveSmallIntegerField()) 
> ).order_by('submitted_as_0_1') 
>
> I think we can combine the last two, and "solve" the issue with a 
> transform 
> defined on boolean fields, so that users will be able to write 
>
> Transaction.objects.order_by('submitted__consisitent_ordered') 
>
> Thoughts? 
>
> Shai. 
>
> [1] https://code.djangoproject.com/ticket/19726 
>

-- 
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/f77a4a51-6e4a-45aa-8499-c19ba5fee225%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: is_authenticated as property

[Josh Smeaton]

I agree with the ticket. The imbalance between is_superuser and 
is_authenticated() should be enough to consider updating the API. The 
security concerns and, in particular, Aymeric's Jinja example, make this 
ticket more compelling.

I think we should be asking.. why not? If there's not a good reason not to, 
let's make it a callable and a property.

On Thursday, 3 December 2015 09:09:54 UTC+11, Shai Berger wrote:
>
> On Wednesday 02 December 2015 18:51:03 Aymeric Augustin wrote: 
> > 
> > We could implement a property that returns an object: 
> > 
> > - that is still callable, for backwards compatibility 
> > - that evaluates correctly in a boolean context 
> > 
> > Then we can consider deprecating the ability to call it. 
> > 
> > 
> > class CallableBool: 
> > 
> > def __init__(self, value): 
> > self.value = value 
> > 
> > def __bool__(self): 
> > return self.value 
> > 
> > def __call__(self): 
> > return self.value 
> > 
> > def __repr__(self): 
> > return 'CallableBool(%r)' % self.value 
> > 
> > CallableFalse = CallableBool(False) 
> > 
> > CallableTrue = CallableBool(True) 
> > 
>
> More general alternative: 
>
> class IdempotentCallMixin(object): 
> def __call__(self): return self 
>
> However, you can't extend bool, so 
>
> class CallableBool(IdempotentCallMixin, bool): pass 
>
> does not work, and you'd have to do something like 
>
> class CallableBool(IdempotentCallMixin, int): pass 
>
> which is less nice (because of __repr__ etc) 
>
> 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/15da4606-c327-4b1e-bc1c-fc309c6955ba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: worth adding PyPy to continuous integration?

[Josh Smeaton]

Shouldn't we decide if we want to support pypy first? By putting it on CI 
that's an implicit agreement to support pypy potentially at the cost of 
certain features.

There's also the consideration that python2 is going away in django 2.0, so 
if pypy3 isn't up to date wrt python3, we'd have to drop pypy.

On Thursday, 3 December 2015 03:52:24 UTC+11, Marc Tamlyn wrote:
>
> If we can get it running on the CI reasonably easily I see no reason why 
> not.
>
> On 2 December 2015 at 16:46, Tim Graham  
> wrote:
>
>> Once in a while, we get a ticket about failures when running the Django 
>> test suite on PyPy. Sometimes they are bugs in PyPy, other times we use 
>> something that's not available or behaves differently in PyPy. Is it worth 
>> adding PyPy to our continuous integration so we can proactively address 
>> these issues?
>>
>> (We can't test with pypy3 since that's based on Python 3.2 which we've 
>> dropped support for in Django 1.9.)
>>
>> Recent tickets:
>> https://code.djangoproject.com/ticket/24779
>> https://code.djangoproject.com/ticket/25844
>>
>> Current failures with pypy 2.4.0 and Django 1.9:
>>
>> ==
>> ERROR: test_serialize_datetime (migrations.test_writer.WriterTests)
>> --
>> Traceback (most recent call last):
>>   File "/home/tim/code/django/tests/migrations/test_writer.py", line 248, 
>> in test_serialize_datetime
>> self.assertSerializedEqual(datetime.datetime.utcnow)
>>   File "/home/tim/code/django/tests/migrations/test_writer.py", line 179, 
>> in assertSerializedEqual
>> self.assertEqual(self.serialize_round_trip(value), value)
>>   File "/home/tim/code/django/tests/migrations/test_writer.py", line 175, 
>> in serialize_round_trip
>> string, imports = MigrationWriter.serialize(value)
>>   File "/home/tim/code/django/django/db/migrations/writer.py", line 540, 
>> in serialize
>> "topics/migrations/#migration-serializing" % (value, 
>> get_docs_version())
>> ValueError: Cannot serialize: > 'datetime.datetime'>>
>> There are some values Django cannot serialize into migration files.
>> For more, see 
>> https://docs.djangoproject.com/en/dev/topics/migrations/#migration-serializing
>>
>> ==
>> ERROR: test_simple_migration (migrations.test_writer.WriterTests)
>> --
>> Traceback (most recent call last):
>>   File "/home/tim/code/django/tests/migrations/test_writer.py", line 459, 
>> in test_simple_migration
>> output = writer.as_string()
>>   File "/home/tim/code/django/django/db/migrations/writer.py", line 167, 
>> in as_string
>> operation_string, operation_imports = 
>> OperationWriter(operation).serialize()
>>   File "/home/tim/code/django/django/db/migrations/writer.py", line 124, 
>> in serialize
>> _write(arg_name, arg_value)
>>   File "/home/tim/code/django/django/db/migrations/writer.py", line 76, 
>> in _write
>> arg_string, arg_imports = MigrationWriter.serialize(item)
>>   File "/home/tim/code/django/django/db/migrations/writer.py", line 357, 
>> in serialize
>> item_string, item_imports = cls.serialize(item)
>>   File "/home/tim/code/django/django/db/migrations/writer.py", line 433, 
>> in serialize
>> return cls.serialize_deconstructed(path, args, kwargs)
>>   File "/home/tim/code/django/django/db/migrations/writer.py", line 318, 
>> in serialize_deconstructed
>> arg_string, arg_imports = cls.serialize(arg)
>>   File "/home/tim/code/django/django/db/migrations/writer.py", line 540, 
>> in serialize
>> "topics/migrations/#migration-serializing" % (value, 
>> get_docs_version())
>> ValueError: Cannot serialize: > 'datetime.datetime'>>
>> There are some values Django cannot serialize into migration files.
>> For more, see 
>> https://docs.djangoproject.com/en/dev/topics/migrations/#migration-serializing
>>
>> ==
>> ERROR: test_band_data_setters 
>> (gis_tests.gdal_tests.test_raster.GDALBandTests)
>> --
>> Traceback (most recent call last):
>>   File "/home/tim/code/django/tests/gis_tests/gdal_tests/test_raster.py", 
>> line 357, in test_band_data_setters
>> bandmem.data(packed_block, (1, 1), (2, 2))
>>   File "/home/tim/code/django/django/contrib/gis/gdal/raster/band.py", 
>> line 133, in data
>> data_array = ctypes_array.from_buffer_copy(data)
>> AttributeError: type object 'c_ubyte_Array_4' has no attribute 
>> 'from_buffer_copy'
>>
>> ==
>> FAIL: test_prefetch_related_queryset 
>> (model_forms.tests.OtherModelFormTests)
>> --
>> Traceback (most recent call 

Consistent ordering of database Booleans

[Shai Berger]

Hi,

A ticket[1] that was wontfix'd almost three years ago says,

"""
When using a model with a boolean field, you can retreive a QuerySet and order 
it on the boolean field. In Postgres, the true comes first, in SQLite, false 
comes first.
"""

The reason to wontfix was that this difference between database behaviors would 
require a lot of work for a relatively unimportant use-case -- a developer 
switching between databases.

Since then, three things happened:

1) A further comment on the ticket noting a more important use-case -- 
pluggable apps;

2) Since Django 1.7, it is easy to add transforms to the ORM, even ones which 
behave differently on different backends;

3) Lately, in an additional comment on the ticket, user felipeochoa suggested 
a workaround (assume a model `Transaction` with a BooleanField `submitted`):

Transaction.objects.annotate(
submitted_as_0_1=Case(When(submitted=True, then=Value(1)),
  default=Value(0),
  output_field=PositiveSmallIntegerField())
).order_by('submitted_as_0_1')

I think we can combine the last two, and "solve" the issue with a transform 
defined on boolean fields, so that users will be able to write

Transaction.objects.order_by('submitted__consisitent_ordered')

Thoughts?

Shai.

[1] https://code.djangoproject.com/ticket/19726

Re: Migration "rebase", or just an "undo" that works with conflicts

[Andrew Godwin]

As long as whatever tool we have fails hard rather than doing weird things
with related dependencies, I'm in favour of automating the process more -
we should reduce friction around migrations wherever possible.

As for undoing a conflicted migration, it should be relatively simple to
make the twin-tip check on the migrate command if you're asking to reverse
one of those tips; that should solve that issue.

Andrew

On Wed, Dec 2, 2015 at 2:48 PM, Shai Berger  wrote:

> On Tuesday 01 December 2015 08:40:34 Andrew Godwin wrote:
> > You can undo a migration manually using migrate, though if you're in
> > multiple-tip-migration scenario you may need to make a merge migration
> > first (but not apply it) or switch to a branch with only the migration
> you
> > wish to undo.
> >
>
> Yep. But this is highly unintuitive: "To fix it, first make things worse".
>
> > The more general rebase command would be interesting, though I've always
> > been wary about adding one, as it's not a guarantee we can always keep -
> > some operations are irreversible, and in Django's case, a migration may
> not
> > be undoable without other related migrations for foreignkeys, so
> deleting a
> > migration would likely require deletion of those target migrations as
> well,
> > potentially?
> >
>
> Oh, I'd definitely not want that. If, in order to rebase a migration, I'd
> find
> that I need to roll other migrations back, I'd expect the rebase to fail.
>
> Similarly, if I get my "conflict-resistant undo", I'd expect it to require
> that
> the migration can be rolled back on its own. If others are dependent on it,
> they should be rolled back explicitly -- I'd really like to minimize
> automatic
> decision-making in a less-than-stable state.
>
> 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/CAFwN1urCWHouZ85ZvTNK3%3D-%3D1Bn4W83b3Pnr7bBZ8PYeVaL%2BJQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migration "rebase", or just an "undo" that works with conflicts

[Shai Berger]

On Tuesday 01 December 2015 08:40:34 Andrew Godwin wrote:
> You can undo a migration manually using migrate, though if you're in
> multiple-tip-migration scenario you may need to make a merge migration
> first (but not apply it) or switch to a branch with only the migration you
> wish to undo.
> 

Yep. But this is highly unintuitive: "To fix it, first make things worse".

> The more general rebase command would be interesting, though I've always
> been wary about adding one, as it's not a guarantee we can always keep -
> some operations are irreversible, and in Django's case, a migration may not
> be undoable without other related migrations for foreignkeys, so deleting a
> migration would likely require deletion of those target migrations as well,
> potentially?
> 

Oh, I'd definitely not want that. If, in order to rebase a migration, I'd find 
that I need to roll other migrations back, I'd expect the rebase to fail. 

Similarly, if I get my "conflict-resistant undo", I'd expect it to require that 
the migration can be rolled back on its own. If others are dependent on it, 
they should be rolled back explicitly -- I'd really like to minimize automatic 
decision-making in a less-than-stable state.

Shai.

Re: annoyance with Python 3.2 support in Django 1.8

[Shai Berger]

On Wednesday 02 December 2015 21:05:00 Tim Graham wrote:
> 
> Given that no one reading this indicated that they plan a long-term
> deployment of Python 3.2, how about if in the next 1.8.x release we
> advertise that Python 3.2 support for Django 1.8 will end January 1, 2017?
> (we won't break anything intentionally after that, but we won't have to
> worry about testing and can spin down our 12.04 machine before it's EOL a
> few months later)
> 

Since you brought the issue up yourself -- shouldn't we "swap" PyPy3 for 
Python 3.2? Would that make running tests on ubuntu 14.04 easier?

Just a half-baked thought,

Shai.

Re: is_authenticated as property

[Shai Berger]

On Wednesday 02 December 2015 18:51:03 Aymeric Augustin wrote:
> 
> We could implement a property that returns an object:
> 
> - that is still callable, for backwards compatibility
> - that evaluates correctly in a boolean context
> 
> Then we can consider deprecating the ability to call it.
> 
> 
> class CallableBool:
> 
> def __init__(self, value):
> self.value = value
> 
> def __bool__(self):
> return self.value
> 
> def __call__(self):
> return self.value
> 
> def __repr__(self):
> return 'CallableBool(%r)' % self.value
> 
> CallableFalse = CallableBool(False)
> 
> CallableTrue = CallableBool(True)
> 

More general alternative:

class IdempotentCallMixin(object):
def __call__(self): return self

However, you can't extend bool, so

class CallableBool(IdempotentCallMixin, bool): pass

does not work, and you'd have to do something like

class CallableBool(IdempotentCallMixin, int): pass

which is less nice (because of __repr__ etc)

Shai

Re: __ne, #5763

[Carsten Fuchs]

Dear Anssi,

Am 2015-11-22 um 13:53 schrieb Anssi Kääriäinen:

The author_count name suggested this was an aggregation. If this is just
a regular field, then things are a bit simpler. Note that negated
Q-object + filter and exclude() queries are the same thing.

[...]

There is a fix for exactly this issue in pr
https://github.com/django/django/pull/4385. After the pr, you could just
use .filter(Q(entry__tags__name='django')&~Q(entry__author_count=2)).


Sorry for my late reply, and many thanks for yours, it's very much 
appreciated!  :-)


Best regards,
Carsten

--
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/565F6B69.4070800%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: annoyance with Python 3.2 support in Django 1.8

[Tim Graham]

I ran into another snag trying to put the Python 3.2 tests on the 14.04 
machines and that's that the unittest-xml-reporting package we use on 
Jenkins to collect the test results isn't compatible with Python 3.2 (the 
Ubuntu 12.04 machine uses an older fork of unittest-xml-reporting but I 
removed that hack on the 14.04 machines). Maybe I could find an older 
official version of unittest-xml-reporting that would work, but I don't 
think I'm adding any value with this exercise.

Given that no one reading this indicated that they plan a long-term 
deployment of Python 3.2, how about if in the next 1.8.x release we 
advertise that Python 3.2 support for Django 1.8 will end January 1, 2017? 
(we won't break anything intentionally after that, but we won't have to 
worry about testing and can spin down our 12.04 machine before it's EOL a 
few months later) 

On Thursday, November 26, 2015 at 9:53:51 AM UTC-5, Donald Stufft wrote:
>
>
> On Nov 26, 2015, at 9:50 AM, Tim Graham  
> wrote:
>
> The thing that makes me a little uncomfortable is promoting the use of 
> possibly insecure Python 3.2 well after it's end-of-life. I guess there 
> might be some Linux distributions that will backport security fixes to 
> their own versions of Python 3.2, but it seems that Ubuntu 12.04's version 
> of Python 3.2 didn't incorporate the security fix which caused breakage.
>
>
> FTR the next major version of pip does not support Python 3.2.
>
> -
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 
> DCFA 
>
>

-- 
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/cff4be08-fcb7-40dc-b450-0392bade6482%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Referrer Policy Delivery, Django shouldn't do strict referrer check anymore?

[Collin Anderson]

Seems to me we could ignore the referrer if we get a valid same-domain
Origin header.

On Wed, Dec 2, 2015 at 1:29 PM, Flávio Junior 
wrote:

> Some browsers already implement the Referrer Policy draft
> ,
> which gives the developer more control over the referer HTTP header sent by
> the browser. Sometimes is useful to set a more private policy, like *Origin
> When Cross-Origin*, to prevent disclosing sensitive URL info to a
> third-party, like a password reset token for example.
>
> But one can't just set the policy to *Origin When Cross-Origin*, because
> it will break on Safari, since Safari doesn't adhere to newest spec and
> defaults to no-referrer, which breaks form submits on HTTPS because of
> Django strict referrer check. Also, I can't imagine now why, but some
> developer might want to disable referer header altogether, and can easily
> do so by setting policy to *No Referrer*. See the rationale
> 
> behind strict referrer check and the code
> 
> .
>
> Maybe Django shouldn't do do strict referrer check anymore?
> It's very strange to change a HTML meta tag and break everything. And
> break in staging specifically, because this happens only on secure requests.
>
> If Django still needs
>  the strict
> referrer check, maybe a better error message should be implemented.
>
> --
> 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/3dcbec32-b180-4cba-9276-731946fdccf6%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/CAFO84S60yWrKp4Q79UtnoxvnQvfwnyfD-BFjphfZZ4TL4q9Tdg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Referrer Policy Delivery, Django shouldn't do strict referrer check anymore?

[Flávio Junior]

Some browsers already implement the Referrer Policy draft 
, 
which gives the developer more control over the referer HTTP header sent by 
the browser. Sometimes is useful to set a more private policy, like *Origin 
When Cross-Origin*, to prevent disclosing sensitive URL info to a 
third-party, like a password reset token for example.

But one can't just set the policy to *Origin When Cross-Origin*, because it 
will break on Safari, since Safari doesn't adhere to newest spec and 
defaults to no-referrer, which breaks form submits on HTTPS because of 
Django strict referrer check. Also, I can't imagine now why, but some 
developer might want to disable referer header altogether, and can easily 
do so by setting policy to *No Referrer*. See the rationale 
 
behind strict referrer check and the code 

.

Maybe Django shouldn't do do strict referrer check anymore?
It's very strange to change a HTML meta tag and break everything. And break 
in staging specifically, because this happens only on secure requests.

If Django still needs 
 the strict referrer 
check, maybe a better error message should be implemented.

-- 
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/3dcbec32-b180-4cba-9276-731946fdccf6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: worth adding PyPy to continuous integration?

[Marc Tamlyn]

If we can get it running on the CI reasonably easily I see no reason why
not.

On 2 December 2015 at 16:46, Tim Graham  wrote:

> Once in a while, we get a ticket about failures when running the Django
> test suite on PyPy. Sometimes they are bugs in PyPy, other times we use
> something that's not available or behaves differently in PyPy. Is it worth
> adding PyPy to our continuous integration so we can proactively address
> these issues?
>
> (We can't test with pypy3 since that's based on Python 3.2 which we've
> dropped support for in Django 1.9.)
>
> Recent tickets:
> https://code.djangoproject.com/ticket/24779
> https://code.djangoproject.com/ticket/25844
>
> Current failures with pypy 2.4.0 and Django 1.9:
>
> ==
> ERROR: test_serialize_datetime (migrations.test_writer.WriterTests)
> --
> Traceback (most recent call last):
>   File "/home/tim/code/django/tests/migrations/test_writer.py", line 248,
> in test_serialize_datetime
> self.assertSerializedEqual(datetime.datetime.utcnow)
>   File "/home/tim/code/django/tests/migrations/test_writer.py", line 179,
> in assertSerializedEqual
> self.assertEqual(self.serialize_round_trip(value), value)
>   File "/home/tim/code/django/tests/migrations/test_writer.py", line 175,
> in serialize_round_trip
> string, imports = MigrationWriter.serialize(value)
>   File "/home/tim/code/django/django/db/migrations/writer.py", line 540,
> in serialize
> "topics/migrations/#migration-serializing" % (value,
> get_docs_version())
> ValueError: Cannot serialize:  'datetime.datetime'>>
> There are some values Django cannot serialize into migration files.
> For more, see
> https://docs.djangoproject.com/en/dev/topics/migrations/#migration-serializing
>
> ==
> ERROR: test_simple_migration (migrations.test_writer.WriterTests)
> --
> Traceback (most recent call last):
>   File "/home/tim/code/django/tests/migrations/test_writer.py", line 459,
> in test_simple_migration
> output = writer.as_string()
>   File "/home/tim/code/django/django/db/migrations/writer.py", line 167,
> in as_string
> operation_string, operation_imports =
> OperationWriter(operation).serialize()
>   File "/home/tim/code/django/django/db/migrations/writer.py", line 124,
> in serialize
> _write(arg_name, arg_value)
>   File "/home/tim/code/django/django/db/migrations/writer.py", line 76, in
> _write
> arg_string, arg_imports = MigrationWriter.serialize(item)
>   File "/home/tim/code/django/django/db/migrations/writer.py", line 357,
> in serialize
> item_string, item_imports = cls.serialize(item)
>   File "/home/tim/code/django/django/db/migrations/writer.py", line 433,
> in serialize
> return cls.serialize_deconstructed(path, args, kwargs)
>   File "/home/tim/code/django/django/db/migrations/writer.py", line 318,
> in serialize_deconstructed
> arg_string, arg_imports = cls.serialize(arg)
>   File "/home/tim/code/django/django/db/migrations/writer.py", line 540,
> in serialize
> "topics/migrations/#migration-serializing" % (value,
> get_docs_version())
> ValueError: Cannot serialize:  'datetime.datetime'>>
> There are some values Django cannot serialize into migration files.
> For more, see
> https://docs.djangoproject.com/en/dev/topics/migrations/#migration-serializing
>
> ==
> ERROR: test_band_data_setters
> (gis_tests.gdal_tests.test_raster.GDALBandTests)
> --
> Traceback (most recent call last):
>   File "/home/tim/code/django/tests/gis_tests/gdal_tests/test_raster.py",
> line 357, in test_band_data_setters
> bandmem.data(packed_block, (1, 1), (2, 2))
>   File "/home/tim/code/django/django/contrib/gis/gdal/raster/band.py",
> line 133, in data
> data_array = ctypes_array.from_buffer_copy(data)
> AttributeError: type object 'c_ubyte_Array_4' has no attribute
> 'from_buffer_copy'
>
> ==
> FAIL: test_prefetch_related_queryset
> (model_forms.tests.OtherModelFormTests)
> --
> Traceback (most recent call last):
>   File "/home/tim/code/django/tests/model_forms/tests.py", line 2308, in
> test_prefetch_related_queryset
> (red_item.pk, 'red'),
>   File "/home/tim/code/django/django/test/testcases.py", line 93, in
> __exit__
> query['sql'] for query in self.captured_queries
> AssertionError: 2 queries executed, 4 expected
> Captured queries were:
> SELECT "model_forms_colourfulitem"."id",
> "model_forms_colourfulitem"."name" FROM "model_forms_colourfulitem"
> SELECT 

Re: is_authenticated as property

[Aymeric Augustin]

Django 1.8 worsens the situation significantly:

{% if request.user.is_authenticated %}

does the right thing in a Django template but is a security vulnerability
in a Jinja2 template!

We could implement a property that returns an object:

- that is still callable, for backwards compatibility
- that evaluates correctly in a boolean context

Then we can consider deprecating the ability to call it.


class CallableBool:

def __init__(self, value):
self.value = value

def __bool__(self):
return self.value

def __call__(self):
return self.value

def __repr__(self):
return 'CallableBool(%r)' % self.value

CallableFalse = CallableBool(False)

CallableTrue = CallableBool(True)


It's a bit of a hack, but what Pythonista doesn't like using Python like
that? ;-)

-- 
Aymeric.


2015-12-02 15:39 GMT+01:00 Collin Anderson :

> On a somewhat unrelated note, is_authenticated really only makes sense
> when using request.user.is_authenticated. If you simply query a user from
> the database, is_authenticated will be True, which doesn't make any sense
> outside the context of a request. is_anonymous makes
> sense, is_authenticated doesn't work as well.
>
> On Wed, Dec 2, 2015 at 9:19 AM, Tim Graham  wrote:
>
>> Someone created a ticket to raise this issue again. I found several
>> improper usages with GitHub code search. Is there any support for the idea
>> or would it be too much magic? My own opinion is that if you don't have
>> tests to catch the mistake in the first place, you're doing it wrong.
>>
>> https://code.djangoproject.com/ticket/25847
>>
>> On Thursday, April 10, 2008 at 1:06:37 PM UTC-4, David Cramer wrote:
>>>
>>> I wouldn't say insecure, but its a big gotcha. I've done it a quite a
>>> few times where I forgot the () :)
>>>
>>> On Apr 10, 5:53 am, Thomas Guettler  wrote:
>>> > Hi,
>>> >
>>> > is_staff, is_active, is_superuser are attributes.
>>> >
>>> > is_anonymous, is_authenticated are methods.
>>> >
>>> > This is insecure if you are not careful while programming:
>>> >
>>> > if user.is_authenticated:
>>> > # Always true, since it is a method!
>>> >
>>> > It would be nice to find a solution. Here is what I thought:
>>> >
>>> > Make is_authenticated a property which returns a object
>>> > which evaluates to the proper boolean value. This object
>>> > has a method __call__ which returns the same value.
>>> >
>>> > This is backwards compatible.
>>> >
>>> >  Thomas
>>> >
>>> > --
>>> > Thomas Guettler,http://www.thomas-guettler.de/
>>> > E-Mail: guettli (*) 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/df236217-bc38-4ceb-8d1e-1da18268c81c%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/CAFO84S7AWu_0a4nPS%3DsZAxwy3MvXXYg%3DqBbwKDHwrhD-rVpWag%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  (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/CANE-7mVc9%3Dy55CEK2Y6gCdz0Ye0zOXhiBiQAGDDY7pkQ7hxFpg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

worth adding PyPy to continuous integration?

[Tim Graham]

Once in a while, we get a ticket about failures when running the Django 
test suite on PyPy. Sometimes they are bugs in PyPy, other times we use 
something that's not available or behaves differently in PyPy. Is it worth 
adding PyPy to our continuous integration so we can proactively address 
these issues?

(We can't test with pypy3 since that's based on Python 3.2 which we've 
dropped support for in Django 1.9.)

Recent tickets:
https://code.djangoproject.com/ticket/24779
https://code.djangoproject.com/ticket/25844

Current failures with pypy 2.4.0 and Django 1.9:

==
ERROR: test_serialize_datetime (migrations.test_writer.WriterTests)
--
Traceback (most recent call last):
  File "/home/tim/code/django/tests/migrations/test_writer.py", line 248, 
in test_serialize_datetime
self.assertSerializedEqual(datetime.datetime.utcnow)
  File "/home/tim/code/django/tests/migrations/test_writer.py", line 179, 
in assertSerializedEqual
self.assertEqual(self.serialize_round_trip(value), value)
  File "/home/tim/code/django/tests/migrations/test_writer.py", line 175, 
in serialize_round_trip
string, imports = MigrationWriter.serialize(value)
  File "/home/tim/code/django/django/db/migrations/writer.py", line 540, in 
serialize
"topics/migrations/#migration-serializing" % (value, get_docs_version())
ValueError: Cannot serialize: >
There are some values Django cannot serialize into migration files.
For more, see 
https://docs.djangoproject.com/en/dev/topics/migrations/#migration-serializing

==
ERROR: test_simple_migration (migrations.test_writer.WriterTests)
--
Traceback (most recent call last):
  File "/home/tim/code/django/tests/migrations/test_writer.py", line 459, 
in test_simple_migration
output = writer.as_string()
  File "/home/tim/code/django/django/db/migrations/writer.py", line 167, in 
as_string
operation_string, operation_imports = 
OperationWriter(operation).serialize()
  File "/home/tim/code/django/django/db/migrations/writer.py", line 124, in 
serialize
_write(arg_name, arg_value)
  File "/home/tim/code/django/django/db/migrations/writer.py", line 76, in 
_write
arg_string, arg_imports = MigrationWriter.serialize(item)
  File "/home/tim/code/django/django/db/migrations/writer.py", line 357, in 
serialize
item_string, item_imports = cls.serialize(item)
  File "/home/tim/code/django/django/db/migrations/writer.py", line 433, in 
serialize
return cls.serialize_deconstructed(path, args, kwargs)
  File "/home/tim/code/django/django/db/migrations/writer.py", line 318, in 
serialize_deconstructed
arg_string, arg_imports = cls.serialize(arg)
  File "/home/tim/code/django/django/db/migrations/writer.py", line 540, in 
serialize
"topics/migrations/#migration-serializing" % (value, get_docs_version())
ValueError: Cannot serialize: >
There are some values Django cannot serialize into migration files.
For more, see 
https://docs.djangoproject.com/en/dev/topics/migrations/#migration-serializing

==
ERROR: test_band_data_setters 
(gis_tests.gdal_tests.test_raster.GDALBandTests)
--
Traceback (most recent call last):
  File "/home/tim/code/django/tests/gis_tests/gdal_tests/test_raster.py", 
line 357, in test_band_data_setters
bandmem.data(packed_block, (1, 1), (2, 2))
  File "/home/tim/code/django/django/contrib/gis/gdal/raster/band.py", line 
133, in data
data_array = ctypes_array.from_buffer_copy(data)
AttributeError: type object 'c_ubyte_Array_4' has no attribute 
'from_buffer_copy'

==
FAIL: test_prefetch_related_queryset (model_forms.tests.OtherModelFormTests)
--
Traceback (most recent call last):
  File "/home/tim/code/django/tests/model_forms/tests.py", line 2308, in 
test_prefetch_related_queryset
(red_item.pk, 'red'),
  File "/home/tim/code/django/django/test/testcases.py", line 93, in 
__exit__
query['sql'] for query in self.captured_queries
AssertionError: 2 queries executed, 4 expected
Captured queries were:
SELECT "model_forms_colourfulitem"."id", "model_forms_colourfulitem"."name" 
FROM "model_forms_colourfulitem"
SELECT ("model_forms_colourfulitem_colours"."colourfulitem_id") AS 
"_prefetch_related_val_colourfulitem_id", "model_forms_colour"."id", 
"model_forms_colour"."name" FROM "model_forms_colour" INNER JOIN 
"model_forms_colourfulitem_colours" ON ("model_forms_colour"."id" = 
"model_forms_colourfulitem_colours"."colour_id") WHERE 
"model_forms_colourfulitem_colours"."colourfulitem_id" IN (1, 2)

Re: is_authenticated as property

[Collin Anderson]

On a somewhat unrelated note, is_authenticated really only makes sense when
using request.user.is_authenticated. If you simply query a user from the
database, is_authenticated will be True, which doesn't make any sense
outside the context of a request. is_anonymous makes
sense, is_authenticated doesn't work as well.

On Wed, Dec 2, 2015 at 9:19 AM, Tim Graham  wrote:

> Someone created a ticket to raise this issue again. I found several
> improper usages with GitHub code search. Is there any support for the idea
> or would it be too much magic? My own opinion is that if you don't have
> tests to catch the mistake in the first place, you're doing it wrong.
>
> https://code.djangoproject.com/ticket/25847
>
> On Thursday, April 10, 2008 at 1:06:37 PM UTC-4, David Cramer wrote:
>>
>> I wouldn't say insecure, but its a big gotcha. I've done it a quite a
>> few times where I forgot the () :)
>>
>> On Apr 10, 5:53 am, Thomas Guettler  wrote:
>> > Hi,
>> >
>> > is_staff, is_active, is_superuser are attributes.
>> >
>> > is_anonymous, is_authenticated are methods.
>> >
>> > This is insecure if you are not careful while programming:
>> >
>> > if user.is_authenticated:
>> > # Always true, since it is a method!
>> >
>> > It would be nice to find a solution. Here is what I thought:
>> >
>> > Make is_authenticated a property which returns a object
>> > which evaluates to the proper boolean value. This object
>> > has a method __call__ which returns the same value.
>> >
>> > This is backwards compatible.
>> >
>> >  Thomas
>> >
>> > --
>> > Thomas Guettler,http://www.thomas-guettler.de/
>> > E-Mail: guettli (*) 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/df236217-bc38-4ceb-8d1e-1da18268c81c%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/CAFO84S7AWu_0a4nPS%3DsZAxwy3MvXXYg%3DqBbwKDHwrhD-rVpWag%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: is_authenticated as property

[Tom Christie]

> My own opinion is that if you don't have tests to catch the mistake in 
the first place, you're doing it wrong.

Not sure I'd necessarily agree there - easy to miss the anonymous case.

No obvious best thing to do tho'.

On the one hand it's too easy to get wrong, on the other the current visual 
distinction between the model fields, and model methods may be helpful.

-- 
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/cae9c6ce-57bb-43de-961a-5f5b86ae776b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: is_authenticated as property

[Tim Graham]

Someone created a ticket to raise this issue again. I found several 
improper usages with GitHub code search. Is there any support for the idea 
or would it be too much magic? My own opinion is that if you don't have 
tests to catch the mistake in the first place, you're doing it wrong.

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

On Thursday, April 10, 2008 at 1:06:37 PM UTC-4, David Cramer wrote:
>
> I wouldn't say insecure, but its a big gotcha. I've done it a quite a 
> few times where I forgot the () :) 
>
> On Apr 10, 5:53 am, Thomas Guettler  wrote: 
> > Hi, 
> > 
> > is_staff, is_active, is_superuser are attributes. 
> > 
> > is_anonymous, is_authenticated are methods. 
> > 
> > This is insecure if you are not careful while programming: 
> > 
> > if user.is_authenticated: 
> > # Always true, since it is a method! 
> > 
> > It would be nice to find a solution. Here is what I thought: 
> > 
> > Make is_authenticated a property which returns a object 
> > which evaluates to the proper boolean value. This object 
> > has a method __call__ which returns the same value. 
> > 
> > This is backwards compatible. 
> > 
> >  Thomas 
> > 
> > -- 
> > Thomas Guettler,http://www.thomas-guettler.de/ 
> > E-Mail: guettli (*) 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/df236217-bc38-4ceb-8d1e-1da18268c81c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.