Re: GSoC query

[anubhav joshi]

On Sunday, February 16, 2014 4:35:05 AM UTC+5:30, Florian Apolloner wrote:
>
> On Saturday, February 15, 2014 5:01:09 PM UTC+1, anubhav joshi wrote:
>>
>> Well I will see what I put in my proposal..it will be based on 
>> aggregation/annotation as well as improving the error message part as 
>> before...I might now look to other things as well like improving tests as 
>> well.
>>
>
> That sounds a little bit to much, the topics themselves are all in all 
> probably three GSoC projects, covering two or more in one will most likely 
> not lead to any success. If I were you (speaking as student), I'd hash out 
> one in all the details and show us that you are actually up to solve one. 
> Trying to tell us that you can solve more than one will most likely meet a 
> bit of scepticism,  especially since noone knows you personally.
>
> Regards,
> Florian
>


I am not trying to say that I can solve all the issues myself, that is no 
way possible. But I had wanted to base my work on aggregation part but I 
think quite has been done so I just said that I would now explore other 
areas as well. I have no intention of telling that I could do all, I merely 
posted the reply to get suggesstions for those topics.

Apologies if what I wrote made you think that way.

Anubhav 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/07bd60a1-bc4e-41aa-b99b-fdb071983902%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: GSoC query

[anubhav joshi]

I am not trying to say that I can solve all the issues myself, that is no 
way possible. But I had wanted to base my work on aggregation part but I 
think quite has been done so I just said that I would now explore other 
areas as well. I have no intention of telling that I could do all, I merely 
posted the reply to get suggesstions for those topics.

Apologies if what I wrote made you think that way.

Anubhav

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/402b20bd-9d29-4c47-9978-604f1a7161b7%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Ticket #9?

[Florian Apolloner]

On Sunday, February 16, 2014 3:13:28 AM UTC+1, Justin Holmes wrote:
>
> I didn't mean to suggest that it was nefarious.  It's just that that 
> ticket had some... sentimental value.  ;-)
>

I am pretty sure it's implemented by now: 
http://web.archive.org/web/20060105063700/http://code.djangoproject.com/ticket/9
 
:)

Cheers,
Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/b20cf1a6-eb2b--976b-867d352f91a3%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Ticket #9?

[Justin Holmes]

I didn't mean to suggest that it was nefarious.  It's just that that ticket
had some... sentimental value.  ;-)


On Sat, Feb 15, 2014 at 6:49 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

>
> There isn't anything nefarious going on here; we delete tickets
> occasionally. It's usually due to spam. There's a lot of deleted tickets in
> the 20k range.
>
> Yours,
> Russ Magee %-)
>
> On Sun, Feb 16, 2014 at 7:37 AM, Justin Holmes wrote:
>
>> It appears that Ticket #9 has been deleted?  Anybody know why?
>>
>> https://code.djangoproject.com/ticket/9
>>
>> --
>> Justin Holmes
>> Chief Chocobo Breeder, slashRoot
>>
>> slashRoot: Coffee House and Tech Dojo
>> New Paltz, NY 12561
>> 845.633.8330
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" 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/CAMGywB4MExcuO_MR5HRi6pHf6XLD65tw_p1YXrHedV9Pa%3DCF_Q%40mail.gmail.com
>> .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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/CAJxq849T25R7F3U7yWFHYdkSzQbnL6%2Bp6r23_cH%3DOUjUKVYwZw%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
Justin Holmes
Chief Chocobo Breeder, slashRoot

slashRoot: Coffee House and Tech Dojo
New Paltz, NY 12561
845.633.8330

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/CAMGywB43TywVxdzk5Xqedbt_KO2mjo8SM-115mmQz3wuaWBh4Q%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSOC] Improving the Test-Suite

[Josh Smeaton]

Just a few observations that I've had when running the test suite that may 
be relevant.

