Re: Some thoughts about improving migration squashing

[charettes]

Hello Raphael,

Thanks for your detailed explanation! You clearly expressed why it's safe to
optimize through RemoveField operations and helped me lift any doubt about
what was a wrong assumption[1].

I gave your two passes optimization strategy a try and I believe I managed 
to
implement it correctly[2].

The plan is to modify the optimization algorithm to start by trying to 
perform
a "right" (as right of the migration in between) reduction and attempt a 
"left"
one if a subsequent operation can be reduced with. The "left" reduction will
only be performed if all the operations in between can optimize through 
(their
reduce() method returns True) the operation we're trying to perform a 
reduction
with.

Cheers,
Simon

[1] 
https://github.com/django/django/pull/7999/commits/6d0b740cbc9ae038f9eef95dac3057dccb283e6d
[2] https://github.com/django/django/pull/7999

Le vendredi 17 février 2017 01:14:58 UTC-5, Gaschignard, Raphael a écrit :
>
> To clarify on my previous post, if we're in the first case, then the +M 
> and -F operations can be optimized in one path to remove the dependency, 
> and then the +M' and -M' operation can be optimized through.
>
> In the second case (with an AddField operation), the +F and -F operations 
> will cancel each other out (since they will be "in between" +M' and -M') 
> and then the optimization can happen.
>
> A bit more holistically, since M's field depends on M' in the code (which 
> is where these operations come from, after all), in order to remove M', you 
> would first need to remove M's field, so you're almost guaranteed that a 
> RemoveField will be "in between" any of its dependency's creations/removals.
>
> If we have the field information in the RemoveField, we could check it. 
> But if we do not make an assumption on (no field information) RemoveFields, 
> it blocks a lot of possible optimizations. We could just do that (start 
> generating RemoveField with field info), though it would not allow for 
> older migrations to get optimized. I'd be good with doing either/both. 
>
> Raphael
>
> On Fri, Feb 17, 2017 at 3:09 PM, Gaschignard, Raphael <
> rap...@makeleaps.com > wrote:
>
>> Hi Simon,
>>
>>I think it's a bit more general than that. Why does the `RemoveField` 
>> exist? Because somewhere, an `AddField`-esque operation exists before it, 
>> right?
>>
>>   Let's say we have m, m' as models.
>>
>>   Let -F be a RemoveField(m, 'foo', ForeignKey(m') operation. We also 
>> have two operations +M', a CreateModel(m'), and -M', a RemoveModel(m') 
>> operation. Because we have a removeField operation, we also have +M, a 
>> "CreateModel(m), somewhere
>>
>>  Let's assume that we have an operations list like:   [ ...(1)..., +M', 
>> ...(2)..., -F, ...(3)..., -M']. How do we know that we can reduce +M' and 
>> -M' together "through" -F?
>>
>> Because we have -F, we have +M somewhere. because m has a field for m', 
>> either: 
>>1 - The field is within the initial +M operation. Because the 
>> definition depends on M', it must be in group (2).
>>2 - The field is not within the initial +M operation. Because the 
>> definition of the field depends on M', we need an AddField operation (or 
>> moral equivalent) +F in group (2)
>>
>> So, if we have -F in between +M' and -M', we will also have either a +M 
>> which depends on M' or a +F which depends on M' within (2).
>>
>> So if the -F is between the two, there will also be another operation 
>> that will be present between the two that expresses the same dependencies. 
>> So the -F operation itself can avoid expressing its "RemoveField" indirect 
>> dependency to m' because another operation will do it for them.
>>
>> 
>>
>> It's hard to generalize this across everything because there are, after 
>> all, arbitrary migrations. But considering that RemoveField will only be 
>> reduced with a "moral equivalent" to AddField, I think we can expand this 
>> reasoning across everything to say that RemoveField will be sufficiently 
>> protected by the AddField operation's location (which will have to be after 
>> +M').
>>
>>
>> Raphael
>>
>>
>> On Fri, Feb 17, 2017 at 12:28 PM, charettes > > wrote:
>>
>>> > RemoveField('A', 'foo') also references A and foo, but does it 
>>> reference B? if it does, then it' s hard to have optimizations that pass 
>>> through this, because this field could be referencing any model 
>>> (theoretically).
>>>
>>> I think we all agree on that.
>>>
>>> > But if we assert that RemoveField doesn't refer to any models 
>>> referenced to by its field, then our optimizer can take a couple more 
>>> liberties.
>>>
>>> Do you have suggestion on how we can assert that it's the case? The only 
>>> way I could come up with was to make sure RemoveField has a reference to 
>>> the field it's removing. e.g. It would be generated in the form 
>>> `RemoveField('A', 'foo', ForeignKey('B'))`.
>>>
>>> Simon
>>>
>>>
>>> Le jeudi 16 février 2017 18:25:16 UTC-5, rap...@makeleaps.com a écrit :

 When you 

