Re: [GSoC] Switching to Jinja2 proposal

[Gwildor Sok]

There are a few problems with Christian's assumptions:

* Not everyone uses a JS Framework. Personally, we use a lot of static 
pages, and when we do want to do some fancy stuff, we use 
pjaxto replace content on the page, but 
in the backend this is still done by 
rendering a full template through a Django view.
* The templating language is also used for small stuff, and the switch to 
Jinja would enable using the templating language for even more stuff. The 
biggest issue that comes to mind are template-based 
widgets
.

Personally, I'm in favor of switching to Jinja. The speed bonus and the 
ability to call functions with arguments are great features for me. One 
downside I can think of is that Jinja does not escape variables by default, 
which might become a XSS security issue.

On Wednesday, February 12, 2014 9:10:29 AM UTC+1, Christian Schmitt wrote:
>
> I'm not a django-developer, but I'm creating a lot of applications with 
> Django and I would never want to switch to Jinja2.
>
> Why?
>
> The first thing is that Django Templates are simple to understand, they 
> are not formed as a new DSL or a Programmable way of a Template language.
> Their Syntax is clear and simple and it's really easy to extend the tags 
> for new programmers aswell.
>
> I only had a quick overview of Jinja2 but the Syntax aswell as other 
> things just looking more like a programming language for templates than a 
> simple templating engine.
>
> Also the Template Language or the Django interface is most of the time not 
> the bottleneck of any application (there are some exceptions where the 
> template engine or some django views will be a bottleneck but most of the 
> time there is a easy way to solve it like using c)
> Nearly 90% of the time you will have trouble with the database.
>
> Changing the Template Language will maybe looking good on benchmark 
> papers, but i don't think that it will help scaling websites to need less 
> servers. (Django also has a really good and easy way to scale up really 
> good, thanks to the DatabaseRouters, Cache Engine, Session Engine, etc. you 
> could Scale out/up really, really well)
>
> The next thing is that the internet is changing and template languages 
> that are on the server side getting less focus.
> Mostly applications are more and more and API which will getting consumed 
> by a Framework like AngularJS or KnockoutJS.
> So there is no need for a faster template language, since the Django 
> Template Language is fast enough for the Django Admin or other applications 
> where a Template Engine is still needed.
>
> I hope that the most people understood my points and that my english isn't 
> too bad.
>
> For me switching to jinja2 wouldn't make any sense. 
> Also we changed a lot of app loading stuff, so my applications needing to 
> be migrated. While I think that I have a lot of stuff that needs to be 
> refactored when I switch to Django 1.7 I don't want to have a lot of 
> backwards incompatible stuff in Django 1.8 or Django 1.9, too.
>
>
>
>
>
> 2014-02-11 14:07 GMT+01:00 Aymeric Augustin 
> 
> >:
>
>> 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.
>>
>>  -- 
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to 
>> django-d...@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/CANE-7mU31zMRkVrJAZY_tde-xdiU63p2s38pB2vVPpeDpPBkxQ%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-develop

Re: bootstrap default admin theme

[Gwildor Sok]

This looks pretty slick. The styling the admin uses currently really needs 
an update, and in that way this project could be a really nice boost and/or 
contribution. I'm not entirely sure however that having Bootstrap as a 
major dependency is the way to go. Perhaps it's better to keep it a bit 
simpler, CSS speaking, and allow easy overriding of the styling by 
providing a custom CSS, so that every project can easily change the styling 
of the admin. I also think the underlying views would benefit from a 
rewrite, and it would be handy to do that with the restyling.

Long story short: Django's default admin UI definitely needs a redesign, 
but I'm not sure this project is the way to go to merge into Django itself. 
It's probably better to do that as part of the real Django development 
cycle, so views can be adjusted as needed, and without being so bloated 
with so many dependencies.

On Thursday, February 6, 2014 6:14:48 PM UTC+1, adam spence wrote:
>
> Hi,
>
> I'd like to contribute my Django admin theme to core django. It uses 
> bootstrap 3 and is a much nicer ui. The prototype is here:
> https://github.com/spenoir/django-admintools-bootstrap
>
> At the moment it relies on mediagenerator which I am planning to remove. 
> If people were interested in me building a theme for the default Django 
> admin in bootstrap then I could greatly reduce the dependencies.
>
> cheers,
> adam
>
>

-- 
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/618baf67-2e8e-4a8d-8a62-6eb7d0b5d9af%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: allow list_display in admin to traverse onetoonfields and foreign key relations

[Gwildor Sok]

Personally I usually use lambda's, which saves another line of code:
class ChoiceAdmin(admin.ModelAdmin):
question__text = lambda s, o: o.question.text  
list_display = ('pk', 'question__text', 'choice_text', 'votes')