- There are lots and lots of different test modules that may be relevant to 
a particular change, and some may not seem relevant until you run the 
entire suite
- bug* modules are hard to classify without reading the tests or the ticket
- *_regress modules seem too complex, and should be folded back in to the 
main test module
- Creating a new test module is not as easy as it could be. Basically, copy 
another test module, and search/replace the fixtures (if they exist)
- Setup/Teardown can be quite expensive across a large number of tests. 
Perhaps individual tests could be longer (which is bad practise, but 
practical with respect to time)
- There are 13 individual admin test modules. Perhaps it'd be nicer to have 
them all under a single admin module, with separate TestCases within. This 
applies to other systems like the ORM.
- It'd be nice if test modules could be parallelised, to improve total run 
time of the test suite

I think that restructuring the modules could take the place of tagging or 
classification in a naive kind of way, but does not allow marking two 
systems as relevant. For example, the checks framework has tests relating 
to the admin, which should be run alongside any admin tests, but wouldn't 
necessarily live in the admin module.

Would pytest help with any of the issues observed with the current test 
suite?

- Josh

On Sunday, 16 February 2014 02:17:37 UTC+11, Chris Wilson wrote:
>
> Hi all, 
>
> On Sat, 15 Feb 2014, Russell Keith-Magee wrote: 
>
> > One of the improvements I see is classification of test cases. 
> > Classifying them into categories (read multiple-categories), would make 
> > it easier for users/developers/maintainers to run them. Basis of 
> > classification,etc is what I am still thinking on. But surely 
> > classification will help in deciding which all test cases to run. For 
> > example - just running third-party app test cases, or just run my test 
> > cases, or those which check part ABC of my project, or just those with 
> > priority set to important. 
> [...] 
> > I would envisage that this would be a declarative process - in code, 
> > marking a specific test as a "system" test or an "integration" test (or 
> > whatever other categories we develop). 
>
> It just occurred to me that most classification systems are completely 
> arbitrary and therefore not very useful. What's a "system" test and how 
> would I know whether I need to run it? 
>
> But some ideas that I can think of that might be useful are: 
>
> * Automatically building test coverage maps for each test, and reversing 
> them, so we can see which tests touch the line(s) of code that we just 
> modified, and rerun them easily. A good smoke test to run while modifying 
> part of Django. 
>
> * Categorising by imports: run all tests that import django.db or 
> django.core.http for example. Not perfect, some tests may touch facilities 
> without needing to actually import them, but it would be quick and cheap. 
>
> * Profile and speed up the test suite, so that we can run all tests more 
> quickly, especially with databases like postgres where it takes an hour to 
> run them all. 
>
> Cheers, Chris. 
> -- 
> Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838 
> Citylife House, Sturton Street, Cambridge, CB1 2QF, UK 
>
> Aptivate is a not-for-profit company registered in England and Wales 
> with company number 04980791. 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/a7e28b8c-50c1-4ab5-8ee1-ebb1ac035173%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC] Switching to Jinja2 proposal

[Russell Keith-Magee]

On Sun, Feb 16, 2014 at 1:12 AM, Donald Stufft  wrote:

>
> On Feb 15, 2014, at 11:43 AM, Christopher Medrela 
> wrote:
>
> My last post was pretty long and the most important questions and
> statements
> have left unanswered, so I will repeat them.
>
> What I'm proposing now is more conservative proposal. Firstly, Django will
> support Jinja2 out-of-the-box, but DTL will remain the "blessed" option.
> Secondly, Django will allow to mix DTL and Jinja2 templates (so you can
> include/inherit DTL template from Jinja2 one and vice versa).
>
> After doing it, I could focus on 3) decoupling DTL or/and 4) rewriting
> Django
> builtin templates in Jinja2 or/and 5) moving rendering form widgets from
> Python code to Jinja2 templates.
>
> After that all, we could start again the war DTL vs Jinja2, but please
> focus
> on the new proposal now.
>
> Questions are:
>
> 1) What do you think about the new proposal? Would it be useful?
>
> 2) Jinja2 doesn't support 3.2. Will Django 1.8 support 3.2?
>
> 3) Supporting Jinja2 out-of-the-box means introducing dependencies. Are we
>ready for this?
>
>
> If we have Jinja2 I don't see any reason to keep the DTL as the blessed
> option.
>

Amongst other reasons:

a) Some of us prefer DTL to Jinja2 :-)

b) The Python3 support issue is a lingering concern

c) There is a lot of legacy code and tutorials that need to continue to
work as is.

This is an area where there is a lot of benefit to moving slowly, IMHO.
We're talking about a major part of the Django experience; Introducing a
new option *and* switching to it in a single release sounds like a recipe
for confusion to me.

As I see it, there are three possible options here:

 1) Add Jinja2 as a supported option, but stick with DTL as the default.
 2) Add Jinja2 as a supported option, and indicate that long term, we're
going to switch to Jinja as the default
 3) Add Jinja2 as a supported option and move to it immediately as the
default.

My personal preferences would be in that order. This is something where
historically, we would have gone to the BDFLs for a call; I suspect the
core team might need to have a quick discussion and make a call, lest this
turn into the mother of all bike sheds.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/CAJxq849aJXA-H8syt8G4evKz3yXpgD2h93bC45rt0BYdv2%2BQkQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC] Switching to Jinja2 proposal

[Russell Keith-Magee]

On Sun, Feb 16, 2014 at 12:43 AM, Christopher Medrela <
chris.medr...@gmail.com> wrote:

> My last post was pretty long and the most important questions and
> statements
> have left unanswered, so I will repeat them.
>
> What I'm proposing now is more conservative proposal. Firstly, Django will
> support Jinja2 out-of-the-box, but DTL will remain the "blessed" option.
>

As a broad statement, this sounds fine; but what does this mean in
practice? What does "out of the box" support look like?


> Secondly, Django will allow to mix DTL and Jinja2 templates (so you can
> include/inherit DTL template from Jinja2 one and vice versa).
>

Including doesn't sound like it would be any problem, but inheriting? Is
that really going to be possible?

>
> After doing it, I could focus on 3) decoupling DTL or/and 4) rewriting
> Django
> builtin templates in Jinja2 or/and 5) moving rendering form widgets from
> Python code to Jinja2 templates.
>
> After that all, we could start again the war DTL vs Jinja2, but please
> focus
> on the new proposal now.
>
> Questions are:
>
> 1) What do you think about the new proposal? Would it be useful?
>

I think the broad feature is useful; I can't comment as to whether it would
make the lives of any existing Django-Jinja users any easier.

2) Jinja2 doesn't support 3.2. Will Django 1.8 support 3.2?
>

Django 1.6 and 1.7 both support 3.2; we haven't had the project-level
discussion about deprecating 3.2 support.

Historically, this would have been based on the usage of Python 3.2 in the
wild, driven primarily by operating systems that shipped 3.2 as the
default. That's not going to apply here. I'm not sure how we'd judge the
rate of 3.2 adoption in practice.

3) Supporting Jinja2 out-of-the-box means introducing dependencies. Are we
>ready for this?
>

I think we are. Pip and setuptools handle dependencies really well; if we
don't want to add it as a default dependency, we can easily check for an
ImportError when Jinja support is enabled and give an appropriate error
message, same as we do for YAML support.


> On Tuesday, February 11, 2014 2:07:19 PM UTC+1, Aymeric Augustin wrote:
>>
>> 2014-02-11 13:42 GMT+01:00 Christopher Medrela :
>>
>>
>>> What did Armin said about Python 3 exactly?
>>
>>
>> He wrote an extensive argumentation about "why Python 2 [is] the better
>> language for dealing with text and bytes" [1] as well as a number of
>> tweets
>> and a few other blog posts along the same lines.
>>
>> While his arguments are technically correct, I disagree with his
>> conclusions
>> because he's speaking with the point of view of an expert maintaining
>> libraries at the boundary between unicode and bytes (like werkzeug).
>> However,
>> most Python users aren't experts and aren't maintaining such libraries.
>> In my
>> experience working with Python programmers ranging from intern to
>> veteran, the
>> unicode model of Python 3 is a strict improvement over Python 2 in terms
>> of
>> pitfalls hit in day-to-day programming. YMMV.
>>
>> [1] http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/
>>
>> --
>> Aymeric.
>>
>
> OK, so Armin finds Python 2 better than Python 3. But why is it at odds
> with
> Django? He didn't say that he is not going to support Python 3. So where is
> the risk that concerns you?
>