Re: Django 2.0 Python version support (Python 3.6+ only?)

[Tim Graham]

Ok, I created a ticket to track cleanups and new Python features we can use 
when Python 3.4 support is removed: 
https://code.djangoproject.com/ticket/27857

We can evaluate that a bit later in the Django 2.0 release cycle and decide 
whether or not to keep Python 3.4 support for 1.11.

On Wednesday, January 18, 2017 at 12:20:13 PM UTC-5, Rotund wrote:
>
> I agree that allowing more people to be able to do development against 
> Django 2.0 is important. That stated, please be very explicit in the 
> release notes and documentation that "Versions below Python 3.6 are 
> expected to be dropped before the next Django LTS will be released, so 
> please keep that in your project planning." (Language too informal, but I 
> think the idea is correct.)
>
>
>
> On Wed, Jan 18, 2017 at 2:28 AM, Claude Paroz  > wrote:
>
>> Le mardi 17 janvier 2017 15:48:46 UTC+1, Tim Graham a écrit :
>>>
>>> I propose to tentatively target Python 3.5+ for Django 2.0 but not to 
>>> remove the current workarounds for Python 3.4 at this time. Shortly before 
>>> the alpha for Django 2.0, an interested person can look into how much work 
>>> is required to fix any test failures on Python 3.4 and we'll make a 
>>> decision then.
>>>
>>
>> I'm strongly advocating for keeping 3.4 support for now, as I would have 
>> difficulty to continue contributing to Django.
>> My main system is still using 3.4 and will be for some months. Even if I 
>> could rather easily installing manually a more recent Python, I very much 
>> like relying on my stable distro packages. Sorry for my dumbness!
>>
>> Claude
>>
>> -- 
>> 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 https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/09570028-4eea-41ac-b364-93ae2c946b21%40googlegroups.com
>>  
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Joe Tennies
> ten...@gmail.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-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/fb3704d2-c069-41d2-beb0-445524c6f0aa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extending Django models with Schevo

[Tim Graham]

Hi Etienne, I'm not sure exactly what type of response you're looking for 
or if this is on-topic for the Django developers mailing list, which 
pertains to the development of Django itself. django-users seems more 
appropriate unless you're proposing some feature for Django.

On Friday, February 17, 2017 at 3:57:42 PM UTC-5, Etienne Robillard wrote:
>
> Hi, 
>
> I'm planning to extend django-hotsauce to support a generic "model" API. 
> I would like to reuse the Django models API to support Schevo databases. 
> Ideally, I would like to introspect into my reusable Django apps to 
> discover configured features. Importing and exporting data from/to 
> Schevo databases using JSON fixtures would also be a great addition. 
>
> Any ideas if Django 1.10 can be used for this? 
>
> Kind regards, 
>
> Etienne 
>
> -- 
> Etienne Robillard 
> tka...@yandex.com  
> http://www.isotopesoftware.ca/ 
>
>

-- 
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/f907064e-f4c4-4c73-aa31-0204b7ee1c12%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Template handling of undefined variables

[Tim Graham]

After reviewing the pull request, I wonder if it would be better to raise 
exceptions when comparing nonexistent variables in {% if %} rather than 
altering the behavior. For existing projects, this would prevent possible 
inadvertent information leakage if some {% if %} starts evaluating 
differently than it did before. While the current behavior may not be 
documented, it seems risky to silently change it.

There are examples of that behavior change on the PR: 
https://github.com/django/django/pull/7901

On Saturday, January 7, 2017 at 12:21:33 PM UTC-5, Tim Martin wrote:
>
> On Friday, 6 January 2017 10:15:22 UTC, Alasdair Nicol wrote:
>>
>> Hi,
>>
>> On Thursday, 5 January 2017 17:51:39 UTC, Tim Martin wrote:
>>>
>>>
>>>
>>> On Thursday, 5 January 2017 04:15:31 UTC, Carl Meyer wrote:

 Hi Tim, 

 On 01/04/2017 03:39 PM, Tim Martin wrote: 
  
 > 1) There are test cases where we have templates that should treat "x 
 >is y" as True where x and y are both undefined. 

 Really? Is this an accidental side effect of some historical change, or 
 really the intent of the test? That behavior seems buggy to me; more 
 likely to be a bug-magnet than useful. 

