Re: Revisiting multiline tags

>> 1) It's an easy fix. >> 2) It's backwards compatible. >> 3) It has no impact on performance. >> 4) LOTS of people want it. >> >> and most importantly >> >> 5) We could stop asking for it. >> >> This issue is such an easy "sure, why not!?" >> >> Please, O benevolent dictators, listen to the p

Django and dictionary ordering

Is there any work going on with regard to making Django more resilient in the face of changes to dictionary ordering? I know there has been discussion about the hash collision issue last December, but I'm unable to find a summary of the official Django position on this. Can someone please point me

Re: Revisiting multiline tags

On 24/02/2012, at 7:01 PM, Stephan Jaensch wrote: >>> 1) It's an easy fix. >>> 2) It's backwards compatible. >>> 3) It has no impact on performance. >>> 4) LOTS of people want it. >>> >>> and most importantly >>> >>> 5) We could stop asking for it. >>> >>> This issue is such an easy "sure, wh

Re: Revisiting multiline tags

On Fri, Feb 24, 2012 at 4:19 AM, Bradley Ayers wrote: > > In the interest of making the wider community opinion heard, I too am +1 on > this, my feeling is exactly the same as Stephen. > > -- +1 I understand that a BDFL has spoken and this change isn't going to happen. I hate to add to the nois

Re: Revisiting multiline tags

A +1 from me too, I've really felt the pain on this when doing i18n templates, I understand the aesthetics, but the aesthetics of obscenely long tags is also bad imo... On 24 February 2012 09:23, Shawn Milochik wrote: > On Fri, Feb 24, 2012 at 4:19 AM, Bradley Ayers > wrote: >> >> In the intere

Re: Django and dictionary ordering

The official Django position on the Python hash randomization issue is that this Python bug has been fixed in Python. Users of Django should explicitly enable hash randomization for versions of Python below 3.3. We'll probably make a formal announcement and writeup for how to do this once the chang

Re: Revisiting multiline tags

+1 from me too - I've used {# #} across line boundaries before and wondered why it didn't work, since it didn't seem especially clear that this doesn't work nor why it doesn't work - I'd just substituted for the obvious and eventually just deleted the offending HTML. On Feb 24, 2012 9:30 AM, "Chri

Re: Revisiting multiline tags

On 02/24/2012 10:01 AM, Stephan Jaensch wrote: This thread contains 6 people expressing support for this change, and 2 against (a BDFL, a core developer) -- and you can add me to the -0 list. There are over 6000 subscribers to django-developers. I put it to you that the vast majority of people

Re: Revisiting multiline tags

On 02/24/2012 01:29 PM, Chris Northwood wrote: > A +1 from me too, I've really felt the pain on this when doing i18n > templates, I understand the aesthetics, but the aesthetics of > obscenely long tags is also bad imo... > > On 24 February 2012 09:23, Shawn Milochik wrote: >> On Fri, Feb 24, 201

django 1.4b + mysql + boolean fields

Hello, I've changed my database from postgresql to mysql. I have never used mysql in django projects before, so it was surprising to me when i saw 0/1 values instead of True/False in boolean fields. It wasn't an issue until i upgraded django from 1.3.1 to 1.4b. After that, all boolean fields

Re: django 1.4b + mysql + boolean fields

Ticket with change described below: https://code.djangoproject.com/ticket/17114 I've also found that since Django 1.2 (https://docs.djangoproject.com/en/dev/releases/1.2/#booleanfield-on-mysql) booleans in mysql backend should be returned as True/False, but i still get ints values. In [7]:

Re: django 1.4b + mysql + boolean fields

