[ANN] Django 1.3 alpha 1 released

[James Bennett]

The first alpha preview package for Django 1.3 is now available.

* Release notes: http://docs.djangoproject.com/en/dev/releases/1.3-alpha-1/

* Download instructions: http://www.djangoproject.com/download/


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Receipt for mail to security@ ?

[Russell Keith-Magee]

On Thu, Nov 11, 2010 at 11:37 AM, Paul McMillan  wrote:
> In general, it would be helpful to have an auto-responder on that
> address (so we know our reports didn't end up in a spambox), and a
> more specific timeframe for expected response noted on the website.
> It's great to have the list, but if a response really is going to take
> a week, it would be helpful to note that somewhere so reporters don't
> worry that their report has gone to a black hole.

I'd argue that an autoresponder is almost exactly what we *don't*
need. An autoreponder can give the illusion of that a message has been
received when it's really just a robot going through the motions. The
worst possible situation would be an autoreponse message that says
"We're looking into it" when the message has actually fallen into the
bit bucket.

The real solution here is to make sure that the security mailing list
is sufficiently well staffed that no message goes 24 hours without
getting a response from a live human being. We (the core team) are
aware that responses haven't been as prompt as they should be over the
last 6 months or so, and we're looking into ways of improving this
situation.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Settings for a pure Oracle multi-db Django test suite setup

[Ramiro Morales]

On Wed, Nov 10, 2010 at 10:06 PM, Ian Kelly  wrote:
>
> Yes, here are the settings I'm using:
>
> DATABASES = {
>     'default': {
>     'ENGINE': 'django.db.backends.oracle',
>     'NAME': 'xe',
>     'USER': 'ikelly',
>     'PASSWORD': 'ikelly',
>     'OPTIONS': {'threaded': True},
>     'TEST_USER': 'django_test_default',
>     'TEST_TBLSPACE': 'django_test_default',
>     'TEST_TBLSPACE_TMP': 'django_test_default_temp',
>     },
>
>     'other': {
>     'ENGINE': 'django.db.backends.oracle',
>     'NAME': 'xe',
>     'USER': 'ikelly',
>     'PASSWORD': 'ikelly',
>     'OPTIONS': {'threaded': True},
>     'TEST_USER': 'django_test_other',
>     'TEST_TBLSPACE': 'django_test_other',
>     'TEST_TBLSPACE_TMP': 'django_test_other_temp',
>     },
> }
>
> The key is that NAME should be the same ('xe') for both entries, since
> you're really establishing two connections to the same database.  The
> TEST_USER, TEST_TBLSPACE, and TEST_TBLSPACE_TMP entries must be different,
> however.

Wow. Thanks Ian!. With these settings, plus your [1]patch for #11101
(and plus [2]r14510)
things look definitely better in the Oracle front:

  --
  Ran 2804 tests in 1935.104s

  FAILED (failures=4, errors=6, skipped=42, expected failures=2)


Will run the test suite against 1.2.X and update the [3]wiki page tomorrow.

-- 
Ramiro Morales

1. http://code.djangoproject.com/ticket/11101
2. http://code.djangoproject.com/changeset/14510
3. http://code.djangoproject.com/wiki/OracleTestSetup

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django POST Broken

[Andrew W]

I just ran into this same issue, but it wasn't Django, the answer
lived in nginx.conf
try checking the
client_max_body_size M;

in your server{

On Nov 10, 9:42 am, john <185...@gmail.com> wrote:
> Hello,
>
> I'm working on a Django project. I'm running on cloudservers hosting,
> with nginx/uwsgi as the server. I'm trying to get an image upload form
> working with POST, but I'm running into some problems.
>
> Basically, it comes down to this: if I comment out this line:
>
> uwsgi_param  CONTENT_TYPE       $content_type;
>
> in the uwsgi_params file, POST suddenly works. However, this breaks
> the admin screen.
>
> Anyone have any idea what's going on? Whether or not this is even a
> Django issue?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Charfields and Admin and None, oh my.

[Karen Tracey]

On Wed, Nov 10, 2010 at 6:32 PM, Andrew Godwin  wrote:

> So, I've been trying to trace a bug that's been affecting me as well as
> someone else I know, to do with ModelForms / the admin and CharFields
> with null=True, blank=True, and unique=True
>
> The old ticket for this was closed as WONTFIX:
> http://code.djangoproject.com/ticket/9590
>
> However, I'd personally rather see the admin work with this (more common
> than you think) combination of options; otherwise, there's no way to
> make more than one model with one of these fields via the admin, and
> it's basically useless.
>
>
There is a way, it just requires some admin customization. See:

http://stackoverflow.com/questions/454436/unique-fields-that-allow-nulls-in-django/1400046#1400046



> I'd propose we either ship a new CharField subclass (NullCharField,
> perhaps), or add an option to the existing one, which when it gets
> something in EMPTY_VALUES returns None, not u"". Then, modify ModelForm
> (and thus the admin) to use this new subclass if the field has null=True
> set.
>
> It's a pretty simple fix, and I don't think it's an excessively ugly
> thing to add one more option/subclass, especially when the resulting
> error is quite user-unfriendly ("This value must be unique" error beside
> a non-required, blank textbox).
>
>
I don't think we can do anything now that would suddenly, when people
installed a new level of Django, start storing nulls in cases where
previously empty strings had been stored. Wouldn't we then likely be
creating a situation where a table column winds up with some "empty" values
equal to empty strings an others nulls? Having just one "empty" value is the
reason empty strings are forced for null values, according to the doc.
Personally I may wish null had been chosen as the empty value but I'm not
sure we can safely make that change at this point. (I am tired, though, so
maybe I am missing something in how this would not be a
backwards-incompatible change?)

