Re: Template handling of undefined variables

[Tim Martin]

On Wednesday, 1 March 2017 19:52:22 UTC, Luke Plant wrote:
>
>
> This is a really big backwards incompatibility, as far as I can see. It 
> means that any filter may now get passed `UndefinedVariable` instead of 
> being passed `None` or string_if_invalid. So for example, the following 
> template behaves oppositely with your patch, if variable 'missing' is 
> undefined:
>
> {% if missing|yesno == "maybe" %}true{% else %}false{% endif %}
>
> There are likely many other filters that will behave differently e.g.:
>
> {{ missing|add:"x" }}
>
> Without the patch, if 'missing' is undefined this returns "x", but with 
> the patch it returns "". It's not just builtin filters I'm thinking about, 
> it's everyone else's that would also have to be made aware of this new 
> false-y value that it will start receiving. This is a really big backwards 
> incompatible change, I don't see how we could justify this. If we were 
> starting from scratch it would be another matter.
>

Yes, I can see the issue and I'm open to the idea of abandoning this patch. 
If we're not willing to tolerate substantial changes to the behaviour then 
I don't think there's a way forward with this patch - changing the 
semantics of undefined variables is pretty much the whole point of it.

In fairness, it's possible to change all the built-in filters to preserve 
existing behaviour (I've already done it for everything that's documented 
or covered by unit tests, though I guess I missed 'yesno', which should 
clearly return maybe for an undefined variable) and any third-party filters 
that are relying on the semantics of undefined variables (outside of 'if', 
'for' and 'regroup') are based on undefined behaviour. Imposing changes on 
third-party filters in a major release of Django doesn't seem too 
unreasonable. But I don't know that there's a strong enough positive case 
for making the change. I don't care much about it, I only picked up this 
bug because it looked like an easy way to learn the template system.

For the record, I don't like the design of treating undefined values as 
None, and I really don't like the design of them having different values in 
different contexts. But I guess that's the design we're stuck with.

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/c5b64d00-40c4-404e-9960-c7ac21251061%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature idea: forms signals

[Aymeric Augustin]

Hello,

My experience with Django — and not just with inexperienced developers — is 
that signals are a footgun. I've seen them misused as workarounds for badly 
structured code and unclear dependency trees too often. I'm not eager to 
encourage their use.

Fundamentally, signals in Django allow a developer to declare a function call 
at the callee site instead of at the caller site. That provides a way for app 
developers to modify the behavior of libraries written by others, but not a 
very good one.

"Signals as an API" have the drawbacks as "subclassing as an API", such as 
making it difficult to tell what happens just by following function calls in 
the code, and then some, for example :

- managing exceptions: while signals give control back from the library to the 
app, they also create their own tiny area of inversion control where the 
signals framework manages execution of signal receivers ; you can either get 
all exceptions or ignore them all, but it's the library that makes this 
decision, not the app.

- transactional behavior: as a consequence of the previous point, it's very 
hard to make guarantees about what the consistency of code that executed 
successfully or failed to execute when signals are involved.

- execution order of receivers: I'm supposed to have rewritten app-loading in 
Django 1.7 to make it deterministic, but I still don't quite believe it's 
reasonable to rely on import order.

- no encapsulation: even if encapsulation is merely a convention in Python, at 
least inheritance defines some boundaries on the behavior.

I'd really prefer if Django encouraged people to support customizing forms 
through dependency injection, which in my opinion is the proper way to perform 
such customizations. It can be as simple as specifying a dotted Python path to 
a form class in settings if there's a desire to stay away from the factory 
pattern and minimise boilerplate setup code.

I must be one of the more anti-signals people here — I could make the argument 
that signals aren't GOTOs, they're COMEFROMs with a straight face — so don't 
take may opinion as reflecting the consensus. It would be nice to know what 
other solutions you considered before proposing this one, though.

Best regards,

-- 
Aymeric.



> On 6 Mar 2017, at 19:10, David Seddon  wrote:
> 
> Hi all,
> 
> One thing I've always found challenging with Django is to adjust the 
> functionality of forms from other apps.  An example might be to add an extra 
> field to a login form provided by a third party module.
> 
> What I end up doing is often overriding the urlconf, view and form class.  
> Or, worse, monkey patching the form class.
> 
> A much nicer way to do this would be to add a few well chosen signals to 
> forms.
> 
> Potential ones could be:
> 
> - post_init
> - post_clean
> - post_save (for ModelForms)
> 
> I'd be happy to do a pull request for this, but just wondered what people 
> think.
> 
> David
> 
> -- 
> 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/d936a1d5-3f6e-4190-83c3-5cc31c8fbb4e%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/F928DC5B-78AC-4755-95A5-2689D48953DA%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Feature idea: forms signals

[David Seddon]

Hi all,

One thing I've always found challenging with Django is to adjust the 
functionality of forms from other apps.  An example might be to add an 
extra field to a login form provided by a third party module.

What I end up doing is often overriding the urlconf, view and form class. 
 Or, worse, monkey patching the form class.

A much nicer way to do this would be to add a few well chosen signals to 
forms.

Potential ones could be:

- post_init
- post_clean
- post_save (for ModelForms)

I'd be happy to do a pull request for this, but just wondered what people 
think.

David

-- 
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/d936a1d5-3f6e-4190-83c3-5cc31c8fbb4e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Commitable json dumps