For my part, my concern is that the tone of his discussions and comments
about Python3 suggests that while he currently supports Python3, he does so
begrudgingly, and he might, at some point in the future, stop. That would
put Django in a precarious position.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/CAJxq8493xryKMEjAzHO_Qbp1k9vn-zWBnS_1iw4i%2Bdq8ng34wQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Ticket #9?

[Russell Keith-Magee]

There isn't anything nefarious going on here; we delete tickets
occasionally. It's usually due to spam. There's a lot of deleted tickets in
the 20k range.

Yours,
Russ Magee %-)

On Sun, Feb 16, 2014 at 7:37 AM, Justin Holmes wrote:

> It appears that Ticket #9 has been deleted?  Anybody know why?
>
> https://code.djangoproject.com/ticket/9
>
> --
> Justin Holmes
> Chief Chocobo Breeder, slashRoot
>
> slashRoot: Coffee House and Tech Dojo
> New Paltz, NY 12561
> 845.633.8330
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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/CAMGywB4MExcuO_MR5HRi6pHf6XLD65tw_p1YXrHedV9Pa%3DCF_Q%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/CAJxq849T25R7F3U7yWFHYdkSzQbnL6%2Bp6r23_cH%3DOUjUKVYwZw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Ticket #9?

[Justin Holmes]

It appears that Ticket #9 has been deleted?  Anybody know why?

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

-- 
Justin Holmes
Chief Chocobo Breeder, slashRoot

slashRoot: Coffee House and Tech Dojo
New Paltz, NY 12561
845.633.8330

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/CAMGywB4MExcuO_MR5HRi6pHf6XLD65tw_p1YXrHedV9Pa%3DCF_Q%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: GSoC query

[Florian Apolloner]

On Saturday, February 15, 2014 5:01:09 PM UTC+1, anubhav joshi wrote:
>
> Well I will see what I put in my proposal..it will be based on 
> aggregation/annotation as well as improving the error message part as 
> before...I might now look to other things as well like improving tests as 
> well.
>

That sounds a little bit to much, the topics themselves are all in all 
probably three GSoC projects, covering two or more in one will most likely 
not lead to any success. If I were you (speaking as student), I'd hash out 
one in all the details and show us that you are actually up to solve one. 
Trying to tell us that you can solve more than one will most likely meet a 
bit of scepticism,  especially since noone knows you personally.

Regards,
Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/42affac6-1932-427c-a8aa-5b16e2f1fa0c%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC] Switching to Jinja2 proposal

[Babatunde Akinyanmi]

On 15 Feb 2014 18:13, "Donald Stufft"  wrote:
>
>
> On Feb 15, 2014, at 11:43 AM, Christopher Medrela 
wrote:
>
>> My last post was pretty long and the most important questions and
statements
>> have left unanswered, so I will repeat them.
>>
>> What I'm proposing now is more conservative proposal. Firstly, Django
will
>> support Jinja2 out-of-the-box, but DTL will remain the "blessed" option.
>> Secondly, Django will allow to mix DTL and Jinja2 templates (so you can
>> include/inherit DTL template from Jinja2 one and vice versa).
>>
>> After doing it, I could focus on 3) decoupling DTL or/and 4) rewriting
Django
>> builtin templates in Jinja2 or/and 5) moving rendering form widgets from
>> Python code to Jinja2 templates.
>>
>> After that all, we could start again the war DTL vs Jinja2, but please
focus
>> on the new proposal now.
>>
>> Questions are:
>>
>> 1) What do you think about the new proposal? Would it be useful?
>>
>> 2) Jinja2 doesn't support 3.2. Will Django 1.8 support 3.2?
>>
>> 3) Supporting Jinja2 out-of-the-box means introducing dependencies. Are
we
>>ready for this?
>
>
> If we have Jinja2 I don't see any reason to keep the DTL as the blessed
option.

