Re: [Django] #14952: New find_commands(management_dir) to support .pyc and .pyo

[Django]

#14952: New find_commands(management_dir) to support .pyc and .pyo
-+--
  Reporter:  l...@live.com| Owner:  nobody   
Status:  closed  | Milestone:   
 Component:  Core framework  |   Version:  1.2  
Resolution:  wontfix |  Keywords:  find_commands
 Stage:  Unreviewed  | Has_patch:  0
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by Alex):

  * status:  new => closed
  * needs_better_patch:  => 0
  * resolution:  => wontfix
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 No, executing Python bytecode only files is gradually being removed from
 CPython, this is not a sane way to do deployments.  Wontfixing.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #14830: Default value for radio button not preserved when dynamically creating new inlines

[Django]

#14830: Default value for radio button not preserved when dynamically creating 
new
inlines
---+
  Reporter:  julien| Owner:  nobody   
Status:  new   | Milestone:  1.3  
 Component:  django.contrib.admin  |   Version:  1.2  
Resolution:|  Keywords:  sprintdec2010
 Stage:  Accepted  | Has_patch:  0
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Comment (by antoinemartin):

 The issue comes from the fact that when the row is inserted, the radio
 elements have the name as in the template. As only one radio element with
 the same name can be checked, the browser "unchecks" the radio in the
 template.

 To fix this, simply move the addition of the new form in the document DOM
 after having changed the names and ids in the template:

 {{{
  row.removeClass(options.emptyCssClass)
   .addClass(options.formCssClass)
   .attr("id", options.prefix + "-" + nextIndex)
   // Remove insertion from here
   //.insertBefore($(template));
 }}}

 ...


 {{{

 row.find("input,select,textarea,label,a").each(function() {
 updateElementIndex(this, options.prefix,
 totalForms.val());
 });
 // Insert the new form when it has been fully edited
 row.insertBefore($(template));
 // Update number of total forms
 $(totalForms).val(nextIndex + 1);
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

[Changeset] r15048 - django/trunk/django/contrib/localflavor/cz

[noreply]

Author: Honza_Kral
Date: 2010-12-24 12:19:48 -0600 (Fri, 24 Dec 2010)
New Revision: 15048

Modified:
   django/trunk/django/contrib/localflavor/cz/forms.py
Log:
Fixed #14593 -- Deprecating CZBirthNumberField's second argument to clean()

Gender is not necessary to determine whether a birth number is valid, it
just validates some further restrictions and shouldn't be part of the
field's validation.

Modified: django/trunk/django/contrib/localflavor/cz/forms.py
===
--- django/trunk/django/contrib/localflavor/cz/forms.py 2010-12-24 12:19:41 UTC 
(rev 15047)
+++ django/trunk/django/contrib/localflavor/cz/forms.py 2010-12-24 18:19:48 UTC 
(rev 15048)
@@ -62,14 +62,18 @@
 
 birth, id = match.groupdict()['birth'], match.groupdict()['id']
 
-# Three digits for verificatin number were used until 1. january 1954
+# Three digits for verification number were used until 1. january 1954
 if len(id) == 3:
 return u'%s' % value
 
 # Birth number is in format YYMMDD. Females have month value raised by 
50.
 # In case that all possible number are already used (for given date),
-#  the month field is raised by 20.
+# the month field is raised by 20.
 if gender is not None:
+import warnings
+warnings.warn(
+"Support for validating the gender of a CZ Birth number has 
been deprecated.",
+DeprecationWarning)
 if gender == 'f':
 female_const = 50
 elif gender == 'm':

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

Re: [Django] #14954: AttributeError: 'dict' object has no attribute 'status_code'

[Django]

#14954: AttributeError: 'dict' object has no attribute 'status_code'
---+
  Reporter:  boe...@gmail.com  | Owner:  nobody   
Status:  closed| Milestone:  1.3  
 Component:  Uncategorized |   Version:  1.3-alpha
Resolution:  invalid   |  Keywords:   
 Stage:  Unreviewed| Has_patch:  0
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Changes (by kmtracey):

  * status:  reopened => closed
  * resolution:  => invalid

Comment:

 Sorry, but the traceback still doesn't make much sense. It shows
 handle_uncaught_exception calling debug.technical_500_response
 transitioning back into !BaseHandler get_response, which doesn't make any
 sense and is not what the Django-included technical_500_response does. I
 am able to get current SVN Django to properly return debug pages, so there
 is something odd about your install: possibly something included among
 your installed apps that monkey-patches bits of Django? You don't say
 exactly what you are doing (not even what URL is getting processed, so I
 can't tell whether the uncaught exception is likely coming from some
 Django code like admin or your own app code) or what happens (beyond "all
 works fine") on 1.2.3...I'm not even sure if that means whatever URL you
 are trying to process here works completely fine on Django 1.2.3 or
 properly produces a debug page for an error in some code.

 Please provide more information about your configuration (installed apps,
 urls) and what URL you are attempting to get (or post?). Without more
 information it is extremely difficult to speculate about what is going
 wrong: as I said, I can get the code path indicated in this traceback
 (handling of an uncaught exception) to work properly using current SVN
 code, Django is not fundamentally broken here so we need more details on
 what's different about your configuration to tell what is going on.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #14954: AttributeError: 'dict' object has no attribute 'status_code'

[Django]

#14954: AttributeError: 'dict' object has no attribute 'status_code'
---+
  Reporter:  boe...@gmail.com  | Owner:  nobody   
Status:  reopened  | Milestone:  1.3  
 Component:  Uncategorized |   Version:  1.3-alpha
Resolution:|  Keywords:   
 Stage:  Unreviewed| Has_patch:  0
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Changes (by anonymous):

  * status:  closed => reopened
  * resolution:  invalid =>

Comment:

 Sorry for the confusing Traceback... I checked out the current trunk and
 removed all pyc files. Same situation, on 1.2.3 all works fine...

 {{{
 Traceback (most recent call last):
   File "[...]django/django-trunk/django/contrib/staticfiles/handlers.py",
 line 74, in __call__
 return self.application(environ, start_response)
   File "[...]django/django-trunk/django/core/handlers/wsgi.py", line 265,
 in __call__
 response = self.get_response(request)
   File "[...]django/django-trunk/django/core/handlers/base.py", line 182,
 in get_response
 response = self.handle_uncaught_exception(request, resolver,
 sys.exc_info())
   File "[...]django/django-trunk/django/core/handlers/base.py", line 203,
 in handle_uncaught_exception
 return debug.technical_500_response(request, *exc_info)
   File "[...]django/django-trunk/django/core/handlers/base.py", line 178,
 in get_response
 response = middleware_method(request, response)
   File "[...]django/django-trunk/django/contrib/flatpages/middleware.py",
 line 7, in process_response
 if response.status_code != 404:
 AttributeError: 'dict' object has no attribute 'status_code'
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #14954: AttributeError: 'dict' object has no attribute 'status_code'

[Django]

#14954: AttributeError: 'dict' object has no attribute 'status_code'
---+
  Reporter:  boe...@gmail.com  | Owner:  nobody   
Status:  closed| Milestone:  1.3  
 Component:  Uncategorized |   Version:  1.3-alpha
Resolution:  invalid   |  Keywords:   
 Stage:  Unreviewed| Has_patch:  0
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Changes (by kmtracey):

  * status:  new => closed
  * needs_better_patch:  => 0
  * resolution:  => invalid
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 There is some conflict between the version you mention (1.3 beta 1
 SVN-15045) and what seems to be indicated by the file names
 (django-1.2.3). Which is it, or have you really put 1.3 beta in a
 directory named django-1.2.3? There is also some evidence you are running
 a mutant/corrupted version in that traceback, though you also seem to have
 edited it to snip the front off pathnames so it's hard to be sure. But
 there's a comment shown as the line where the transition was made from
 base.py line 178 to the flatpage middleware line 7, and that sort of
 weirdness in the traceback makes me think you are running a corrupted
 version.

 I have verified that I can get a debug page to propery display, with
 flatpage fallback middleware in place, on current SVN level code. I
 suggest you entirely remove Django and then re-install whatever level it
 is you want to be running, because I think what has happened here is due
 to some corruption in your install.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #8158: Make possible to extend some of admin's templates

[Django]

#8158: Make possible to extend some of admin's templates
---+
  Reporter:  marinho   | Owner:  nobody
Status:  reopened  | Milestone:
 Component:  django.contrib.admin  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by marinho):

 BTW, Jacob, I guess that allow extending from another template with the
 same name, like a parent as Jinja does is incompatible with Django's model
 for templates.

 Because Django just finds a template by name in the sequence of template
 loaders and their internal sequences (usually TEMPLATE_DIRS and
 INSTALLED_APPS).

 There's no "parent", really. What's there is just a template that is found
 before another with the same name, so, how could we say to a template to
 extend its parent? Skipping its own to find the next in the sequency of
 paths?

 So, **I guess** this would be a worse trick than just rename those
 templates as base_* and extend them to the right name.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #8158: Make possible to extend some of admin's templates

[Django]

#8158: Make possible to extend some of admin's templates
---+
  Reporter:  marinho   | Owner:  nobody
Status:  reopened  | Milestone:
 Component:  django.contrib.admin  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by marinho):

  * summary:  Make possible to extend admin/index.html => Make possible to
  extend some of admin's templates

Comment:

 This change should be done for many of admin templates, like:

 * app_index.html
 * change_form.html
 * change_list.html
 * delete_confirmation.html
 * index.html
 * login.html
 * object_history.html

 All of those above could be renamed as "base_*" and a new one with
 original name would just "{% extends "base_..." %}" .

 The worst part on customizing Admin is to make a symlink of admin's
 templates directory with a fake name to can extend them to avoid a bad
 copy/paste of all a directory. It works, but it's a quick fix.

 I think: what's the problem with this idea, if many other things in Django
 does the same? (i.e.: every class and templates starting with "base... ")

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #7334: URLField validator does not allow non-ASCII-Domains

[Django]

#7334: URLField validator does not allow non-ASCII-Domains
-+--
  Reporter:  anonymous   | Owner:  nobody   
   
Status:  closed  | Milestone:   
   
 Component:  Validators  |   Version:  SVN  
   
Resolution:  fixed   |  Keywords:  punycode, url, 
validator
 Stage:  Design decision needed  | Has_patch:  0
   
Needs_docs:  0   |   Needs_tests:  0
   
Needs_better_patch:  0   |  
-+--
Changes (by claudep):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 I confirm this has been fixed by other tickets. Closing.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #14955: URLField validation should use HEAD requet instead of GET

[Django]

#14955: URLField validation should use HEAD requet instead of GET
-+--
  Reporter:  claudep | Owner:  nobody
Status:  new | Milestone:
 Component:  Core framework  |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by claudep):

  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 Note that tests are already done in forms/tests/fields.py (e.g.
 test_urlfield_3).

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

[Django] #14955: URLField validation should use HEAD requet instead of GET

[Django]

#14955: URLField validation should use HEAD requet instead of GET
+---
 Reporter:  claudep |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Core framework  | Version:  SVN   
 Keywords:  |   Stage:  Unreviewed
Has_patch:  1   |  
+---
 When an URLField has verify_exists to True, it checks that the page exists
 with urrlib2.urlopen. Doing a GET request (urllib2 default) is not
 necessary whereas a simple HEAD request should be sufficient to know if
 the page exists.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

[Changeset] r15047 - django/tags/releases

[noreply]

Author: ubernostrum
Date: 2010-12-24 06:19:41 -0600 (Fri, 24 Dec 2010)
New Revision: 15047

Added:
   django/tags/releases/1.1.3/
Log:
Tag 1.1.3

Copied: django/tags/releases/1.1.3 (from rev 15043, 
django/branches/releases/1.1.X)

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

[Changeset] r15046 - django/tags/releases

[noreply]

Author: ubernostrum
Date: 2010-12-24 06:19:01 -0600 (Fri, 24 Dec 2010)
New Revision: 15046

Added:
   django/tags/releases/1.2.4/
Log:
Tag 1.2.4

Copied: django/tags/releases/1.2.4 (from rev 15042, 
django/branches/releases/1.2.X)

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

[Django] #14954: AttributeError: 'dict' object has no attribute 'status_code'

[Django]

#14954: AttributeError: 'dict' object has no attribute 'status_code'
--+-
 Reporter:  boe...@gmail.com  |   Owner:  nobody
   Status:  new   |   Milestone:  1.3   
Component:  Uncategorized | Version:  1.3-alpha 
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 Django version 1.3 beta 1 SVN-15045:


 {{{
   File "[...]django/django-
 current/django/contrib/staticfiles/handlers.py", line 74, in __call__

   File "[...]django/django-1.2.3/django/core/handlers/wsgi.py", line 265,
 in __call__

   File "[...]django/django-1.2.3/django/core/handlers/base.py", line 182,
 in get_response
 def _get_traceback(self, exc_info=None):
   File "[...]django/django-1.2.3/django/core/handlers/base.py", line 203,
 in handle_uncaught_exception
 anything).
   File "[...]django/django-1.2.3/django/core/handlers/base.py", line 178,
 in get_response
 # Return an HttpResponse that displays a friendly error message.
   File "[...]django/django-1.2.3/django/contrib/flatpages/middleware.py",
 line 7, in process_response
 if response.status_code != 404:
 AttributeError: 'dict' object has no attribute 'status_code'
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #14953: New find_commands(management_dir) to support .pyc and .pyo

[Django]

#14953: New find_commands(management_dir) to support .pyc and .pyo
-+--
  Reporter:  anonymous   | Owner:  nobody   
Status:  closed  | Milestone:   
 Component:  Core framework  |   Version:  1.2  
Resolution:  duplicate   |  Keywords:  find_commands
 Stage:  Unreviewed  | Has_patch:  0
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by claudep):

  * status:  new => closed
  * needs_better_patch:  => 0
  * resolution:  => duplicate
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 Dup of #14952

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

[Django] #14953: New find_commands(management_dir) to support .pyc and .pyo

[Django]

#14953: New find_commands(management_dir) to support .pyc and .pyo
+---
 Reporter:  anonymous   |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Core framework  | Version:  1.2   
 Keywords:  find_commands   |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 In django/core/management/__init__.py:

 {{{
 def find_commands(management_dir):
 """
 Given a path to a management directory, returns a list of all the
 command
 names that are available.

 Returns an empty list if no commands are defined.
 """
 command_dir = os.path.join(management_dir, 'commands')
 try:
 return [f[:-3] for f in os.listdir(command_dir)
 if not f.startswith('_') and f.endswith('.py')]
 except OSError:
 return []
 }}}

 In our environment, We compile all .py to .pyc, and then remove all .py.
 Then manage.py can't find our commands because find_commands only find
 .py.

 Here is a modified version for find_command:

 {{{
 def find_commands(management_dir):
 """
 Given a path to a management directory, returns a list of all the
 command
 names that are available.

 Returns an empty list if no commands are defined.
 """
 command_dir = os.path.join(management_dir, 'commands')
 ret = {}
 try:
 filenames = os.listdir(command_dir)
 for filename in filenames:
 if filename.startswith('_'):
 continue

 if filename.endswith('.py'):
 modname = filename[:-3]
 elif filename.endswith('.pyc') or filename.endswith('.pyo'):
 modname = filename[:-4]
 else:
 modname = None

 if modname:
 ret[modname] = 1
 except OSError:
 pass

 return ret.keys()
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

[Django] #14952: New find_commands(management_dir) to support .pyc and .pyo

[Django]

#14952: New find_commands(management_dir) to support .pyc and .pyo
+---
 Reporter:  l...@live.com|   Owner:  nobody
   Status:  new |   Milestone:
Component:  Core framework  | Version:  1.2   
 Keywords:  find_commands   |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 In django/core/management/__init__.py:

 {{{
 def find_commands(management_dir):
 """
 Given a path to a management directory, returns a list of all the
 command
 names that are available.

 Returns an empty list if no commands are defined.
 """
 command_dir = os.path.join(management_dir, 'commands')
 try:
 return [f[:-3] for f in os.listdir(command_dir)
 if not f.startswith('_') and f.endswith('.py')]
 except OSError:
 return []
 }}}

 In our environment, We compile all .py to .pyc, and then remove all .py.
 Then manage.py can't find our commands because find_commands only find
 .py.

 Here is a modified version for find_command:

 {{{
 def find_commands(management_dir):
 """
 Given a path to a management directory, returns a list of all the
 command
 names that are available.

 Returns an empty list if no commands are defined.
 """
 command_dir = os.path.join(management_dir, 'commands')
 ret = {}
 try:
 filenames = os.listdir(command_dir)
 for filename in filenames:
 if filename.startswith('_'):
 continue

 if filename.endswith('.py'):
 modname = filename[:-3]
 elif filename.endswith('.pyc') or filename.endswith('.pyo'):
 modname = filename[:-4]
 else:
 modname = None

 if modname:
 ret[modname] = 1
 except OSError:
 pass

 return ret.keys()
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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