Karen

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django POST Broken

[Jason Mayfield]

My company uses the nginx + uwsgi combination extensively (well, so far it's 
the stack serving Django on 6-ish servers) and haven't ever had this particular 
problem.  For reference, here's our (stock) uwsgi_params file:

uwsgi_param  QUERY_STRING   $query_string;
uwsgi_param  REQUEST_METHOD $request_method;
uwsgi_param  CONTENT_TYPE   $content_type;
uwsgi_param  CONTENT_LENGTH $content_length;

uwsgi_param  REQUEST_URI$request_uri;
uwsgi_param  PATH_INFO  $document_uri;
uwsgi_param  DOCUMENT_ROOT  $document_root;
uwsgi_param  SERVER_PROTOCOL$server_protocol;

uwsgi_param  REMOTE_ADDR$remote_addr;
uwsgi_param  REMOTE_PORT$remote_port;
uwsgi_param  SERVER_PORT$server_port;
uwsgi_param  SERVER_NAME$server_name;

- Jason

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Settings for a pure Oracle multi-db Django test suite setup

[Ian Kelly]

On Mon, Nov 8, 2010 at 10:02 PM, Ramiro Morales  wrote:

> Has anybody had success with this setup i.e. one where the 'default and
> 'other'
> alias pointing to such an Oracle product/install?. Is it possible at all?
>
> If so, could you please share the relevant Django settings file (not
> really, only
> the DATABASES setting)?
>

Yes, here are the settings I'm using:

DATABASES = {
'default': {
'ENGINE': 'django.db.backends.oracle',
'NAME': 'xe',
'USER': 'ikelly',
'PASSWORD': 'ikelly',
'OPTIONS': {'threaded': True},
'TEST_USER': 'django_test_default',
'TEST_TBLSPACE': 'django_test_default',
'TEST_TBLSPACE_TMP': 'django_test_default_temp',
},

'other': {
'ENGINE': 'django.db.backends.oracle',
'NAME': 'xe',
'USER': 'ikelly',
'PASSWORD': 'ikelly',
'OPTIONS': {'threaded': True},
'TEST_USER': 'django_test_other',
'TEST_TBLSPACE': 'django_test_other',
'TEST_TBLSPACE_TMP': 'django_test_other_temp',
},
}

The key is that NAME should be the same ('xe') for both entries, since
you're really establishing two connections to the same database.  The
TEST_USER, TEST_TBLSPACE, and TEST_TBLSPACE_TMP entries must be different,
however.

Cheers,
Ian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: multi-tenant-ized AuthenticationMiddleware?

[Russell Keith-Magee]

On Thu, Nov 11, 2010 at 12:49 AM, Jeff Enderwick
 wrote:
> Hi, is anyone working on making the auth middleware friendly for
> multi-tenent systems?
> For example, username not being unique, but tenant+username being
> unique instead?
> I just thought I would check before diving in...

I'm not aware of anyone doing any work in this area at the moment.

Increasing the flexibility of contrib.auth (in particular, making the
use of alternate User models easier) is something that is on our
radar, and there have been some prototype plans floated (search the
archives for details), but to the best of my knowledge there isn't an
active effort to get this into trunk for 1.3.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django POST Broken

[Russell Keith-Magee]