On Wednesday, February 26, 2014 6:49:51 AM UTC+1, Zach Borboa wrote:
>
> I agree that the current behaviour is confusing and needs change in order 
> to be DRY[1] and consistent[2].
>
> [1] 
> https://docs.djangoproject.com/en/dev/misc/design-philosophies/#don-t-repeat-yourself-dry
> [2] 
> https://docs.djangoproject.com/en/dev/misc/design-philosophies/#consistency
>
>
>
> This is how I currently work around this issue.
>
> models.py
> class Question(models.Model):
> text = models.CharField(max_length=200)
> pub_date = models.DateTimeField('date published')
>
> class Choice(models.Model):
> question = models.ForeignKey(Question)
> choice_text = models.CharField(max_length=200)
> votes = models.IntegerField(default=0)
>
> admin.py
> class ChoiceAdmin(admin.ModelAdmin):
> def question__text(self, obj):
> return obj.question.text
>
> list_display = ('pk', 'question__text', 'choice_text', 'votes')
>
> admin.site.register(Choice, ChoiceAdmin)
>
>
>
>
>
>
> On Tuesday, February 25, 2014 3:48:40 PM UTC-8, Wim Feijen wrote:
>>
>> Hello,
>>
>> Right now I have a School model containing a OneToOne-relation to User.
>>
>> In the admin, in search_fields, I can use double underscores to search in 
>> related fields, for example:
>> search_fields = ('place__name', 'school__name')
>>
>> But in list_display, I can't. For example,
>> list_display = ['school', 'school__user', 'place', ]
>> gives an error.
>>
>> I find this totally confusing. More people do.
>>
>> A ticket has been made six years ago and was eventually closed as won't 
>> fix. Currently, the proposed solution is to write a custom method or 
>> callable. I'd like to raise a discussion to reopen that ticket.
>>
>> For reference, see:
>> https://code.djangoproject.com/ticket/5863
>> https://groups.google.com/forum/#!topic/django-developers/eQSEv74bQh8
>>
>> My arguments to allow such a syntax are:
>>
>> 1. allowing 'school__user' in list_display is consistent with the 
>> behaviour of search_fields, list_filter in the admin, and get() and 
>> filter() query syntax in general.
>> 2. it saves many people duplicating two to four lines of custom code, and 
>> in my opinion, allows for a more concise yet extremely easy to understand 
>> notation.
>> 3. ideally, a solution would use select_related in order to save database 
>> queries and thus be longer than two to four lines of code.
>> 4. the need is common, and in onetoonefields specifically. Many people 
>> have expressed their interest in this feature, and a core developer 
>> initially accepted it.
>> 5. a long time has passed since then and our policy of accepting tickets 
>> has changed.
>>
>> Thanks for reading! I'd love to hear your response.
>>
>> Regards, Wim
>>
>

-- 
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/96177bfe-e83a-4b35-9bab-0ff8fe3b3839%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSOC] Shifting to Py.Test and Improving the Test Suite

[Gwildor Sok]

Personally I'm a big fan of Py.test, simply because it's so simple and 
Pythonic to use. Simple functions with simple assert statements. That's 
all. For me this significantly lowers the threshold to write tests and 
requires less effort, which in the end results in way more tests written in 
Py.test than the testsuite Django is currently using.

This is a talk I watched when I was looking for alternative test suites and 
got me hooked: http://www.youtube.com/watch?v=DTNejE9EraI

