Re: Composite key development

[Asif Saifuddin]

Hi Julien,

I will publish it very soon.

Thanks

On Wednesday, March 1, 2017 at 5:58:50 AM UTC+6, Julien Phalip wrote:
>
> Hi Asif,
>
> That sounds good. On first look I did have some reservations about some of 
> the design details in the current DEP, especially around the observer 
> pattern for data binding. But I’m going to have to dig deeper into the 
> implementation to get a clearer idea.
>
> It’d be great if you could publish your work-in-progress at some point so 
> we can discuss the approach in more detail.
>
> Thanks,
>
> Julien
>
> On Mon, Feb 27, 2017 at 9:03 PM, Asif Saifuddin  > wrote:
>
>> Hi Julian,
>>
>> I have been also reviewing and studying the previous works, deps, 
>> discussions, codes and tickets. I have also been working to prepare a new 
>> dep based on the previous works.
>>
>> Like what Michal said, from my observation, I found the works and 
>> approaches of Michal is quite better and it's possible to break the work 
>> down into smaller parts to implement gradually.
>>
>> I am not quite sure how much work or which approaches of  Thomas 
>> Stephenson in 2015 could be mixed or needed with Michal's approach. In my 
>> humble opinion Michal spent more time in working on this and I also found 
>> his insights and suggestions on this topic more sensible.
>>
>> I would also like to work on this. My Dep is not yet ready for a push.
>>
>> You could certainly review and give you input on the Dep. Some core 
>> members suggested me to finalize a Dep before div into code.
>>
>> Let me know what your thoughts.
>>
>> Regards,
>>
>> Asif
>>
>> I have also contact with 
>>
>> On Tuesday, November 29, 2016 at 6:10:38 PM UTC+6, Craig Kerstiens wrote:
>>>
>>> Hi all,
>>>
>>> My company (Citus Data) is interested in sponsoring some Django work. In 
>>> particular work on support for composite primary keys. From what I 
>>> understand this wouldn't be the first time the work has been explored and 
>>> it sounds like it has a number of intricacies to it (
>>> https://github.com/django/deps/blob/master/draft/0191-composite-fields.rst 
>>> and 
>>> https://github.com/django/deps/blob/master/draft/0192-standalone-composite-fields.rst).
>>>  
>>> Our hope here is that it would be done in line with something that could 
>>> eventually become part of an official Django release vs. a one-off work 
>>> around. 
>>>
>>> While we know there's no guarantee of it being accepted, we'd love to 
>>> find someone with some knowledge of all the existing areas that would have 
>>> to be touched and has some experience contributing to Django core to 
>>> improve that likelihood. As part of the work, we would want the two 
>>> existing DEPs to be completed and work towards getting those accepted by 
>>> the broader community. And hopefully it goes without saying, but we'd fully 
>>> expect all the work to done in the open similar to other Django 
>>> development. 
>>>
>>> If you're interested in doing this work please reach out as we'd love to 
>>> discuss further. And if we have enough interest we'll be doing a full CFP 
>>> for the work to try to keep the process as fair as possible. 
>>>
>>> ~ Craig
>>>
>>> -- 
>> 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/cc29383b-b930-4d4c-9f48-51fa10909ecd%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/1decacfd-667a-4b66-993d-48cf06f3599a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Composite key development

[Julien Phalip]

Hi Michal,

Thanks for your detailed reply. Very helpful.

I was also curious, during your work did you look into SQLAlchemy? They
seem to have a pretty elaborate system for multi-column fields. I know that
overall the SQLAlchemy and Django ORMs follow a different approach, but I’m
wondering if perhaps some inspiration could be found in how they
specifically handle composite fields, both API-wise and implementation-wise.

Julien

On Mon, Feb 27, 2017 at 12:44 PM, Michal Petrucha <
michal.petru...@konk.org> wrote:

> Hi everyone,
>
> I can't speak for Thomas' implementation, as I haven't had the time
> and energy to look into it too much, but I can try to clarify some
> aspects of what I did years ago.
>
> On Mon, Feb 27, 2017 at 11:10:55AM -0800, Julien Phalip wrote:
> > Composite primary keys (GSoC)
> >
> > =
> >
> >
> > Michal Petrucha participated in two Google Summer of Code (GSoC) projects
> > in 2011 and 2013, during which some extensive code, tests and
> documentation
> > were written. Unfortunately this project didn't reach the point where it
> > could be merged into core and it eventually fell behind. Some relevant
> > resources about these projects can be found here:
> >
> > - GSoC'2013 proposal: https://gist.github.com/konk/5408673
> >
> > - GSoC'2013 status updates:
> > https://groups.google.com/forum/#!topic/django-developers/CD7OrkJ63zc
> >
> > - Discussion about some implementation details:
> > https://github.com/django/django/pull/1407
> >
> > - Status update from Michal from last year:
> > https://groups.google.com/forum/#!topic/django-developers/SunyXc_BTVM
> >
> >
> > Michal's implementation work is divided in two separate branches
> > ("composite-fields" and "foreignkey-refactor"), presented below with
> their
> > corresponding list of commits:
> >
> >
> > "composite-fields" branch:
> >
> > - Branch: https://github.com/konk/django/tree/soc2013/composite-
> fields
> >
> > - Commits:
> > https://github.com/django/django/compare/041a076dadce547d450cf73d97401d
> 63cde8891d...konk:soc2013/composite-fields
> >
> >
> > "foreign-refactor" branch:
> >
> > - Branch:
> > https://github.com/konk/django/tree/soc2013/foreignkey-refactor
> >
> > - Commits:
> > https://github.com/django/django/compare/041a076dadce547d450cf73d97401d
> 63cde8891d...konk:soc2013/foreignkey-refactor
> >
> >
> > I took a quick stab at merging current master into those branches but
> > didn't make it too far as it turned out to be a little tedious. The main
> > reason is that since 2013 there have been extensive changes in the ORM
> > internals, in particular around the Meta api. So I'm not sure if it's
> worth
> > doing that merge at this point. However, it'd be a shame to let all that
> > great work go to waste and hopefully some of it can still be reused.
>
> Sadly, I don't see how a merge of current master would be feasible
> with those branches. This all happened before migrations, the explicit
> AppRegistry, and all the meta changes were merged, all of which cause
> quite some conflicts. It should be feasible to port significant
> portions of my old work onto master, though, commit by commit.
>
> > Some questions:
> >
> > - Are there any portions of code or some solutions from Michal's
> > implementation that could be ported over to the DEPs and to Thomas' more
> > recent implementation?
>
> I would hope so, but unfortunately, can't say with any certainty. Even
> if I just look at the interface, Thomas' approach seems quite
> different from mine, but without going through the code, it's hard for
> me to tell what parts could be relevant.
>
> > - What is the difference or relationship between the "composite-fields"
> and
> > "foreignkey-refactor" branches?
>
> Right, so the gist of it is that if we ever want to support composite
> foreign keys, it will be necessary to turn ForeignKey into a virtual
> field, which is exactly what I attempted to achieve in the
> “foreignkey-refactor” branch. This would also have the neat side
> effect of clearly defining what even is a virtual field in the ORM,
> since that was definitely not a very well defined concept at the time.
> (I think it's gotten better with the formalization of _meta, but it's
> still very heavily influenced by the early approach of “any aspects of
> GenericForeignKey that don't closely match regular fields”.)
>
> My thinking was that I'd first try to get the refactoring part as
> solid as possible, and only then start to build on that by introducing
> the new concept of composite fields. Unfortunately, I seem to have
> crammed too much into the GSoC project, so I couldn't really stop and
> take the time to get the FK refactor over the finish line, and instead
> focused on getting as much of the new-feature code finished as
> possible.
>
> So yeah, foreignkey-refactor is the part where I turned ForeignKey
> into a virtual field, and composite-fields is the part based on the
> first branch where I added composite fi

Re: Composite key development

[Julien Phalip]

Hi Asif,

That sounds good. On first look I did have some reservations about some of
the design details in the current DEP, especially around the observer
pattern for data binding. But I’m going to have to dig deeper into the
implementation to get a clearer idea.

It’d be great if you could publish your work-in-progress at some point so
we can discuss the approach in more detail.

Thanks,

Julien

On Mon, Feb 27, 2017 at 9:03 PM, Asif Saifuddin  wrote:

> Hi Julian,
>
> I have been also reviewing and studying the previous works, deps,
> discussions, codes and tickets. I have also been working to prepare a new
> dep based on the previous works.
>
> Like what Michal said, from my observation, I found the works and
> approaches of Michal is quite better and it's possible to break the work
> down into smaller parts to implement gradually.
>
> I am not quite sure how much work or which approaches of  Thomas
> Stephenson in 2015 could be mixed or needed with Michal's approach. In my
> humble opinion Michal spent more time in working on this and I also found
> his insights and suggestions on this topic more sensible.
>
> I would also like to work on this. My Dep is not yet ready for a push.
>
> You could certainly review and give you input on the Dep. Some core
> members suggested me to finalize a Dep before div into code.
>
> Let me know what your thoughts.
>
> Regards,
>
> Asif
>
> I have also contact with
>
> On Tuesday, November 29, 2016 at 6:10:38 PM UTC+6, Craig Kerstiens wrote:
>>
>> Hi all,
>>
>> My company (Citus Data) is interested in sponsoring some Django work. In
>> particular work on support for composite primary keys. From what I
>> understand this wouldn't be the first time the work has been explored and
>> it sounds like it has a number of intricacies to it (
>> https://github.com/django/deps/blob/master/draft/0191-compo
>> site-fields.rst and https://github.com/django/deps
>> /blob/master/draft/0192-standalone-composite-fields.rst). Our hope here
>> is that it would be done in line with something that could eventually
>> become part of an official Django release vs. a one-off work around.
>>
>> While we know there's no guarantee of it being accepted, we'd love to
>> find someone with some knowledge of all the existing areas that would have
>> to be touched and has some experience contributing to Django core to
>> improve that likelihood. As part of the work, we would want the two
>> existing DEPs to be completed and work towards getting those accepted by
>> the broader community. And hopefully it goes without saying, but we'd fully
>> expect all the work to done in the open similar to other Django
>> development.
>>
>> If you're interested in doing this work please reach out as we'd love to
>> discuss further. And if we have enough interest we'll be doing a full CFP
>> for the work to try to keep the process as fair as possible.
>>
>> ~ Craig
>>
>> --
> 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/cc29383b-b930-4d4c-9f48-
> 51fa10909ecd%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/CABFDzjDjLXGOnoWa%2BE1UtKowiZgtxzB-PcR1goSJhqP2udqUqA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Template handling of undefined variables

[Tim Martin]

On Monday, 27 February 2017 10:43:02 UTC, Luke Plant wrote:
>
>
>
> On 05/01/17 02:39, Tim Martin wrote:
>
> 2) There appears to be an inconsistency in the default_if_none
>modifier. If I have a template with
>
>x|default_if_none:y = {{x|default_if_none:y}}
>{% if x|default_if_none:y %}
>x|default_if_none:y is apparently True
>{% endif %}
>
>with y defined to True and x undefined, then it produces:
>
>x|default_if_none:y = 
>x|default_if_none:y is apparently True
>
>IOW it appears that the default_if_none doesn't cause y's value to
>be used in the case where the variable is being printed, even
>though it causes the expression to have y's value when evaluated in
>an if. I think this is something to do with the fact that the two
>ways of handling failures (ignore_failures and string_if_invalid)
>do different things.
>
>I don't see a way to make backward compatible code here.
>
>I think this is just a bug, does anyone think otherwise?
>
>
> This seems to be working exactly as it should.
>
> In the context of template variable interpolation i.e. `{{ }}` syntax, it 
> is defined that `x` in this case will get converted to the empty string (or 
> your 'string_if_invalid' setting) - 
> https://docs.djangoproject.com/en/dev/ref/templates/api/#how-invalid-variables-are-handled
>  
> - unlike the case for `if` tags.
>
> When this value (the empty string) is passed to `default_if_none`, the 
> value is not changed, since it is not None. See 
> https://docs.djangoproject.com/en/1.10/ref/templates/builtins/#default-if-none
>

The missing piece of information for me (and even reading the docs it's far 
from obvious) is that undefined variables mean two different things in the 
different contexts.

The value *is* changed in the second case, because it *is* None. Undefined 
values are '' in {{ }} context but are None in {% %} context. Maybe that's 
obvious to you, but it's not to me. In fact, after a few minutes searching 
I still can't find where this is mentioned in the documentation. Only the 
vague statement that invalid variables are "generally" replaced with 
string_if_invalid.

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/9f9a2f60-ab5d-4010-b81e-90a47625a5e2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Template handling of undefined variables

[Tim Martin]

On Tuesday, 28 February 2017 13:39:21 UTC, Luke Plant wrote:
>
>
>
> On 28/02/17 15:24, Marten Kenbeek wrote:
>
> What about adding a filter |defined that returns True if a variable is 
> defined, False otherwise? It may not solve any problems when it's left 
> implicit, but at least it allows users the explicitly define the behaviour 
> for non-existing template variables, and it makes the intention of the 
> template code crystal clear. And of course it's fully backwards compatible. 
> The drawback is perhaps the resulting verbosity of if statements: 
>
> {% if user.role|defined and roles.staff|defined and user.role == 
> roles.staff %}
> [sensitive information here]
> {% endif %}
>
>
>
> The only way to do it would be to hard code this filter into the template 
> engine, because otherwise the 'defined' filter runs too late to know 
> whether the variable is defined.  This is really hacky and magic.
>


Is that true? In my patch, the undefined variable gets expanded into an 
UndefinedVariable sentinel object, which can be detected by the defined 
modifier, and can compare == to None (or not, if you wish). Other than the 
result of the 'is' operator, I think you can make this fully backward 
compatible if you choose. Whether or not this is desirable is another 
question, of course.

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/5e9949b2-11ae-466e-86ae-03f41754955f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: RGSoC'17

[Александра Мартынова]

Yes, we would like to know about the most useful tickets, thank you.

Alexandra and Alexandra

2017-02-27 23:15 GMT+03:00 Tim Graham :

> Yes, I think a collection of tickets from the "Testing framework"
> component in Trac (or whatever ideas you might have) would be a
> suitable project. If you want any feedback about what tickets would be
> more useful than others, just let me know.
>
> https://code.djangoproject.com/query?status=assigned&;
> status=new&component=Testing+framework&stage=Accepted&col=
> id&col=summary&col=status&col=owner&col=type&col=version&desc=1&order=id
>
> On Mon, Feb 27, 2017 at 3:02 PM, Саша Ершова
>  wrote:
> > Hi Tim,
> >
> > We're thinking about working on test framework cleanup, do you think it
> > would be more useful than NoSQL idea?
> >
> > Alexandra and Alexandra
> >
> > пн, 27 февр. 2017 г. в 15:30, Tim Graham :
> >>
> >> Hi Alexandra and Alexandra,
> >>
> >> I'm not sure what exactly the NoSQL idea would entail but I personally
> >> don't see it as a big priority. There are a number of third-party
> packages
> >> offering NoSQL support, see https://djangopackages.org/grids/g/nosql/
> for
> >> some examples. I'd recommend to choose some other idea unless you have a
> >> specific use case and idea in mind, as well as a motivated coach.
> >>
> >>
> >> On Sunday, February 26, 2017 at 6:28:56 PM UTC-5, Александра Мартынова
> >> wrote:
> >>>
> >>> Dear all,
> >>>
> >>> We are a team looking to participate in Rails Girls Summer of Code
> 2017,
> >>> and we would like to contribute to Django for our internship. We are
> Russian
> >>> CS students with 4-year experience in Python (both 2 and 3) and OOP,
> as well
> >>> as algorithms and database design.
> >>>
> >>> Among the projects suggested for GSoC'17 we think the most suitable for
> >>> us would be SQLAlchemy / NoSQL integration, because we have some
> experience
> >>> with both SQL and NoSQL. There are no issues related to this project,
> so
> >>> could you please give us some test task?
> >>>
> >>> Best wishes,
> >>> Alexandra Ershova (https://github.com/religofsil)
> >>> and Alexandra Martynova (https://github.com/melanoya)
>

-- 
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/CAFrdQmQ5sMPZNFNjkgVbmUpcC20%2BxzbwPbp2ranTu%2BO4BqYAWQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Template handling of undefined variables

[Luke Plant]

On 28/02/17 15:24, Marten Kenbeek wrote:
What about adding a filter |definedthat returns True if a variable is 
defined, False otherwise? It may not solve any problems when it's left 
implicit, but at least it allows users the explicitly define the 
behaviour for non-existing template variables, and it makes the 
intention of the template code crystal clear. And of course it's fully 
backwards compatible. The drawback is perhaps the resulting verbosity 
of if statements:


{% if user.role|defined and roles.staff|defined and user.role == 
roles.staff %}

[sensitive information here]
{% endif %}



The only way to do it would be to hard code this filter into the 
template engine, because otherwise the 'defined' filter runs too late to 
know whether the variable is defined.  This is really hacky and magic.


The alternative would be for this filter to take a string e.g.:


{% if "user.role"|defined and "roles.staff"|defined and user.role 
== roles.staff %}

[sensitive information here]
{% endif %}

As an analogy, in Python you can't write:

if hasattr(foo.bar)

you have to write:

if hasattr(foo, 'bar')

Another alternative would be to have some special syntax that could 
check for defined variables e.g.


   {% if user.role? and roles.staff? and user.role == roles.staff %}

My own preference, if I had a time machine, would be to have missing 
data/attributes just raise NameError/KeyError/AttributeError, and then 
have special syntax for replacing missing values with None - like 
https://msdn.microsoft.com/en-us/library/dn986595(v=vs.140).aspx .


However, I think that any option involving special syntax here has 
already got way too complex for the design philosophy of Django 
templates - to be simpler than normal Python code, and more designer 
friendly - this would take us in the opposite direction.


Luke

--
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/c1bada04-9852-e49a-e651-b12c68dcb284%40cantab.net.
For more options, visit https://groups.google.com/d/optout.

Re: Composite key development

[Asif Saifuddin]

Hi Roger,

I do agree with your points. I have some thoughts which I will share in 
Dep/mailing list soon.

Thanks

On Tuesday, November 29, 2016 at 6:10:38 PM UTC+6, Craig Kerstiens wrote:
>
> Hi all,
>
> My company (Citus Data) is interested in sponsoring some Django work. In 
> particular work on support for composite primary keys. From what I 
> understand this wouldn't be the first time the work has been explored and 
> it sounds like it has a number of intricacies to it (
> https://github.com/django/deps/blob/master/draft/0191-composite-fields.rst 
> and 
> https://github.com/django/deps/blob/master/draft/0192-standalone-composite-fields.rst).
>  
> Our hope here is that it would be done in line with something that could 
> eventually become part of an official Django release vs. a one-off work 
> around. 
>
> While we know there's no guarantee of it being accepted, we'd love to find 
> someone with some knowledge of all the existing areas that would have to be 
> touched and has some experience contributing to Django core to improve that 
> likelihood. As part of the work, we would want the two existing DEPs to be 
> completed and work towards getting those accepted by the broader community. 
> And hopefully it goes without saying, but we'd fully expect all the work to 
> done in the open similar to other Django development. 
>
> If you're interested in doing this work please reach out as we'd love to 
> discuss further. And if we have enough interest we'll be doing a full CFP 
> for the work to try to keep the process as fair as possible. 
>
> ~ Craig
>
>

-- 
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/a97f240d-af26-4de4-9624-d2455e06eeba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Template handling of undefined variables

[Marten Kenbeek]

What about adding a filter |defined that returns True if a variable is 
defined, False otherwise? It may not solve any problems when it's left 
implicit, but at least it allows users the explicitly define the behaviour 
for non-existing template variables, and it makes the intention of the 
template code crystal clear. And of course it's fully backwards compatible. 
The drawback is perhaps the resulting verbosity of if statements:

{% if user.role|defined and roles.staff|defined and user.role == 
roles.staff %}
[sensitive information here]
{% endif %}

Marten

On Monday, February 27, 2017 at 11:36:09 AM UTC+1, Luke Plant wrote:
>
>
> On 26/02/17 00:44, Karen Tracey wrote:
>
> On Sat, Feb 25, 2017 at 2:10 PM, Tim Graham  > wrote:
>
>> I think any use of undefined template variables should raise an 
>> exception. In the long run, keeping a setting to allow some other behavior 
>> seems confusing and, considering the case of templates that might be reused 
>> in different projects with different settings, even dangerous.
>>
>
> I think I'm confused...Django templates have allowed use of undefined 
> variables and documented their use as evaluating to the empty string for as 
> long as I recall. Wouldn't a change to instead raise exceptions be a major 
> backwards-incompatibility?
>
> https://docs.djangoproject.com/en/1.7/topics/templates/#variables said 
> "If you use a variable that doesn’t exist, the template system will insert 
> the value of the TEMPLATE_STRING_IF_INVALID setting, which is set to '' 
> (the empty string) by default."
>
>
> This behaviour applies only to what happens when the variable is rendered. 
> In the context of `if` tags, undefined variables get converted to `None`. 
> This behaviour is documented - 
> https://docs.djangoproject.com/en/dev/ref/templates/api/#how-invalid-variables-are-handled
>  
> but perhaps not in as much detail as necessary.
>
> The question is about changing this, especially due to templates like this:
>
> {% if user.role == roles.staff %}
> [sensitive information here]
> {% endif %}
>
> If:
> 1) you forget to provide both user and role to template context or
> 2) 'role' or 'staff' are invalid attributes, or
> 3) 'role' returns None but 'staff' is an invalid attribute, for example,
> 4) various combinations of these
>
> then this results in the sensitive info being shown, because `None == 
> None`. The proposal is to introduce a value that doesn't not compare equal 
> to itself and avoid this kind of issue.
>
> Having thought about it more, I've realised that this really isn't going 
> to work at all.
>
> First attempt:
>
> class Undefined1(object):
> def __eq__(self, other):
> return False
> 
> If we use this, then consider the following template code:
>
> {% if user.role != roles.staff %}
> This info is private, sorry
> {% else %}
> [sensitive information here]
> {% endif %}
>
>
> The default implementation of != means we will again get the sensitive 
> data shown for some of the error situations given above (e.g. 1 and 2). 
> Second attempt:
>
> class Undefined2(object):
> def __eq__(self, other):
> return False
> def __new__(self, other):
> return False
>
> This object is neither equals nor not-equals to itself or anything else. 
> But consider this template:
>
>
> {% if user.role == roles.customer %}
> This info is private, sorry
> {% else %}
> [sensitive information here]
> {% endif %}
>
> With `Undefined2` being used for invalid attributes, we again get the 
> sensitive information being shown in the case of developer error and 
> missing attributes. Plus, we now have the situation that `{% if a != b %}` 
> is not the same as `{% if not a == b %}`, which is very confusing behaviour 
> for most people.
>
> In other words, we are getting into the territory of needing a value that 
> behaves like NULL in SQL. Even if there were no implementation issues (and 
> there will be lots, because operators like 'or' 'and' etc. would need to 
> cope with this, not to mention 3rd party code), and there were no backwards 
> compatibility issues (there are lots), this would be extremely dubious to 
> me, because ternary logic is extremely tricky.
>
> The only sensible alternative to current behaviour is to raise exceptions, 
> but huge backwards incompatibility issues I think rule this out. If I were 
> to start again, I think I would make the template system not silence any 
> errors you would normally get in Python, but just have some special syntax 
> for converting non-existent data or attributes into None. But I don't have 
> that time machine.
>
> Regards,
>
> Luke
>
>

-- 
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+