Re: please help! need to know python version
Carl Karsten wrote: > Python code is not developed in Python. You should talk to the PyPy guys/gals someday. ;-) > that can be debated, but for the purposed of this thread, I think it > fits. Oh, you already took the above comment into account. :-) -- Nicola Larosa - http://www.tekNico.net/ I accuse you, Mr. Bush, [...] of fomenting fear among your own people, of creating the very terror you claim to have fought. -- Keith Olbermann, July 2007 --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: please help! need to know python version
> James Bennett wrote: >> Django is compatible with any version of Python greater than 2.3 Don Arbow wrote: > You mean >=, right? :-) Well, 2.3.6 is strictly greater than 2.3 . ;-) http://www.python.org/download/releases/2.3.6/ -- Nicola Larosa - http://www.tekNico.net/ I accuse you, Mr. Bush, [...] of fomenting fear among your own people, of creating the very terror you claim to have fought. -- Keith Olbermann, July 2007 --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: runtests failures
>>
>> Got an error creating the test database: (1007, "Can't create database
>> 'django_t
>> est_db'; database exists")
>>
>> It seems stuck there? perhaps I should mysql> drop database django_test_db;
>> but that should never be done, right? :)
>
> It will be asking you if you want to drop the database. If you are
> redirecting stdout/stderr, then you aren't seeing that question. Just
./runtests.py --settings settings_mysql 2>&1|tee --append runtests.log
I type 'yes\n' tests run.
[EMAIL PROTECTED]:~/django/django-src/tests$ cat runtests.log
[snip]
Ran 139 tests in 126.896s
FAILED (failures=3)
It appears the test database, django_test_db, already exists. Type 'yes' to
delete it, or 'no' to cancel:
oh... there it is.
any idea how to get bash to do what I want?
> All going smoothly there should be only only one failed test:
> modeltests.fixtures (two sub-tests in there fail because the default
> MySQL storage engine does not support transactions, but it's reported as
> "failures=1").
>
I see your 3 and raise you 2.
Carl K
svnversion 5625
# settings.mysql.py
DATABASE_ENGINE = 'mysql'
DATABASE_USER = 'djangouser'
DATABASE_PASSWORD = 'd842'
DATABASE_HOST = ''
DATABASE_PORT = ''
ROOT_URLCONF=None
SITE_ID=1
/usr/lib/python2.5/site-packages/django/db/models/base.py:247: Warning:
Incorrect string value: '\xE6\x9E\x97\xE5\x8E\x9F...' for column 'headline' at
row 1
','.join(placeholders)), db_values)
==
FAIL: Doctest: modeltests.basic.models.__test__.API_TESTS
--
Traceback (most recent call last):
File "/usr/lib/python2.5/site-packages/django/test/_doctest.py", line 2161,
in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for
modeltests.basic.models.__test__.API_TESTS
File "/home/carl/django/django-src/tests/modeltests/basic/models.py", line
unknown line number, in API_TESTS
--
File "/home/carl/django/django-src/tests/modeltests/basic/models.py", line ?,
in
modeltests.basic.models.__test__.API_TESTS
Failed example:
Article.objects.get(pk=a.id).headline
Expected:
u'\u6797\u539f \u3081\u3050\u307f'
Got:
u'?? ???'
==
FAIL: Doctest: modeltests.fixtures.models.__test__.API_TESTS
--
Traceback (most recent call last):
File "/usr/lib/python2.5/site-packages/django/test/_doctest.py", line 2161,
in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for
modeltests.fixtures.models.__test__.API_TESTS
File "/home/carl/django/django-src/tests/modeltests/fixtures/models.py",
line
unknown line number, in API_TESTS
--
File "/home/carl/django/django-src/tests/modeltests/fixtures/models.py", line
?,
in modeltests.fixtures.models.__test__.API_TESTS
Failed example:
Article.objects.all()
Expected:
[, , ]
Got:
[, , , ]
--
File "/home/carl/django/django-src/tests/modeltests/fixtures/models.py", line
?,
in modeltests.fixtures.models.__test__.API_TESTS
Failed example:
print management.dump_data(['fixtures'], format='json')
Expected:
[{"pk": "3", "model": "fixtures.article", "fields": {"headline": "Time to
reform copyright", "pub_date": "2006-06-16 13:00:00"}}, {"pk": "2", "model":
"fixtures.article", "fields": {"headline": "Poker has no place on ESPN",
"pub_date": "2006-06-16 12:00:00"}}, {"pk": "1", "model": "fixtures.article",
"fields": {"headline": "Python program becomes self aware", "pub_date":
"2006-06-16 11:00:00"}}]
Got:
[{"pk": "5", "model": "fixtures.article", "fields": {"headline": "XML
identified as leading cause of cancer", "pub_date": "2006-06-16 16:00:00"}},
{"pk": "3", "model": "fixtures.article", "fields": {"headline": "Time to reform
copyright", "pub_date": "2006-06-16 13:00:00"}}, {"pk": "2", "model":
"fixtures.article", "fields": {"headline": "Poker on TV is great!", "pub_date":
"2006-06-16 11:00:00"}}, {"pk": "1", "model": "fixtures.article", "fields":
{"headline": "Python program becomes self aware", "pub_date": "2006-06-16
11:00:00"}}]
==
FAIL: Doctest: regressiontests.string_lookup.models.__test__.API_TESTS
--
Traceback (most recent call last):
File "/usr/lib/python2.5/site-packages/django/test/_doctest.py", line 2161,
in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for
regressiontests.string_lookup.models.__
Re: runtests failures
On Fri, 2007-07-06 at 08:59 -0500, Carl Karsten wrote: [...] > > All going smoothly there should be only only one failed test: > > modeltests.fixtures (two sub-tests in there fail because the default > > MySQL storage engine does not support transactions, but it's reported as > > "failures=1"). > > > > I see your 3 and raise you 2. > > Carl K > > svnversion 5625 > > # settings.mysql.py > DATABASE_ENGINE = 'mysql' > DATABASE_USER = 'djangouser' > DATABASE_PASSWORD = 'd842' > DATABASE_HOST = '' > DATABASE_PORT = '' > > ROOT_URLCONF=None > SITE_ID=1 How about, just for fun, going back and reading my first response in this thread where I pointed out a setting you may be need (TEST_DATABASE_CHARSET)? In many configurations, the default database will be created with a latin1 encoding, which will cause problems, since the tests exercise lots of data outside the latin1 range. The setting is documented (in settings.txt and in testing.txt) and you can search in the django-users archive for a thread a month or so ago when we debugged why it was necessary. > /usr/lib/python2.5/site-packages/django/db/models/base.py:247: Warning: > Incorrect string value: '\xE6\x9E\x97\xE5\x8E\x9F...' for column 'headline' > at row 1 >','.join(placeholders)), db_values) This line indicates some sort of encoding problem. [...] > -- > File "/home/carl/django/django-src/tests/modeltests/basic/models.py", line ?, > in > modeltests.basic.models.__test__.API_TESTS > Failed example: > Article.objects.get(pk=a.id).headline > Expected: > u'\u6797\u539f \u3081\u3050\u307f' > Got: > u'?? ???' This should not be failing (by that, I mean that they pass for me). It suggests your database is not storing all characters. Those particular Unicode characters are Japanese (林原 めぐみ if you have the right font installed), so they require a reasonable database server encoding to be able to store them. > == > FAIL: Doctest: modeltests.fixtures.models.__test__.API_TESTS > -- > Traceback (most recent call last): >File "/usr/lib/python2.5/site-packages/django/test/_doctest.py", line > 2161, > in runTest > raise self.failureException(self.format_failure(new.getvalue())) > AssertionError: Failed doctest test for > modeltests.fixtures.models.__test__.API_TESTS >File "/home/carl/django/django-src/tests/modeltests/fixtures/models.py", > line > unknown line number, in API_TESTS > > -- [...] These are caused by lack of transaction support. They are the expected failures for MySQL with the default storage engine. Can't be helped. One day somebody enthusiastic might submit a patch to remove them from consideration for that setup, but it's harmless. [...] > -- > File > "/home/carl/django/django-src/tests/regressiontests/string_lookup/models.py", > line ?, in regressiontests.string_lookup.models.__test__.API_TESTS > Failed example: > Foo.objects.get(friend__contains=u'\xe7') > Exception raised: > Traceback (most recent call last): >File "/usr/lib/python2.5/site-packages/django/test/_doctest.py", line > 1248, in __run > compileflags, 1) in test.globs >File " regressiontests.string_lookup.models.__test__.API_TESTS[18]>", line 1, in > > Foo.objects.get(friend__contains=u'\xe7') >File "/usr/lib/python2.5/site-packages/django/db/models/manager.py", > line > 73, in get > return self.get_query_set().get(*args, **kwargs) >File "/usr/lib/python2.5/site-packages/django/db/models/query.py", > line > 262, in get > raise self.model.DoesNotExist, "%s matching query does not exist." % > self.model._meta.object_name > DoesNotExist: Foo matching query does not exist. > -- > File > "/home/carl/django/django-src/tests/regressiontests/string_lookup/models.py", > line ?, in regressiontests.string_lookup.models.__test__.API_TESTS > Failed example: > Foo.objects.get(friend__contains='\xc3\xa7') > Exception raised: > Traceback (most recent call last): >File "/usr/lib/python2.5/site-packages/django/test/_doctest.py", line > 1248, in __run > compileflags, 1) in test.globs >File " regressiontests.string_lookup.models.__test__.API_TESTS[19]>", line 1, in > > Foo.objects.get(friend__contains='\xc3\xa7') >File "/usr/lib/python2.5/site-packages/django/db/models/manager.py", > line > 73, in get > return self.get_query_set().get(*args, **kwargs) >File "/usr/lib/python2.5/site-packages/django/db/models/query.py", > line > 262, in get > raise self.model.DoesNotExist, "%s match
Small concern in newforms-admin
I've been merging the Unicode changes into newforms-admin tonight (won't
be finished until tomorrow; I'm losing willpower) and I came across this
code (in admin/sites.py):
if u'@' in username:
# Mistakenly entered e-mail address instead of username? Look it up.
try:
user = User.objects.get(email=username)
except User.DoesNotExist:
message = _("Usernames cannot contain the '@' character.")
else:
message = _("Your e-mail address is not your username. Try '%s'
instead.") % user.username
I'm a little bit concerned by this. It means that if the admin login
page is exposed (for remote login), I (being a hypothetical person of
negotiable morals and principles) can mine for usernames by guessing
email addresses. It's easier to get ahold of somebody's email address
(or guess it using the corporate scheme) than their username, so now I'm
reduced to only having to guess the password.
Not a huge security hole, but not having the option would be less leaky.
It's usually recommended not to report when the username but not the
password is correct in a login attempt. This has the same slight
weakness.
If somebody wanted to add a "I've forgotten my username and/or password"
link, that easy enough to customise anyway, so we're not being complete
bastards by removing this.
Regards,
Malcolm
--
Plan to be spontaneous - tomorrow.
http://www.pointy-stick.com/blog/
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Skipping tests that are bound to fail?
Hi, I think it's a bit confusing that even with correct settings some tests always fail for some backends. If I happen to compile any other software package and the test suite fails, I usually suspect something went wrong. In addition, failing tests make it hard to verify that everything is alright with the package if you do any automated tests, e.g. before deploying a new version. So--what do you think about skipping tests that *must* fail? Michael -- noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg - Tel +49-911-9352-0 - Fax +49-911-9352-100 http://www.noris.de - The IT-Outsourcing Company Vorstand: Ingo Kraupa (Vorsitzender), Joachim Astel, Hansjochen Klenk - Vorsitzender des Aufsichtsrats: Stefan Schnabel - AG Nürnberg HRB 17689 --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Small concern in newforms-admin
On 7/6/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > I've been merging the Unicode changes into newforms-admin tonight (won't > be finished until tomorrow; I'm losing willpower) and I came across this > code (in admin/sites.py): > [...] > I'm a little bit concerned by this. It means that if the admin login > page is exposed (for remote login), I (being a hypothetical person of > negotiable morals and principles) can mine for usernames by guessing > email addresses. It's easier to get ahold of somebody's email address > (or guess it using the corporate scheme) than their username, so now I'm > reduced to only having to guess the password. For the record, that's in trunk, too -- it's in staff_member_required() in django/contrib/admin/views/decorators.py. I'm fine with removing that special-casing. We originally added it as a usability feature before Django was open-sourced, because we found our admin users were attempting to log in with their e-mail addresses, but I can see how it might be misused. Because the Unicode merge is going on, it's probably cleanest if we wait for that newforms-admin/unicode merge, then apply the change to both trunk and newforms-admin. Thanks for bringing this up, Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Per request internal variables
On Jul 6, 6:05 pm, PoBK <[EMAIL PROTECTED]> wrote: Ah crap... Wrong list. Sorry folks. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Small concern in newforms-admin
On 7/6/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > I'm fine with removing that special-casing. We originally added it as > a usability feature before Django was open-sourced, because we found > our admin users were attempting to log in with their e-mail addresses, > but I can see how it might be misused. Were it totally up to me, I'd leave it in to cut down on the number of "help me!" calls I get (:P), but I see the security issue, so let's kill it. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Skipping tests that are bound to fail?
On 7/6/07, Michael Radziej <[EMAIL PROTECTED]> wrote: > So--what do you think about skipping tests that *must* fail? AFAIK, there aren't any tests that are "supposed" to be failing; just a few backend-dependent bugs that need to be tracked down. As a general principle, though, skipping tests that must fail is a good idea; I'm not sure, though, if our test suite supports that. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Per request internal variables
I've got a case for passing an object between various components within my framework. The basic concept is similar to the way Mod_Python does things, where I can add an attribute to the request instance and that attribute will persist accross the current request only irrespective of which handler is currently operating on the request. I could hack this into the GET or POST attributes of request, but that would expose internal objects beyond the scope of application. Does anyone know of any method of passing variables around per request in a loosely coupled Djangonic way? -- Richard --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Skipping tests that are bound to fail?
On Fri, Jul 06, Jacob Kaplan-Moss wrote: > > On 7/6/07, Michael Radziej <[EMAIL PROTECTED]> wrote: > > So--what do you think about skipping tests that *must* fail? > > AFAIK, there aren't any tests that are "supposed" to be failing; just > a few backend-dependent bugs that need to be tracked down. The serializer tests don't work for mysql/mysql_old with a transaction enabled mysql storage engine since mysql doesn't test foreign key constraints at commit time but at row insertion time. There's nothing that could fix this ... > As a general principle, though, skipping tests that must fail is a > good idea; I'm not sure, though, if our test suite supports that. I have patches that simply skip tests via 'if'. I guess you'd prefer something such that you get a report line "xxx tests skipped since they don't work for %(reason)s"? Michael -- noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg - Tel +49-911-9352-0 - Fax +49-911-9352-100 http://www.noris.de - The IT-Outsourcing Company Vorstand: Ingo Kraupa (Vorsitzender), Joachim Astel, Hansjochen Klenk - Vorsitzender des Aufsichtsrats: Stefan Schnabel - AG Nürnberg HRB 17689 --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Skipping tests that are bound to fail?
On Fri, Jul 06, Jacob Kaplan-Moss wrote: > Yeah, that would be much better -- see the Python test suite, for > example; it gives a report at the end like "200 tests passed; 14 > skipped; 1 failure". http://code.djangoproject.com/ticket/4788 May I count your reply as "Approved"? Michael -- noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg - Tel +49-911-9352-0 - Fax +49-911-9352-100 http://www.noris.de - The IT-Outsourcing Company Vorstand: Ingo Kraupa (Vorsitzender), Joachim Astel, Hansjochen Klenk - Vorsitzender des Aufsichtsrats: Stefan Schnabel - AG Nürnberg HRB 17689 --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Skipping tests that are bound to fail?
On 7/6/07, Michael Radziej <[EMAIL PROTECTED]> wrote: > The serializer tests don't work for mysql/mysql_old with a transaction enabled > mysql storage engine since mysql doesn't test foreign key constraints at > commit > time but at row insertion time. There's nothing that could fix this ... Duh - I knew that. Sorry. > I have patches that simply skip tests via 'if'. I guess you'd prefer > something such that you get a report line "xxx tests skipped since they > don't work for %(reason)s"? Yeah, that would be much better -- see the Python test suite, for example; it gives a report at the end like "200 tests passed; 14 skipped; 1 failure". 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
empty list on "for" template tag
I'm new, so I don't know how to submit a patch.
This patch allow a tag "else" in a "for" loop. When the list is empty,
it is called (as well "else" on a "if").
{% for i in items %}
{{ i }}
{% else %}
no items
{% endfor %}
This is useful?
The patch:
Index: django/template/defaulttags.py
===
--- django/template/defaulttags.py (revisão 5625)
+++ django/template/defaulttags.py (cópia de trabalho)
@@ -69,10 +69,11 @@
return u''
class ForNode(Node):
-def __init__(self, loopvars, sequence, reversed, nodelist_loop):
+def __init__(self, loopvars, sequence, reversed, nodelist_loop,
nodelist_loop_empty):
self.loopvars, self.sequence = loopvars, sequence
self.reversed = reversed
self.nodelist_loop = nodelist_loop
+self.nodelist_loop_empty = nodelist_loop_empty
def __repr__(self):
if self.reversed:
@@ -109,36 +110,33 @@
if not hasattr(values, '__len__'):
values = list(values)
len_values = len(values)
-if self.reversed:
-values = reversed(values)
-unpack = len(self.loopvars) > 1
-for i, item in enumerate(values):
-context['forloop'] = {
-# shortcuts for current loop iteration number
-'counter0': i,
-'counter': i+1,
-# reverse counter iteration numbers
-'revcounter': len_values - i,
-'revcounter0': len_values - i - 1,
-# boolean values designating first and last times
through loop
-'first': (i == 0),
-'last': (i == len_values - 1),
-'parentloop': parentloop,
-}
-if unpack:
-# If there are multiple loop variables, unpack the
item into them.
-context.update(dict(zip(self.loopvars, item)))
-else:
-context[self.loopvars[0]] = item
-for node in self.nodelist_loop:
-nodelist.append(node.render(context))
-if unpack:
-# The loop variables were pushed on to the context so
pop them
-# off again. This is necessary because the tag lets
the length
-# of loopvars differ to the length of each set of
items and we
-# don't want to leave any vars from the previous loop
on the
-# context.
-context.pop()
+if len_values:
+if self.reversed:
+values = reversed(values)
+unpack = len(self.loopvars) > 1
+for i, item in enumerate(values):
+context['forloop'] = {
+# shortcuts for current loop iteration number
+'counter0': i,
+'counter': i+1,
+# reverse counter iteration numbers
+'revcounter': len_values - i,
+'revcounter0': len_values - i - 1,
+# boolean values designating first and last times
through loop
+'first': (i == 0),
+'last': (i == len_values - 1),
+'parentloop': parentloop,
+}
+if unpack:
+# If there are multiple loop variables, unpack
the item into them.
+context.update(dict(zip(self.loopvars, item)))
+else:
+context[self.loopvars[0]] = item
+for node in self.nodelist_loop:
+nodelist.append(node.render(context))
+else:
+for node in self.nodelist_loop_empty:
+ nodelist.append(node.render(context))
context.pop()
return nodelist.render(context)
@@ -583,9 +581,14 @@
raise TemplateSyntaxError, "'for' tag received an invalid
argument: %s" % token.contents
sequence = parser.compile_filter(bits[in_index+1])
-nodelist_loop = parser.parse(('endfor',))
+nodelist_loop = parser.parse(('else', 'endfor',))
+token = parser.next_token()
+if token.contents == 'else':
+nodelist_loop_false = parser.parse(('endfor',)) #ALTERADO
+else:
+nodelist_loop_false = NodeList()
parser.delete_first_token()
-return ForNode(loopvars, sequence, reversed, nodelist_loop)
+return ForNode(loopvars, sequence, reversed, nodelist_loop,
nodelist_loop_false)
do_for = register.tag("for", do_for)
def do_ifequal(parser, token, negate):
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~
empty list on "for" template tag
I'm new, so I don't know how to submit a patch.
This patch allow a tag "else" in a "for" loop. When the list is empty,
it is called (as well "else" on a "if").
{% for i in items %}
{{ i }}
{% else %}
no items
{% endfor %}
This is useful?
The patch:
Index: django/template/defaulttags.py
===
--- django/template/defaulttags.py (revisão 5625)
+++ django/template/defaulttags.py (cópia de trabalho)
@@ -69,10 +69,11 @@
return u''
class ForNode(Node):
-def __init__(self, loopvars, sequence, reversed, nodelist_loop):
+def __init__(self, loopvars, sequence, reversed, nodelist_loop,
nodelist_loop_empty):
self.loopvars, self.sequence = loopvars, sequence
self.reversed = reversed
self.nodelist_loop = nodelist_loop
+self.nodelist_loop_empty = nodelist_loop_empty
def __repr__(self):
if self.reversed:
@@ -109,36 +110,33 @@
if not hasattr(values, '__len__'):
values = list(values)
len_values = len(values)
-if self.reversed:
-values = reversed(values)
-unpack = len(self.loopvars) > 1
-for i, item in enumerate(values):
-context['forloop'] = {
-# shortcuts for current loop iteration number
-'counter0': i,
-'counter': i+1,
-# reverse counter iteration numbers
-'revcounter': len_values - i,
-'revcounter0': len_values - i - 1,
-# boolean values designating first and last times
through loop
-'first': (i == 0),
-'last': (i == len_values - 1),
-'parentloop': parentloop,
-}
-if unpack:
-# If there are multiple loop variables, unpack the
item into them.
-context.update(dict(zip(self.loopvars, item)))
-else:
-context[self.loopvars[0]] = item
-for node in self.nodelist_loop:
-nodelist.append(node.render(context))
-if unpack:
-# The loop variables were pushed on to the context so
pop them
-# off again. This is necessary because the tag lets
the length
-# of loopvars differ to the length of each set of
items and we
-# don't want to leave any vars from the previous loop
on the
-# context.
-context.pop()
+if len_values:
+if self.reversed:
+values = reversed(values)
+unpack = len(self.loopvars) > 1
+for i, item in enumerate(values):
+context['forloop'] = {
+# shortcuts for current loop iteration number
+'counter0': i,
+'counter': i+1,
+# reverse counter iteration numbers
+'revcounter': len_values - i,
+'revcounter0': len_values - i - 1,
+# boolean values designating first and last times
through loop
+'first': (i == 0),
+'last': (i == len_values - 1),
+'parentloop': parentloop,
+}
+if unpack:
+# If there are multiple loop variables, unpack
the item into them.
+context.update(dict(zip(self.loopvars, item)))
+else:
+context[self.loopvars[0]] = item
+for node in self.nodelist_loop:
+nodelist.append(node.render(context))
+else:
+for node in self.nodelist_loop_empty:
+ nodelist.append(node.render(context))
context.pop()
return nodelist.render(context)
@@ -583,9 +581,14 @@
raise TemplateSyntaxError, "'for' tag received an invalid
argument: %s" % token.contents
sequence = parser.compile_filter(bits[in_index+1])
-nodelist_loop = parser.parse(('endfor',))
+nodelist_loop = parser.parse(('else', 'endfor',))
+token = parser.next_token()
+if token.contents == 'else':
+nodelist_loop_false = parser.parse(('endfor',)) #ALTERADO
+else:
+nodelist_loop_false = NodeList()
parser.delete_first_token()
-return ForNode(loopvars, sequence, reversed, nodelist_loop)
+return ForNode(loopvars, sequence, reversed, nodelist_loop,
nodelist_loop_false)
do_for = register.tag("for", do_for)
def do_ifequal(parser, token, negate):
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~
Reverse URL lookups after the Unicode merge
Yesterday evening I upgraded my site to the latest Subversion trunk so
I could take a look at all the Unicode loveliness. It seemed to work
with one minor problem.
If I pass a method as the first argument to
django.core.urlresolvers.reverse, it always returns a NoReverseMatch
error. However, if I pass a string as the first parameter, the
reverse matching works fine. As an example:
>>> from django.core.urlresolvers import reverse
>>> reverse('project.apps.blog.views.entry_detail', None, ('2006', 'slug'))
'/blog/archives/2006/slug/'
>>> from project.apps.blog.views import entry_detail
>>> reverse(entry_detail, None, ('2006', 'slug'))
Traceback (most recent call last):
File "", line 1, in ?
File "[...]/django/core/urlresolvers.py", line 289, in reverse
return iri_to_uri(u'/' + get_resolver(urlconf).reverse(viewname,
*args, **kwargs))
File "[]...]/django/core/urlresolvers.py", line 273, in reverse
raise NoReverseMatch
NoReverseMatch
Is anyone else suffering from this problem?
M.
--
Matt Riggott (mailto:[EMAIL PROTECTED]).
Dictated but not read.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Skipping tests that are bound to fail?
On 7/6/07, Michael Radziej <[EMAIL PROTECTED]> wrote: > http://code.djangoproject.com/ticket/4788 > > May I count your reply as "Approved"? Indeed; and thanks. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: empty list on "for" template tag
On 7/6/07, Rodolfo <[EMAIL PROTECTED]> wrote: > I'm new, so I don't know how to submit a patch. Please read: http://www.djangoproject.com/documentation/contributing/#submitting-patches In particular, please submit patches to the ticket tracker. Submitting patches to the list is a great way to get us to ignore them entirely; once the message scrolls off onto page two of my email, it might as well be gone forever. Thanks! 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Reverse URL lookups after the Unicode merge
Yep. I just saw it...
On Fri, 2007-07-06 at 18:06 +0100, Matt Riggott wrote:
> Yesterday evening I upgraded my site to the latest Subversion trunk so
> I could take a look at all the Unicode loveliness. It seemed to work
> with one minor problem.
>
> If I pass a method as the first argument to
> django.core.urlresolvers.reverse, it always returns a NoReverseMatch
> error. However, if I pass a string as the first parameter, the
> reverse matching works fine. As an example:
>
> >>> from django.core.urlresolvers import reverse
> >>> reverse('project.apps.blog.views.entry_detail', None, ('2006', 'slug'))
> '/blog/archives/2006/slug/'
> >>> from project.apps.blog.views import entry_detail
> >>> reverse(entry_detail, None, ('2006', 'slug'))
> Traceback (most recent call last):
> File "", line 1, in ?
> File "[...]/django/core/urlresolvers.py", line 289, in reverse
> return iri_to_uri(u'/' + get_resolver(urlconf).reverse(viewname,
> *args, **kwargs))
> File "[]...]/django/core/urlresolvers.py", line 273, in reverse
> raise NoReverseMatch
> NoReverseMatch
>
> Is anyone else suffering from this problem?
>
> M.
>
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Small concern in newforms-admin
I personally don't understand why we can't use email addresses as usernames. I know there are work arounds but it seems odd to me that we would have to do extra steps to allow a user to log in with their email. Just my $.02 -Chris On Jul 6, 10:59 am, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote: > On 7/6/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > > I'm fine with removing that special-casing. We originally added it as > > a usability feature before Django was open-sourced, because we found > > our admin users were attempting to log in with their e-mail addresses, > > but I can see how it might be misused. > > Were it totally up to me, I'd leave it in to cut down on the number of > "help me!" calls I get (:P), but I see the security issue, so let's > kill it. > > 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Small concern in newforms-admin
On 7/6/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I personally don't understand why we can't use email addresses as > usernames. You can, you just need to roll your own form. -- "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-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Uncredited authors for Oracle backend work
Hi all, It was pointed out to me this morning that when we merged the Oracle branch back into the trunk, the authors that contributed this work didn't make their way into the AUTHORS file. Such magnificent work should not go uncredited. As far as I can work out, the following people deserve credit: Visible members of the Boulder Sprinters: Matt Boersma <[EMAIL PROTECTED]> Ian G. Kelly <[EMAIL PROTECTED]> Others in the ticket tracker that contributed bug reports and patches: Ben Khoo <[EMAIL PROTECTED]> Andreas Mock <[EMAIL PROTECTED]> I've added these names to the AUTHORS file. If there are other names that I have missed, let me know and I'll chisel their names into the file. 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-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Skipping tests that are bound to fail?
On Fri, 2007-07-06 at 17:24 +0200, Michael Radziej wrote: > Hi, > > I think it's a bit confusing that even with correct settings some tests > always fail for some backends. If I happen to compile any other software > package and the test suite fails, I usually suspect something went wrong. In > addition, failing tests make it hard to verify that everything is alright > with the package if you do any automated tests, e.g. before deploying a new > version. > > So--what do you think about skipping tests that *must* fail? We do that in quite a few places if you rummage through the test suite. Grep for settings.DATABASE, etc. The remaining places are just waiting for somebody to submit a clean patch, so go for it. It's not completely trivial for the MySQL transaction case, because you'll need to check the database options setting as well to ensure they aren't using InnoDB (which I think Andy mentioned at one point was respected by the tests, but I haven't checked that recently) Regards, Malcolm -- Depression is merely anger without enthusiasm. http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