Exactly
>
>>
>> On Tuesday, February 11, 2014 2:07:19 PM UTC+1, Aymeric Augustin wrote:
>>>
>>> 2014-02-11 13:42 GMT+01:00 Christopher Medrela :
>>>

 What did Armin said about Python 3 exactly?
>>>
>>>
>>> He wrote an extensive argumentation about "why Python 2 [is] the better
>>> language for dealing with text and bytes" [1] as well as a number of
tweets
>>> and a few other blog posts along the same lines.
>>>
>>> While his arguments are technically correct, I disagree with his
conclusions
>>> because he's speaking with the point of view of an expert maintaining
>>> libraries at the boundary between unicode and bytes (like werkzeug).
However,
>>> most Python users aren't experts and aren't maintaining such libraries.
In my
>>> experience working with Python programmers ranging from intern to
veteran, the
>>> unicode model of Python 3 is a strict improvement over Python 2 in
terms of
>>> pitfalls hit in day-to-day programming. YMMV.
>>>
>>> [1] http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/
>>>
>>> --
>>> Aymeric.
>>
>>
>> OK, so Armin finds Python 2 better than Python 3. But why is it at odds
with
>> Django? He didn't say that he is not going to support Python 3. So where
is
>> the risk that concerns you?
>>
>> --
>> You received this message because you are subscribed to the Google
Groups "Django developers" 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/79dbbf71-6b70-48d1-8510-cef471812677%40googlegroups.com
.
>> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
> -
> 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" 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/CA%2BWjgXOegMcvFC4_%2Bg8-siy_2s_VqLg5ecYquO4rw8_ivmBNzw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC] Switching to Jinja2 proposal

[Donald Stufft]

On Feb 15, 2014, at 11:43 AM, Christopher Medrela  
wrote:

> My last post was pretty long and the most important questions and statements
> have left unanswered, so I will repeat them.
> 
> What I'm proposing now is more conservative proposal. Firstly, Django will
> support Jinja2 out-of-the-box, but DTL will remain the "blessed" option.
> Secondly, Django will allow to mix DTL and Jinja2 templates (so you can
> include/inherit DTL template from Jinja2 one and vice versa).
> 
> After doing it, I could focus on 3) decoupling DTL or/and 4) rewriting Django
> builtin templates in Jinja2 or/and 5) moving rendering form widgets from
> Python code to Jinja2 templates.
> 
> After that all, we could start again the war DTL vs Jinja2, but please focus
> on the new proposal now.
> 
> Questions are:
> 
> 1) What do you think about the new proposal? Would it be useful?
> 
> 2) Jinja2 doesn't support 3.2. Will Django 1.8 support 3.2?
> 
> 3) Supporting Jinja2 out-of-the-box means introducing dependencies. Are we
>ready for this?

If we have Jinja2 I don’t see any reason to keep the DTL as the blessed option.

> 
> On Tuesday, February 11, 2014 2:07:19 PM UTC+1, Aymeric Augustin wrote:
> 2014-02-11 13:42 GMT+01:00 Christopher Medrela :
>  
> What did Armin said about Python 3 exactly?
> 
> He wrote an extensive argumentation about "why Python 2 [is] the better
> language for dealing with text and bytes" [1] as well as a number of tweets
> and a few other blog posts along the same lines.
> 
> While his arguments are technically correct, I disagree with his conclusions
> because he's speaking with the point of view of an expert maintaining
> libraries at the boundary between unicode and bytes (like werkzeug). However,
> most Python users aren't experts and aren't maintaining such libraries. In my
> experience working with Python programmers ranging from intern to veteran, the
> unicode model of Python 3 is a strict improvement over Python 2 in terms of
> pitfalls hit in day-to-day programming. YMMV.
> 
> [1] http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/
> 
> -- 
> Aymeric.
> 
> OK, so Armin finds Python 2 better than Python 3. But why is it at odds with
> Django? He didn't say that he is not going to support Python 3. So where is
> the risk that concerns you?
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" 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/79dbbf71-6b70-48d1-8510-cef471812677%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.


-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [GSoC] Switching to Jinja2 proposal

[Christopher Medrela]

My last post was pretty long and the most important questions and statements
have left unanswered, so I will repeat them.