>>>
>>> There are a couple of test cases in test_if.py: 
>>> test_if_is_both_variables_missing and 
>>> test_if_is_not_both_variables_missing. These are verifying this specific 
>>> case, so they haven't been introduced by accident. I haven't got as far as 
>>> figuring out whether it was a fully thought through decision or whether 
>>> someone just created these cases for completeness.
>>>
>>
>> I added the tests in ticket 26479 (see comment 5 onwards) [1]. I believe 
>> I added them for consistency with == and != operators, which have similar 
>> tests [2], [3] (trickier to spot because they are numbered). I apologise if 
>> adding the tests has made it harder to improve the behaviour of the tag. 
>>
>
> Thanks for the background info Alasdair, that saved me lots of time 
> hunting around.
>
> I agree you were right to add the tests, which were useful since without 
> them I wouldn't have realised the potential behaviour change I was 
> introducing. As I see it, these tests don't in themselves form a reason not 
> to change the behaviour (since AIUI you originally added them for 
> completeness, rather than because this specific behaviour was desired).
>
> Does anyone think changing the behaviour of {% if a is None %} is the 
> wrong thing to do? I realise there can potentially be template code out 
> there relying on this, but after a quick scout through the documentation I 
> can't see anywhere that the behaviour on undefined variables is specified 
> officially.
>
> For what it's worth, the same issue doesn't come up with ==, because 
> although the existing template behaviour has the same pattern, it's 
> possible to override == and != so that the Undefined object gives the same 
> behaviour as None did before. It's only for 'is' that this can't be 
> achieved. I don't know how for to go with this: preserving the existing == 
> behaviour but changing it for 'is' leaves the two operations superficially 
> inconsistent (though there's nothing fundamentally wrong with two things 
> that satisfy equality but not 'is'). I can see a couple of alternatives (in 
> all cases all variables are undefined):
>
> * "x is y" is false, but "x == y" is true and "x != y" is false (minimal 
> difference from the current behaviour)
> * "x is y" and "x == y" are both false, "x != y" is true (probably the 
> most mutually consistent?)
> * "x is y", "x == y" and "x != y" are all false (the SQL NULL alternative 
> - I'm not sure if I like this, but it has the merit that wrongly skipping 
> sections of a template is usually less bad than wrongly including parts of 
> a template)
>
> Tim
>  
>

-- 
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/76adf765-bdd8-4ecc-b12c-6766d8363751%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Extending Django models with Schevo

[Etienne Robillard]

Hi,

I'm planning to extend django-hotsauce to support a generic "model" API. 
I would like to reuse the Django models API to support Schevo databases. 
Ideally, I would like to introspect into my reusable Django apps to 
discover configured features. Importing and exporting data from/to 
Schevo databases using JSON fixtures would also be a great addition.


Any ideas if Django 1.10 can be used for this?

Kind regards,

Etienne

--
Etienne Robillard
tkad...@yandex.com
http://www.isotopesoftware.ca/

--
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/de1730ab-2c5e-310e-d7a8-38d0ca5f4e43%40yandex.com.
For more options, visit https://groups.google.com/d/optout.

Re: Use signing backend for signed_cookie session engine

[Tim Graham]

These questions involving old code aren't always easily answered. I would 
try to answer it by looking through git blame and finding the relative 
commits and tickets to see if there's an explanation there.

On Wednesday, February 15, 2017 at 8:07:45 PM UTC-5, Danielle Madeley wrote:
>
> Hi all,
>
> Was looking at implementing a custom signing backend via a HSM to sign and 
> validate my Django sessions without knowing the key.
>
> It seems that the functions signing.loads() and signing.dumps() force you 
> to use TimestampSigner [1] rather than calling get_cookie_signer(). This 
> has the interesting side effect that response.set_signed_cookie() does go 
> via the signing backend but the signed_cookie session engine is signed with 
> a different backend.
>
> Is there any reason the loads() and dumps() functions don't use the 
> signing backend?
>
> [1] 
> https://github.com/django/django/blob/master/django/core/signing.py#L127
>
> --danni
>

-- 
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/d9afd2eb-5d99-4032-aac6-f83ee8f31733%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Channels: get IP address of client websocket

[Andrew Godwin]

It's in the connect message, as message['client']:
http://channels.readthedocs.io/en/latest/asgi.html#connection

Andrew

On Fri, Feb 17, 2017 at 10:05 AM, Fabien Millerand 
wrote:

> As far as I know I cannot get client websocket public IP address with
> channels.
>
> I even looked into the sessions and couldn't find anything.
>
> Did I miss it?
>
>
>
> --
> 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/c2f88798-b212-47a2-b058-
> 05b2021787ae%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFwN1up2eYb6%2BicL%3DFNvfNjzeKXdStTpogeRXe5dd9UQQtp1aA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Channels: get IP address of client websocket

[Fabien Millerand]

As far as I know I cannot get client websocket public IP address with 
channels.

I even looked into the sessions and couldn't find anything.

Did I miss it?



-- 
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/c2f88798-b212-47a2-b058-05b2021787ae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.