The problem was caused by django.contrib.gis.db.backends.mysql backend. It has own backend implementation which returns booleans as integers (it was fixed for 'core' mysql backend in https://code.djangoproject.com/ticket/13293 ) I think it's a bug which will afect some users after upgrading to

Re: Revisiting multiline tags

Since we're consensus building or whatever the fancy term is, another +1. Mainly for comments, since {# #} is far, far more readable than {% comment %}{% endcomment %} even with syntax highlighting, but also for other tags too, particularly long i18n ones -- or even relatively short ones where you

Newline stripping in templates: the dnl way

Hi all, regarding issue #2594 "Template system should handle whitespace better" explaining the need for some kind of (optional) whitespace stripping from the output of templates, I've been looking at the proposed solutions and compared them to other template and macro engines. In particular, a his

Re: Django and dictionary ordering

On 24 February 2012 10:31, Paul McMillan wrote: > The official Django position on the Python hash randomization issue is > that this Python bug has been fixed in Python. Users of Django should > explicitly enable hash randomization for versions of Python below 3.3. > We'll probably make a formal a

Re: Newline stripping in templates: the dnl way

I definitely want to see a resolution to this issue. Django templates when white space matters (e.g. plain text emails) are painful. But, I don't think adding {# to the end of lines is easy to understand at a glance, it doesn't even convey a hint of meaning like "dnl" does, but either option is pre

Re: Newline stripping in templates: the dnl way

On Fri, Feb 24, 2012 at 2:10 PM, Tobia wrote: > Hi all, > regarding issue #2594 "Template system should handle whitespace > better" explaining the need for some kind of (optional) whitespace > stripping from the output of templates, I've been looking at the > proposed solutions and compared them t

Re: Revisiting multiline tags

On Fri, Feb 24, 2012 at 6:01 AM, Stephan Jaensch wrote: >> This thread contains 6 people expressing support for this change, and 2 >> against (a BDFL, a core developer) -- and you can add me to the -0 list. >> There are over 6000 subscribers to django-developers. I put it to you that >> the vas

Re: Revisiting multiline tags

On Fri, Feb 24, 2012 at 10:01 AM, Daniel Moisset wrote: > On Fri, Feb 24, 2012 at 6:01 AM, Stephan Jaensch wrote: > >> This thread contains 6 people expressing support for this change, and 2 > against (a BDFL, a core developer) -- and you can add me to the -0 list. > There are over 6000 subscribe

Re: Revisiting multiline tags

On Fri, Feb 24, 2012 at 12:12 PM, Alex Gaynor wrote: > > Folks, you seem to have missed Russell's point.  Even if 100 people +1 this, > it's meaningless.  That's a tiny fraction of this mailing list's readership, > much less of the Django community at large.  Django is the way it is > because, fir

Re: Revisiting multiline tags

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/23/2012 11:29 PM, Russell Keith-Magee wrote: > This thread contains 6 people expressing support for this change, and > 2 against (a BDFL, a core developer) -- and you can add me to the -0 FWIW, I'd forgotten how painful the single-line restricti

Re: Revisiting multiline tags

Mark me a +1 on this as well. Many of us don't ask for items in discussion that have been marked as "won't fix" because we don't realize that the decisions on these items can be reversed. Thanks, Paul On Fri, Feb 24, 2012 at 2:19 AM, Bradley Ayers wrote: > > On 24/02/2012, at 7:01 PM, Stephan

Re: Revisiting multiline tags

On Fri, Feb 24, 2012 at 3:12 PM, Alex Gaynor wrote: > Folks, you seem to have missed Russell's point.  Even if 100 people +1 this, > it's meaningless.  That's a tiny fraction of this mailing list's readership, > much less of the Django community at large.  Django is the way it is > because, first

Re: Revisiting multiline tags

+1 and reason as previously stated: it makes sense to brake down very long tags for readability purposes. From: Alex Gaynor Sent: Friday, February 24, 2012 10:12 AM To: django-developers@googlegroups.com Subject: Re: Revisiting multiline tags On Fri, Feb 24, 2012 at 10:01 AM, Daniel Moisset

Re: django 1.4b + mysql + boolean fields

Please go ahead, create a ticket and set its severity to "release blocker". Assuming a proper test was added with the fix for #13293, that test should fail on the geographic version of mysql. Unfortunately we don't have this engine on the CI server at this time. I'll try to add it. Thanks for you

Re: django 1.4b + mysql + boolean fields

Hello Tomasz, On 02/24/2012 03:00 AM, Tomasz Kloc wrote: > I've changed my database from postgresql to mysql. I have never used > mysql in django projects before, so it was surprising to me when i saw > 0/1 values instead of True/False in boolean fields. It wasn't an issue > until i upgraded djang

Re: django 1.4b + mysql + boolean fields

I just noticed that #17747 was reopened for this purpose, so there's no need for another ticket. Best regards, -- Aymeric. 2012/2/24 Aymeric Augustin > Please go ahead, create a ticket and set its severity to "release blocker". > > Assuming a proper test was added with the fix for #13293, tha

Re: django 1.4b + mysql + boolean fields

On Fri, Feb 24, 2012 at 7:53 AM, Tomasz Kloc wrote: > The problem was caused by django.contrib.gis.db.backends.mysql backend. It > has own backend implementation which returns booleans as integers (it was > fixed for 'core' mysql backend in > https://code.djangoproject.com/ticket/13293 ) > > I thi

Re: Newline stripping in templates: the dnl way

On Fri, Feb 24, 2012 at 9:45 AM, Tom Evans wrote: > In your folder are: > {^ for item in folder ^} > {{ item }}, > {^ endfor ^} > > This would render as "In your folder are: item1,item2,item3," > > Changing some of the carets: > > In your folder are: > {% for item in folder ^} > {{ item }}, > {^ e

Re: Revisiting multiline tags

With all the voting and aesthetic discussion, maybe let's get back to technical details: On 24 February 2012 05:18, colinta wrote: > 1) It's an easy fix. Maybe it is, I can only judge a specific patch, > 2) It's backwards compatible. Right now, tags are free to parse the tag contents any way t

Re: Revisiting multiline tags

On 24 February 2012 17:29, Łukasz Rekucki wrote: > With all the voting and aesthetic discussion, maybe let's get back to > technical details: > > On 24 February 2012 05:18, colinta wrote: >> 1) It's an easy fix. > > Maybe it is, I can only judge a specific patch, > >> 2) It's backwards compatible

Re: Newline stripping in templates: the dnl way

For this (avoiding newlines) the currently discussed multiline tags would work pretty well too without adding more cruft to the template language: foo bar {# #}baz mjl -- You received this message because you are subsc

Re: Newline stripping in templates: the dnl way

2012/2/24 mjl Martin J. Laubach > For this (avoiding newlines) the currently discussed multiline > tags > would work pretty well too without adding more cruft to the template > language: > > foo bar {# > #}baz > > > Martin,

Re: Revisiting multiline tags

> If you'd like to make an argument as to *why* it's useful, that's useful, but > we don't take polls. I think the argument as to why it's useful as been made quite extensively. On the flip side, beside the ivory tower philosophical stance, I did not see much compelling argument as to *why* this

Re: Revisiting multiline tags

On Fri, Feb 24, 2012 at 12:06 PM, h3 wrote: > > If you'd like to make an argument as to *why* it's useful, that's > useful, but we don't take polls. > > I think the argument as to why it's useful as been made quite > extensively. > > On the flip side, beside the ivory tower philosophical stance,

Re: Newline stripping in templates: the dnl way

Tai Lee wrote: > I don't think adding {# to the end of lines is easy to understand at a > glance, it doesn't even convey a hint of meaning like "dnl" does I beg to differ. {# is already recognized by template authors as meaning "start of comment", and they know (or should know) that it cannot ext

Re: Newline stripping in templates: the dnl way

Jinja implements whitespace control by putting a minus sign after/before the % in a tag - http://jinja.pocoo.org/docs/templates/#whitespace-control - I haven't tried it myself, but it looks like {% tag -%} is equivalent to your {% tag %}{# . On 24 February 2012 17:37, Tobia wrote: > Tai Lee wrot

Re: Revisiting multiline tags

On 24 February 2012 17:16, Alex Gaynor wrote: > > > On Fri, Feb 24, 2012 at 12:06 PM, h3 wrote: > >> > If you'd like to make an argument as to *why* it's useful, that's >> useful, but we don't take polls. >> >> I think the argument as to why it's useful as been made quite >> extensively. >> >> O

Re: Revisiting multiline tags

> Folks, you seem to have missed Russell's point. Even if 100 people +1 > this, it's meaningless. That's a tiny fraction of this mailing list's > readership, much less of the Django community at large. If the maintainers of Django want to make a personal taste-based decision rather than a popula

integration of sphinx documentation in a website a la https://www.djangoproject.com/

Hi, I just got started using Sphinx to generate documentation, and am loving it.. beautiful and (relatively) painless. I am interested in making a website using a Python framework (probably Flask) that includes some Sphinx-generated documention, and am thinking about different ways to accompli

Re: integration of sphinx documentation in a website a la https://www.djangoproject.com/

Hey, did you know that the webpage is opensource? You can take a look yourself: https://github.com/django/djangoproject.com Cheers, Florian On Friday, February 24, 2012 10:33:54 PM UTC+1, d b wrote: > > Hi, > > I just got started using Sphinx to generate documentation, and am loving > it.. bea

Re: Newline stripping in templates: the dnl way

Hi, On Friday, February 24, 2012 7:48:29 PM UTC+1, ojno wrote: > > Jinja implements whitespace control by putting a minus sign after/before > the % in a tag - http://jinja.pocoo.org/docs/templates/#whitespace-control - > I haven't tried it myself, but it looks like {% tag -%} is equivalent to >

Re: Newline stripping in templates: the dnl way

s/why/way/ sry :( On Friday, February 24, 2012 11:47:21 PM UTC+1, Florian Apolloner wrote: > > Hi, > > On Friday, February 24, 2012 7:48:29 PM UTC+1, ojno wrote: >> >> Jinja implements whitespace control by putting a minus sign after/before >> the % in a tag - >> http://jinja.pocoo.org/docs/te

Re: Newline stripping in templates: the dnl way

Adding more symbols to existing tags (e.g. {^ for x in y ^} or {% for x in y -%}), multi-line comment tags that don't actually include a comment, and half baked comment tags (where the closing tag is assumed) are all going to make templates uglier, and harder to read. The comment tag based solutio

Re: Revisiting multiline tags

I'm -1 on this for s specific reason; If you need multiple lines for a tag, you're doing it wrong. >>> import this -- 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

Testing multidb without inconsistency

I have a master and a replica. In test, the TEST_MIRROR on the replica points to master. I make writes to master, then read from replica, then assert some numbers. def test_stuff(self): Foo.objects.using('master').create() number_received = do_expensive_computations() # Down in some