What I'm proposing now is more conservative proposal. Firstly, Django will
support Jinja2 out-of-the-box, but DTL will remain the "blessed" option.
Secondly, Django will allow to mix DTL and Jinja2 templates (so you can
include/inherit DTL template from Jinja2 one and vice versa).

After doing it, I could focus on 3) decoupling DTL or/and 4) rewriting 
Django
builtin templates in Jinja2 or/and 5) moving rendering form widgets from
Python code to Jinja2 templates.

After that all, we could start again the war DTL vs Jinja2, but please focus
on the new proposal now.

Questions are:

1) What do you think about the new proposal? Would it be useful?

2) Jinja2 doesn't support 3.2. Will Django 1.8 support 3.2?

3) Supporting Jinja2 out-of-the-box means introducing dependencies. Are we
   ready for this?

On Tuesday, February 11, 2014 2:07:19 PM UTC+1, Aymeric Augustin wrote:
>
> 2014-02-11 13:42 GMT+01:00 Christopher Medrela :
>  
>
>> What did Armin said about Python 3 exactly?
>
>
> He wrote an extensive argumentation about "why Python 2 [is] the better
> language for dealing with text and bytes" [1] as well as a number of tweets
> and a few other blog posts along the same lines.
>
> While his arguments are technically correct, I disagree with his 
> conclusions
> because he's speaking with the point of view of an expert maintaining
> libraries at the boundary between unicode and bytes (like werkzeug). 
> However,
> most Python users aren't experts and aren't maintaining such libraries. In 
> my
> experience working with Python programmers ranging from intern to veteran, 
> the
> unicode model of Python 3 is a strict improvement over Python 2 in terms of
> pitfalls hit in day-to-day programming. YMMV.
>
> [1] http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/
>
> -- 
> Aymeric.
>

OK, so Armin finds Python 2 better than Python 3. But why is it at odds with
Django? He didn't say that he is not going to support Python 3. So where is
the risk that concerns you?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/79dbbf71-6b70-48d1-8510-cef471812677%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: GSoC query

[anubhav joshi]

Well I will see what I put in my proposal..it will be based on 
aggregation/annotation as well as improving the error message part as 
before...I might now look to other things as well like improving tests as 
well.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/8be2174c-99f0-4ce7-ad26-691ac17fb319%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSOC] Improving the Test-Suite

[Chris Wilson]

Hi all,

On Sat, 15 Feb 2014, Russell Keith-Magee wrote:

One of the improvements I see is classification of test cases. 
Classifying them into categories (read multiple-categories), would make 
it easier for users/developers/maintainers to run them. Basis of 
classification,etc is what I am still thinking on. But surely 
classification will help in deciding which all test cases to run. For 
example - just running third-party app test cases, or just run my test 
cases, or those which check part ABC of my project, or just those with 
priority set to important.

[...]
I would envisage that this would be a declarative process - in code, 
marking a specific test as a "system" test or an "integration" test (or 
whatever other categories we develop).


It just occurred to me that most classification systems are completely 
arbitrary and therefore not very useful. What's a "system" test and how 
would I know whether I need to run it?


But some ideas that I can think of that might be useful are:

* Automatically building test coverage maps for each test, and reversing 
them, so we can see which tests touch the line(s) of code that we just 
modified, and rerun them easily. A good smoke test to run while modifying 
part of Django.


* Categorising by imports: run all tests that import django.db or 
django.core.http for example. Not perfect, some tests may touch facilities 
without needing to actually import them, but it would be quick and cheap.


* Profile and speed up the test suite, so that we can run all tests more 
quickly, especially with databases like postgres where it takes an hour to 
run them all.


Cheers, Chris.
--
Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838
Citylife House, Sturton Street, Cambridge, CB1 2QF, UK

Aptivate is a not-for-profit company registered in England and Wales
with company number 04980791.

--
You received this message because you are subscribed to the Google Groups "Django 
developers" 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/alpine.DEB.2.02.1402151512310.19498%40lap-x201.fen.aptivate.org.
For more options, visit https://groups.google.com/groups/opt_out.