Re: Proposal: switch to HTML5 for bundled templates

On Mar 29, 4:01 pm, Stephen Burrows wrote: > 3. There is a simple workaround going back to ie6 for handling the css > problems related to unrecognized tags. [3] ...snip... > [3]http://diveintohtml5.org/semantics.html#unknown-elements The workaround works if

Re: Trac components cleanup

On Mar 29, 4:47 pm, Gabriel Hurley wrote: > The component re-organization is done now, as per Julien's (and Jannis') > suggestions above. I even re-categorized the 84 tickets that were in > "Contrib apps" into their new separate contrib.foo components (thank god for > Trac bulk

Re: Template Compilation

Maybe. We solved that use-case by adding another custom directory to TEMPLATE_DIRS when we had to override the base template. But I can imagine that someone wants to be able to dynamically change the base template, from inside a view or context processor. This was a choice we made, because almost

Re: Proposal: switch to HTML5 for bundled templates

Using HTML5 tags in IE _will_ break it at some point. There is ofcourse the work around with "document.createElement('article')" etc used by modernizr But: 1. This will not work for IEs' that have JS disabled 2. Will break if you insert HTML5 tags by javascript into the "innerHTML" attribute

GSoC Student and Mentor Applications Open

Hi everyone, Just a reminder that student and mentor applications for GSoC are now open on the SoC website (middle column, at the bottom): http://www.google-melange.com/gsoc/homepage/google/gsoc2011 Students, you have until 7pm GMT on April 8th to get your submissions in; if you want more

Re: Proposal: switch to HTML5 for bundled templates

On 29/03/11 05:52, Gabriel Hurley wrote: > Switching to the HTML5 doctype won't hurt IE6 rendering (having dealt > with this myself several times). To the best of my knowledge--from my > own tests and third-party sources--using the new input attributes also > doesn't hurt IE6. However, if we start

Re: Trac milestones

On 29/03/11 03:29, Julien Phalip wrote: > Hi, > > Since we've recently been discussing a few ways to improve Trac, I'm > suggesting to move the discussion which started a few minutes ago in > #5833 here so as not to pollute the ticket with too many meta > conversations. I'd also like to apologise

Re: Suggestion: a new "nature" field in Trac

On 28/03/11 16:22, Luke Plant wrote: > On 28/03/11 15:50, Russell Keith-Magee wrote: > >> However, I accept your point about splitting bug into two categories. >> Making it two different flags was a suggestion for expediency of >> implementation, but I can see how it will complicate your life

Proposal for Template Engine Refactoring

Hi, I would like to participate in this year's Google Summer of Code by introducing a new backend for the Django (and Jinja2) templating language. As the author of Jinja2 I recently decided to rewrite the code generation of the engine to better support alternative Python implementations like PyPy

Re: Proposal for Template Engine Refactoring

Great. Google groups decided to reflow my mail. Here in actually readable version: http://paste.pocoo.org/show/362024/ Regards, Armin -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to

Re: Suggestion: a new "nature" field in Trac

On 29 March 2011 22:42, Luke Plant wrote: > As for the gardening, there are about 1700 open tickets that need the > type setting. Those needing the severity field changing to 'Blocker' can > be found more easily here: > > >

Re: Suggestion: a new "nature" field in Trac

On 28/03/11 13:04, Julien Phalip wrote: > On Mar 28, 10:49 pm, Karen Tracey wrote: >> +1 on having a distinction between bug, feature, and optimization. >> >> I don't think both "Uncategorized" and "Other" are necessary. > > My reasoning for "Other" was that there might be

Re: Proposal for Template Engine Refactoring

+1 on this. Are you planning on keeping the API for registering template tags compatible? (django.template.Library.register.tag) I think this may be required for backwards-compatibility, but personally, I'd like to see a cleaner API for this, which doesn't expose the parser details. (Writing

FOR template tag improvement

Hi, I've came up with an idea of improving default FOR template tag: {% for ... in ... %} By adding something similar to list comprehension syntax: {% for ... in ... if ... %} Filtering through looping is so common task that I'm sure many people would find this syntax quite handy. I'll be

Re: Proposal: switch to HTML5 for bundled templates

On 29/03/11 04:29, Julien Phalip wrote: > Since the patch is small, then it would be very quick to test it in > all browsers right away, no? :-) I've spent 20 minutes testing out the admin with this patch and IE6, and haven't found any issues (at least, none that aren't already present without

Re: Complains about FileField not deleting files in 1.3.

Hi Alex, On 03/29/2011 01:36 AM, Alex Kamedov wrote: > I think, cron jobs is an overhead in many simple cases where old > behaviour was useful and more simpler. > Why you don't want include DeletingFileField[1] in django? > > [1] https://gist.github.com/889692 Because, as mentioned above, it is

Re: Proposal for Template Engine Refactoring

Hi, On Mar 29, 2:23 pm, Jonathan S wrote: > Are you planning on keeping the API for registering template tags > compatible?  (django.template.Library.register.tag) It will be supported because otherwise upgrading won't be possible, but how well this works in detail

Re: FOR template tag improvement

Hi Mikołaj -- On Tue, Mar 29, 2011 at 8:45 AM, Mikołaj S. wrote: > I've came up with an idea of improving default FOR template tag: > {% for ... in ... %} > By adding something similar to list comprehension syntax: > {% for ... in ... if ... %} Can you give us some context

Re: FOR template tag improvement

There are reasons. 1. It's handy and quick to type. {% for x in lst %} {% if x.is_something %} {{ x }} {% endif %} {% endfor %} vs {% for x in lst if x.is_something %} {{ x }} {% endfor %} I really believe it is a common task. For me it is. 2. It's pythonic. It wouldn't

Re: Proposal for Template Engine Refactoring

Hi Armin -- Can you speak a little more about how you'd see the workflow working with this new library? It seems a bit complex to have a library that's *copied* between Django and Jinja: I'd worry about patches getting lost. For context, this has happened a few times with the simplejson and

Re: Proposal: switch to HTML5 for bundled templates

I think it would be helpful here to clearly distinguish three distinct varieties of "using HTML5," two of which are clear wins and one which I don't see any reason to do: 1. Switching to the HTML5 doctype in those few places where Django actually renders a full page with doctype (the admin,

Re: FOR template tag improvement

Sorry, but without a specific use-case I'm just not convinced. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to

Re: FOR template tag improvement

It's rather difficult to provide specific use case for something that is a convenience-related proposal. :) Let's make an analogy - why do we have AND boolean operator in IF tag, though we could just write: {% if first_condition %} {% if second_condition %} {{ x }} {% endif %} {%

New messages API: regressions ?

Greetings hackers, Django offered a feature to add messages to offline users, or to add messages to users in slots (if that's the pythonic name for "functions connected to signals"). It is still possible before 1.4, to call myuser.message_set.create() which doesn't need the request object. In

Re: FOR template tag improvement

Mikoskay, I understand Jacob. > It's rather difficult to provide specific use case for something that is a > convenience-related proposal. :) If its dificult to have a use case, may is not a good idea for a Open Source project trunk. And if its a "convenience-related proposal", its not a case

Single Table Inheritance

I'm sure this subject has been beaten to death, but I haven't found an answer to a simple scenario and I'm wondering why this hasn't been addressed before. I have three models, structured like so: Document -Presentation -Spreadsheet Document is never instantiated on its own; a prime candidate

Re: Single Table Inheritance

On Tue, Mar 29, 2011 at 11:11 AM, Carl Meyer wrote: > Hi Jordan, > > On 03/29/2011 11:40 AM, Jordan MacDonald wrote: >> I have three models, structured like so: >> >> Document >> -Presentation >> -Spreadsheet ... >> I'd like to be able to write >> Document.objects.all(). I'd

Re: Proposal for Template Engine Refactoring

Hi, On Mar 29, 3:54 pm, Jacob Kaplan-Moss wrote: > Can you speak a little more about how you'd see the workflow working > with this new library? It seems a bit complex to have a library that's > *copied* between Django and Jinja: I'd worry about patches getting > lost. I

Re: Single Table Inheritance

On 03/29/2011 12:40 PM, Jeremy Dunck wrote: > What about keeping abstract inheritance in this case, but allowing > Document.objects.* to work by returning instances of the subclasses. > Filtering, etc. would only work based on the Document base class. > > It would mean doing some unions, but

Re: Suggestion: a new "nature" field in Trac

+1 on blocker being a severity, -0 on "other" as an option here. +0 on the others. Happy to donate a couple hours reviewing a chunk of tickets in a coordinated way if we decide to do that. - Gabriel -- You received this message because you are subscribed to the Google Groups "Django

Re: Single Table Inheritance

Cool. Well, maybe I can look into how abstract base classes are currently implemented and see if there's a way to generate query sets for all derived classes from the parent. Thanks for the insight! On Mar 29, 12:40 pm, Carl Meyer wrote: > On 03/29/2011 12:40 PM, Jeremy Dunck

Re: Single Table Inheritance

Hopefully someone on the core dev team can let me know if this is possible in Django. If so, it will solve this problem. I am not familiar with custom metaclass stuff done within models.Model. 1. Create a custom metaclass as described in "Pro Python," page 124. 2. Add this metaclass to the

Re: Single Table Inheritance

On Tue, Mar 29, 2011 at 11:40 AM, Carl Meyer wrote: > On 03/29/2011 12:40 PM, Jeremy Dunck wrote: >> What about keeping abstract inheritance in this case, but allowing >> Document.objects.* to work by returning instances of the subclasses. >> Filtering, etc. would only work

Re: Single Table Inheritance

Hi Shawn, On 03/29/2011 01:28 PM, Shawn Milochik wrote: > Hopefully someone on the core dev team can let me know if this is > possible in Django. If so, it will solve this problem. > I am not familiar with custom metaclass stuff done within models.Model. > > 1. Create a custom metaclass as

Re: Single Table Inheritance

On Tue, Mar 29, 2011 at 2:21 PM, Carl Meyer wrote: > Hi Shawn, > > What you've outlined here is certainly possible (and yes, you'd need to > subclass the ModelBase metaclass). I haven't looked at the abstract > inheritance stuff recently, but I think there would be some

Re: Single Table Inheritance

On 03/29/2011 02:46 PM, Shawn Milochik wrote: > I'm not proposing a change to Django itself or suggesting that this > should be a standard practice. I do think that this is a fairly clean > solution for an individual to use to solve this problem if they have > it. > > They can create a custom

Re: Single Table Inheritance

Am 29.03.2011 um 20:46 schrieb Shawn Milochik: > They can create a custom manager on the abstract class that would > return an iterable, perhaps using itertools.chain() of the querysets. > > It depends on what they expect to do with the output of this custom > manager, and they'd obviously lose

Re: FOR template tag improvement

On Tue, Mar 29, 2011 at 10:32 PM, Mikoskay wrote: > It's rather difficult to provide specific use case for something that is a > convenience-related proposal. :) The opposite should be true. If this is a proposal that is so convenient, there must be many ways in which it

Re: Suggestion: a new "nature" field in Trac

On Tue, Mar 29, 2011 at 8:17 PM, Luke Plant wrote: > On 28/03/11 13:04, Julien Phalip wrote: >> On Mar 28, 10:49 pm, Karen Tracey wrote: >>> +1 on having a distinction between bug, feature, and optimization. >>> >>> I don't think both "Uncategorized"

Re: FOR template tag improvement

On Tue, Mar 29, 2011 at 7:19 PM, Russell Keith-Magee < russ...@keith-magee.com> wrote: > On Tue, Mar 29, 2011 at 10:32 PM, Mikoskay wrote: > > It's rather difficult to provide specific use case for something that is > a > > convenience-related proposal. :) > > The opposite

Re: Django Lines of Code

Sorry for that, but thanks for the answer. On Mar 28, 1:36 pm, Jacob Kaplan-Moss wrote: > On Mon, Mar 28, 2011 at 3:29 PM, Andrea Zilio wrote: > > I was just wondering if anyone knows the total number of lines of code > > of Django. > > Hi Andrea -- > >

Re: FOR template tag improvement

I think it's not that pythonic as it's just another syntax to do a thing that we are already able to do with the current syntax. -1. -- Vinicius Mendes Globo.com On Tue, Mar 29, 2011 at 9:19 PM, Alex Gaynor wrote: > > > On Tue, Mar 29, 2011 at 7:19 PM, Russell

Re: Proposal: switch to HTML5 for bundled templates

Maybe start thinking in other way. Most of users has JS enabled browsers, if so, modernizr works. Otherwise jQuery will not work either. I can't remember when someone who has IE6 hit one of my django based sites. Maybe convert django to html5, and those who has to care about ie6 support should