[Adam Johnson]

PyYAML sorts keys by default, so if you use the YAML serializer that should
work for your usecase.

I think patching the JSON serializer to be deterministic by default is a
good idea, the performance cost of sorting keys is pretty small compared to
disk operations.

On 6 March 2017 at 11:32, Brice PARENT  wrote:

> Hello,
>
> I've had a few customers for whom I've had to create a repository with all
> their almost-static data (pages contents, etc.). To do that, when they want
> a backup, a scripts calls several "manage.py dumpdata --indent=4
> [app].[model] > app_model.json", then commit the whole thing. The customer
> may then update their version of the repo.
>
> But whenever there are some changes, I'd like to be able to see them
> easily (that's the reason of the --indent), but right now, the fields order
> changes frequently as the order has no meaning. But in a diff, the order
> changes everything. It's almost impossible to see the changes because every
> line has moved.
>
> I have no idea if this should be an argument to dumpdata, or a special
> behaviour on the serializer's side, but having the fields sorted during the
> serialization doesn't change the validity of the data, but allows the diffs
> to be way more explicit.
>
> How it can be done for json's serializaer (django/core/serializers/json.py:60
> for django 1.8):
> json.dump(self.get_dump_object(obj), self.stream, cls=DjangoJSONEncoder,
> sort_keys=True, **self.json_kwargs)
>
> (I added the sort_keys=True argument)
>
> I haven't looked if it would have an equivalent for other serializers, nor
> if it would make any sense without the "indent" argument, for now it's just
> an idea that feels good, but probably require more thinking and advice
> before being investigated more deeply. And I didn't launch any test suite
> for now, so I don't know if there is any side effect.  Just validating the
> idea here.
>
> Any thoughts?
>
> Brice Parent
>
>
>
> --
> 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/ms
> gid/django-developers/818b56b8-716d-d80f-ade2-1f3424206b08%40brice.xyz.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Adam

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

Re: Introduction GSoC 2017

[Tim Graham]

Hi, Have you read the wiki page? 
https://code.djangoproject.com/wiki/SummerOfCode2017 It contains getting 
started tips. If so, please be more specific with your questions.

On Monday, March 6, 2017 at 7:25:31 AM UTC-5, sahil jain wrote:
>
> Hello Everyone
> I am a sophomore major in computer science and engineering.
> I would like to contribute to django .
> I am interested in project Replace form media class for GSoC 2017
> I have been working with django for more than year. 
>
> Please suggest where to begin with,
>
> Regards
> Sahil Jain
>

-- 
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/6ecbd3f8-5cfb-4b35-87c8-0755915da392%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Google Summer of Code 2017

[Tim Graham]

Have you read the wiki page? 
https://code.djangoproject.com/wiki/SummerOfCode2017 It contains getting 
started tips. If so, please be more specific with your questions.

On Sunday, March 5, 2017 at 11:11:17 AM UTC-5, Pranav Jadhav wrote:
>
> Hey Tim,
> I am Pranav Jadhav, an undergrad student from Pune, India. I was keen 
> on working with contributions towards communities. I just wished some 
> guidance to get actually started. Means how actually these things proceed 
> and how I actually would be getting something to work upon. Just like the 
> basics. Anything helpful will be appreciated.
> Thank You!!
>

-- 
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/ec56ba99-80b3-4e76-b69a-e48eee6f02c3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Introduction GSoC 2017

[sahil jain]

Hello Everyone
I am a sophomore major in computer science and engineering.
I would like to contribute to django .
I am interested in project Replace form media class for GSoC 2017
I have been working with django for more than year. 

Please suggest where to begin with,

Regards
Sahil Jain

-- 
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/d62e3695-5f63-475f-891d-cd1fdc9b7e5b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Database connection retry

[Aymeric Augustin]

> On 5 Mar 2017, at 12:27, James Pic  wrote:
> 
> However, I'm still a bit puzzled by having a process that's just stuck when 
> checks fail (if I understand correctly) is there any particular reason why it 
> is this way ? If not, perhaps a retry or exit could improve the developer 
> experience

To me this looks like a bug in the implementation of the auto-reloader.

Handling correctly both the initial invocation and subsequent invocations 
(after reloads) isn't as easy as it seems.

-- 
Aymeric.

-- 
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/9CD08426-CC6A-4BA7-A9D4-AB8451FA47B0%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Project idea for GSoC page - Support for expressions in indexes

[Florian Apolloner]

On Monday, March 6, 2017 at 3:57:48 AM UTC+1, akki wrote:
>
>
>
> On Sunday, 5 March 2017 01:53:28 UTC+5:30, Florian Apolloner wrote:
>>
>> On Saturday, March 4, 2017 at 7:10:57 PM UTC+1, akki wrote:
>>>
>>> First of all let's not call the work done by the 1000s of GSoC mentors 
>>> every year "putting down hands and doing nothing".
>>>
>>
>> I am pretty sure I did not say that
>>
> Thanks!
>
> What do you think about the other tasks? Is it all right to include them 
> on the page?
>

Sure, I think including them is fine. All I wanted to say is that we might 
(or might not) have to be careful about accepting a few. But either way, 
that is something to think about when it comes so far -- if there is a 
strong proposal we can certainly find a way to make it happen.

-- 
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/6b78f446-4a94-4460-8acc-6058e067ede5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.