On Wed, Nov 10, 2010 at 11:42 PM, john <185...@gmail.com> wrote:
> Hello,
>
> I'm working on a Django project. I'm running on cloudservers hosting,
> with nginx/uwsgi as the server. I'm trying to get an image upload form
> working with POST, but I'm running into some problems.
>
> Basically, it comes down to this: if I comment out this line:
>
> uwsgi_param  CONTENT_TYPE       $content_type;
>
> in the uwsgi_params file, POST suddenly works. However, this breaks
> the admin screen.
>
> Anyone have any idea what's going on? Whether or not this is even a
> Django issue?

I would be deeply surprised if this were a Django issue -- "POST"
being broken would be a pretty fundamental failing for any web
framework. The only way I can see this being a Django issue is if
there is some subtle issue with our WSGI wrapper that only a
NginX/uwsgi combo exposes. However, even this seems unlikely -- we
have a fairly large installed base of users, using a wide range of web
servers. I don't personally know anyone using NginX/uwsgi, but I'd be
surprised if there weren't at least a couple of people using it.

So -- my money is on a configuration problem of some sort. I have no
suggestions on where to look, however; I don't know enough about uwsgi
to point you in the right direction.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Charfields and Admin and None, oh my.

[Andrew Godwin]

So, I've been trying to trace a bug that's been affecting me as well as
someone else I know, to do with ModelForms / the admin and CharFields
with null=True, blank=True, and unique=True

The old ticket for this was closed as WONTFIX:
http://code.djangoproject.com/ticket/9590

However, I'd personally rather see the admin work with this (more common
than you think) combination of options; otherwise, there's no way to
make more than one model with one of these fields via the admin, and
it's basically useless.

I'd propose we either ship a new CharField subclass (NullCharField,
perhaps), or add an option to the existing one, which when it gets
something in EMPTY_VALUES returns None, not u"". Then, modify ModelForm
(and thus the admin) to use this new subclass if the field has null=True
set.

It's a pretty simple fix, and I don't think it's an excessively ugly
thing to add one more option/subclass, especially when the resulting
error is quite user-unfriendly ("This value must be unique" error beside
a non-required, blank textbox).

Thoughts?

Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Ticket #7817: Extending "with" and "include" tags.

[Gabriel Hurley]

I apologize for the unintentional insult. In retrospect "silly" was a
poor choice of words, and certainly not directed at you specifically,
Jannis. Your opinion is plenty valid, even if we disagree.

The real crux of my argument is this: Django's philosophy of keeping
programming concerns out of templates is a great principle; however,
it creeps into a tacit implication that template authors (in other
words, designers) need to be treated with kid gloves. As someone who
actually came up *as a designer* before I ever learned to code, and
who has been very involved in design communities in the past, I find
the implied necessity of readability specifically for "the target
audience" (designers) mildly pejorative. I'm sure it's not always
meant that way, but that's how it feels when I read these types of
rationales. I'm +1 on readability for readability's sake. -1 on
readability for the sake of "the target audience".

Getting back to the real subject at hand, I like the general human
readability of your syntax (and the current syntax in general), I just
like the "=" a little more. I'm +1 on "=", and +0 on "... as ...".
Either one gets the job done and I'd gladly accept either as they both
solve the same problems.

Thanks!

- Gabriel


On Nov 10, 1:36 am, Jannis Leidel  wrote:
> On 10.11.2010, at 09:20, Gabriel Hurley wrote:
>
>
>
>
>
>
>
>
>
> > In a fit of coincidental timing, I was just being frustrated by this
> > very issue with inclusion tags today. I'm +1 on supporting kwargs with
> > "=". It is in fact *more* familiar to someone who works with HTML to
> > be able to assign attributes in arbitrary order, for example:
>
> > http://example.com; class="green" id="my_id">
>
> > works the same as:
>
> > http://example.com;>
>
> > whereas this is just nonsense:
>
> > http://example.com; "my_id" "green">
>
> > and this is even more broken:
>
> > 
>
> While I appreciate that you think that's a fact, comparing HTML semantics 
> with those of the template language doesn't proof anything, at the most shows 
> that they both have the concept of parameters. If that's all you are implying 
> we should probably move to using arrow brackets?
>
> > So any argument about not using kwargs being "for template authors"
> > seems a bit silly to me. Designers may not be programmers (though many
> > of them are these days), but the reality of the tools they already use
> > is that this is a familiar syntax.
>
> Please stop trying to make a point by calling my argument silly. I've voiced 
> my strong concerns about the proposed change but agreed with a different 
> proposal.
>
> Jannis
>
>
>
>
>
>
>
> > On Nov 8, 7:16 pm, Peter Baumgartner  wrote:
> >> On Thu, Nov 4, 2010 at 5:37 AM, silent1mezzo  
> >> wrote:
> >>> +1 for {% include "foo.html" x=1 y=2 %}
>
> >>> This just seems more natural.  My designer agreed based on the {% url
> >>> %} tags.
>
> >> +1 for using the = syntax here. My reasons have been mentioned above,
> >> but to recap:
>
> >> * and/as gets too verbose and difficult to read if you add more than a
> >> couple variables
> >> * HTML uses "=" to set attributes, so this shouldn't be a new paradigm
> >> for template authors
>
> >> -- Pete

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Receipt for mail to security@ ?

