On Mon, 2017-02-27 at 21:03 -0800, 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.
>
I haven't had a chance to review Michael's
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
On Sunday 26 February 2017 11:16:54 Florian Apolloner wrote:
> As much as I'd like variables to raise an error if they cannot resolve, I
> am with Karen here -- the backwards compatibility considerations should
> take priority here. At least we should have a possibility in the templates
> to check
Django is accepted as a mentor organization. The student application period
opens March 20 ends on April 3. Students playing to apply should share
drafts of their proposal on this mailing list well before the deadline to
get feedback and find possible mentors.
On Friday, January 20, 2017 at
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)
>
>
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.
On Tuesday, November 29, 2016 at 4:10:38 AM UTC-8, Craig Kerstiens wrote:
>
> 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
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
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