On Thursday, February 27, 2014 9:10:58 PM UTC+1, Andrew Pashkin wrote:
>
>
>>>1. Distributed testing (speed up, especially on multi-core 
>>>machines), Line Coverage, etc using plugins
>>>
>>> How would this work? We still have shared resources like the database 
>> where you can't just run 10 Test against in parallel.
>>
>
> There is django plugin for 
> py.testexists, it is able to create 
> separate DBs for each process.
>
> On Thursday, February 27, 2014 11:59:56 PM UTC+4, Florian Apolloner wrote:
>>
>> Hi Akshay,
>>
>> On Thursday, February 27, 2014 8:50:32 PM UTC+1, Akshay Jaggi wrote:
>>>
>>> *Why Py.Test?* (http://pytest.org)
>>>
>>>1. Widely Used
>>>
>>> So is nose and unittest, you'll need to add a bit more info to such 
>> statements. 
>>
>>>
>>>1. Better reporting
>>>
>>> Better how exactly? 
>>
>>>
>>>1. Distributed testing (speed up, especially on multi-core 
>>>machines), Line Coverage, etc using plugins
>>>
>>> How would this work? We still have shared resources like the database 
>> where you can't just run 10 Test against in parallel.
>>
>> 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/63ae1993-33c9-457c-b995-ee3fe079e50f%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Add support for get_or_none?

[Gwildor Sok]

Actually, at the moment you can't have a column named "defaults" either if 
you want to use your model with the current get_or_create function, so 
naming a keyword argument like that is not that uncommon.

On Sunday, March 16, 2014 6:39:47 PM UTC+1, Cal Leeming [Simplicity Media 
Ltd] wrote:
>
> Still waiting for other people to chime in on this thread, but so far I'm 
> not seeing any argument against the explained logic for having 
> `.get_or_none()`. 
>
> Comments appear to be more regarding how not to do it, rather than not 
> doing it at all.
>
> Ultimately this either needs someone to find a flaw in my logic (have I 
> missed anything?), or needs a BDFL decision.
>
> If all this needs to get approved is a patch, then I'll be happy to do so.
>
> Cal
>
>
>
>
> On Sat, Mar 15, 2014 at 5:06 PM, Shai Berger 
> > wrote:
>
>> There is a family of names that would be valid -- names that cannot be 
>> used to
>> name fields -- and that is names that begin with dunder.
>>
>> I would like to see neither get(__default=x) nor first(__only=True) -- I 
>> think
>> that's quite ugly -- I just want to remind us that technically, the option
>> exists.
>>
>> On Friday 14 March 2014 12:40:25 Michael Manfre wrote:
>> > Good point. I forgot that some people would do that.
>> >
>> >
>> > On Fri, Mar 14, 2014 at 11:52 AM, Florian Apolloner
>> >
>> > >wrote:
>> > > On Friday, March 14, 2014 4:50:49 PM UTC+1, Michael Manfre wrote:
>> > >> On Fri, Mar 14, 2014 at 11:15 AM, Cal Leeming [Simplicity Media Ltd] 
>> <
>> > >>
>> > >> cal.l...@simplicitymedialtd.co.uk> wrote:
>> >  .get(or=None) (of some description) would be my preference, but 
>> even
>> >  that is ugly and confuses the existing API with "special" keywords 
>> that
>> >  aren't actually a filter.
>> > >>>
>> > >>> I would be strong -1 on having a special keyword.
>> > >>
>> > >> Even if the special keyword is 'default'? .get(..., default=None) is 
>> a
>> > >> common python pattern that fits well with this usage.
>> > >
>> > > Yes, especially 'default' -- which is a perfectly valid name for a 
>> table
>> > > column.
>> > >
>> > > --
>> > > 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-develop...@googlegroups.com .
>> > > To post to this group, send email to 
>> > > django-d...@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/4aa7d1e3-4fb3-429e-a95
>> > > a-6e52cc9b511a%40googlegroups.com<
>> https://groups.google.com/d/msgid/django
>> > > -developers/4aa7d1e3-4fb3-429e-a95a-6e52cc9b511a%
>> 40googlegroups.com?utm_me
>> > > dium=email&utm_source=footer> .
>> > >
>> > > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to 
>> django-d...@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/3039581.NUMVpPu4sL%40deblack
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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/3623f921-4c6f-4e5f-af9a-fc8e5d656c5b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSoC] Switching to Jinja2 proposal

[Gwildor Sok]

So, there won't be a GSoC project for this, but it would be a shame to let 
the lengthy discussion and momentum generated go to waste. Can a decision 
on this matter be made and implemented regardless of the GSoC projects?

Personally, I'm all for it, mostly because of the speed gained, which would 
finally allow ticket #15667 to be 
solved, which is a really important one to me because it addresses 
one of the core modules of Django and one which is behaving pretty sloppy 
compared to the better ones, in my humble opinion.

On Sunday, March 16, 2014 6:07:14 PM UTC+1, Christopher Medrela wrote:
>
> Hello! I'm sorry for such long time without any feedback. Unfortunately, 
> I'm
> not going to send Django proposal. My original plan was to send two 
> proposals:
> one for Django and one for Breeze (Scala numerical processing library) but 
> I
> lack time and I will focus on Breeze. Therefore, I won't have enough time 
> to
> work at adding Jinja2 support this summer.
>
> Thank you very much for all responses! Lots of DTL aspects were discussed 
> here
> and we reached consensus in some issues (like adding out-of-the-box 
> support of
> Jinja2) so I hope that the time you spent at this thread is not lost time.
> Maybe there will be some other students eager to work at template system?
>

-- 
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/bec73964-2fde-4b2c-a0f8-7ccf4ff9d149%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Built-in support for Jinja2 in Django

[Gwildor Sok]

It's good to see something happening after the lengthy discussion of last 
February on this mailing list. Thank you for taking initiative in this. I 
believe this will be a great addition to make Django even better.

On Thursday, October 2, 2014 1:28:01 AM UTC+2, Russell Keith-Magee wrote:
>
>
> On Thu, Oct 2, 2014 at 3:04 AM, Aymeric Augustin <
> aymeric@polytechnique.org > wrote:
>
>> Hello,
>>
>> I've been thinking about providing built-in support for Jinja2 in Django. 
>> I found that supporting pluggable template engines, like Django does for 
>> databases, caches, etc. would be the most elegant solution. The best 
>> summary I have at this time is on the crowdfunding campaign's page: 
>> http://igg.me/at/mtefd.
>>
>> I will submit a detailed proposal to this mailing-list as soon as I have 
>> a sufficiently good version. Until then, if you hear noises, don't worry -- 
>> there will be a technical discussion here before any decision.
>>
>  
> SHUT UP AND TAKE MY MONEY!!!1!1!BBQ!
>  
> Seriously - thanks for taking this on. It's yet another of those huge 
> projects with huge potential impact that you seem to excel in tackling. 
> Can't wait to see the results!
>
> Yours,
> Russ Magee %-)
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ce7956c7-2ae6-4b95-aa1e-539cb81c3267%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.