[Stephen Kelly]

Jacob Kaplan-Moss wrote:

> On Wed, Nov 10, 2010 at 1:39 PM, Stephen Kelly
>  wrote:
>> Can someone confirm that the email I sent yesterday made it through? Last
>> time I emailed that list it was marked as spam apparently.
> 
> Yes, we've got it. We'll get back to you shortly - sorry for the delay.

No rush, sorry. Just wanted to make sure it wasn't in the spam again.

Steve


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Receipt for mail to security@ ?

[Jacob Kaplan-Moss]

On Wed, Nov 10, 2010 at 1:39 PM, Stephen Kelly  wrote:
> Can someone confirm that the email I sent yesterday made it through? Last
> time I emailed that list it was marked as spam apparently.

Yes, we've got it. We'll get back to you shortly - sorry for the delay.

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-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

multi-tenant-ized AuthenticationMiddleware?

[Jeff Enderwick]

Hi, is anyone working on making the auth middleware friendly for
multi-tenent systems?
For example, username not being unique, but tenant+username being
unique instead?
I just thought I would check before diving in...

thanks,
Jeff

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Django POST Broken

[john]

Hello,

I'm working on a Django project. I'm running on cloudservers hosting,
with nginx/uwsgi as the server. I'm trying to get an image upload form
working with POST, but I'm running into some problems.

Basically, it comes down to this: if I comment out this line:

uwsgi_param  CONTENT_TYPE   $content_type;

in the uwsgi_params file, POST suddenly works. However, this breaks
the admin screen.

Anyone have any idea what's going on? Whether or not this is even a
Django issue?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Ticket #7817: Extending "with" and "include" tags.

[Jannis Leidel]

On 10.11.2010, at 11:09, Luke Plant wrote:

> On Sun, 2010-10-31 at 16:59 -0700, SmileyChris wrote:
>> On Oct 29, 2:22 pm, Russell Keith-Magee 
>> wrote:
>>> If we can introduce the terse syntax while maintaining the old syntax
>>> (including the analogous change in  blocktrans), I think it would be a
>>> worthwhile change. However, I certainly won't complain if public
>>> opinion sways the other way.
>> 
>> I've done this here:
>> http://github.com/SmileyChris/django/compare/master...7817-include-with
> 
> Nice work. I also find the '=' format more readable, and definitely
> appropriate for the reasons given by others. With the others fixed to be
> consistent Russell's concerns are addressed. It seems only Jannis is
> opposed to this syntax so far, and several core developers as well as
> everyone else on the thread prefer it. Are we close enough to "rough
> consensus" yet?

Not really, I'm -1 on this and gave a different proposal that doesn't get rid 
of an existing paradigm and would solve the issues for me (+0).

BTW, while looking trough Chris' patch again I noticed another wart of his 
proposed change regarding filters when used in the parameter assignment.

  {% blocktrans with berta=anton|lower %}{{ berta }}{% endblocktrans %}

The version that works today:

  {% blocktrans with anton|lower as berta %}{{ berta }}{% endblocktrans %}

The include proposed by Chris:

  {% include "basic-syntax03" with first=second|lower|upper second=first|upper 
%}

and the more verbose version that corresponds to how the template language 
works today: 

  {% include "basic-syntax03" with first|lower|upper as new_first and 
second|upper as new_second %}


Jannis


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: custom function for autoescape

[Will Hardy]

> Reading over the discussion, I'm in the same camp as Luke. I can see
> the use case, but I see a bunch of sharp edges that will end up biting
> the user in unexpected ways.

Thanks for dropping by :-) I think I've managed to remove the sharp edges.

The main problem in this thread is that the default filters were
written in the html context and their interaction with autoescaping
breaks down when a different escaping context is required.

I believe the solution would be to simply declare the html filters as
"unsafe" and I've uploaded a patch [1] to the ticket that would do
that. I've included a detailed description of the approach on the
ticket [2]. All filters appear to be correctly handled in the new
approach described there.

If you think this approach is sensible, I'll edit the group 2 filters
to use the custom escape function (they mostly take the autoescape
argument anyway). There are a small number of tests on the ticket, but
if this is something that might be in core, then I'll write some more
comprehensive tests and documentation.

Cheers,

Will

[1] 

[2] 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Ticket #7817: Extending "with" and "include" tags.

[Jannis Leidel]

On 10.11.2010, at 09:20, Gabriel Hurley wrote:

> In a fit of coincidental timing, I was just being frustrated by this
> very issue with inclusion tags today. I'm +1 on supporting kwargs with
> "=". It is in fact *more* familiar to someone who works with HTML to
> be able to assign attributes in arbitrary order, for example:
> 
> http://example.com; class="green" id="my_id">
> 
> works the same as:
> 
> http://example.com;>
> 
> whereas this is just nonsense:
> 
> http://example.com; "my_id" "green">
> 
> and this is even more broken:
> 
> http://example.com as src and my_id as id and green as class>

While I appreciate that you think that's a fact, comparing HTML semantics with 
those of the template language doesn't proof anything, at the most shows that 
they both have the concept of parameters. If that's all you are implying we 
should probably move to using arrow brackets?

> So any argument about not using kwargs being "for template authors"
> seems a bit silly to me. Designers may not be programmers (though many
> of them are these days), but the reality of the tools they already use
> is that this is a familiar syntax.

Please stop trying to make a point by calling my argument silly. I've voiced my 
strong concerns about the proposed change but agreed with a different proposal.

Jannis

> On Nov 8, 7:16 pm, Peter Baumgartner  wrote:
>> On Thu, Nov 4, 2010 at 5:37 AM, silent1mezzo  wrote:
>>> +1 for {% include "foo.html" x=1 y=2 %}
>> 
>>> This just seems more natural.  My designer agreed based on the {% url
>>> %} tags.
>> 
>> +1 for using the = syntax here. My reasons have been mentioned above,
>> but to recap:
>> 
>> * and/as gets too verbose and difficult to read if you add more than a
>> couple variables
>> * HTML uses "=" to set attributes, so this shouldn't be a new paradigm
>> for template authors
>> 
>> -- Pete



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Ticket #7817: Extending "with" and "include" tags.

[Luke Plant]

On Sun, 2010-10-31 at 16:59 -0700, SmileyChris wrote:
> On Oct 29, 2:22 pm, Russell Keith-Magee 
> wrote:
> > If we can introduce the terse syntax while maintaining the old syntax
> > (including the analogous change in  blocktrans), I think it would be a
> > worthwhile change. However, I certainly won't complain if public
> > opinion sways the other way.
> 
> I've done this here:
> http://github.com/SmileyChris/django/compare/master...7817-include-with

Nice work. I also find the '=' format more readable, and definitely
appropriate for the reasons given by others. With the others fixed to be
consistent Russell's concerns are addressed. It seems only Jannis is
opposed to this syntax so far, and several core developers as well as
everyone else on the thread prefer it. Are we close enough to "rough
consensus" yet?

Luke

-- 
I never hated a man enough to give him his diamonds back. (Zsa Zsa 
Gabor)

Luke Plant || http://lukeplant.me.uk/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Call for review and comment: #7539 (ForeignKey on_delete)

[Harro]

_/-o_ \o/

On Nov 9, 5:59 pm, Carl Meyer  wrote:
> This is committed as r14507:http://code.djangoproject.com/changeset/14507
>
> Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Ticket #7817: Extending "with" and "include" tags.

[Gabriel Hurley]

In a fit of coincidental timing, I was just being frustrated by this
very issue with inclusion tags today. I'm +1 on supporting kwargs with
"=". It is in fact *more* familiar to someone who works with HTML to
be able to assign attributes in arbitrary order, for example:

http://example.com; class="green" id="my_id">

works the same as:

http://example.com;>

whereas this is just nonsense:

http://example.com; "my_id" "green">

and this is even more broken:

http://example.com as src and my_id as id and green as class>

So any argument about not using kwargs being "for template authors"
seems a bit silly to me. Designers may not be programmers (though many
of them are these days), but the reality of the tools they already use
is that this is a familiar syntax.

All the best,

- Gabriel

On Nov 8, 7:16 pm, Peter Baumgartner  wrote:
> On Thu, Nov 4, 2010 at 5:37 AM, silent1mezzo  wrote:
> > +1 for {% include "foo.html" x=1 y=2 %}
>
> > This just seems more natural.  My designer agreed based on the {% url
> > %} tags.
>
> +1 for using the = syntax here. My reasons have been mentioned above,
> but to recap:
>
> * and/as gets too verbose and difficult to read if you add more than a
> couple variables
> * HTML uses "=" to set attributes, so this shouldn't be a new paradigm
> for template authors
>
> -- Pete

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.