django_tickets
id | created | changetime | last_pulled_from_trac | stage | status | component | type | severity | version | resolution | summary | description | owner | reporter | keywords | easy | has_patch | needs_better_patch | needs_tests | needs_docs | ui_ux |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
8012 | 2008-07-29 00:30:27 | 2011-09-28 16:12:17 | 2022-03-06 03:41:10.071351 | Unreviewed | closed | Tools | 0.96 | invalid | MySQLdb build failure | Hello, I'm at my wit's end. I have been trying to add the required MySQL-python-1.2.2 to MySQL so i can use the database with django but the i cannot get the command: python setup.py build , to work. I posted my problem in the Django Users group but didn't get any response. Here is the error output i am getting. $ python setup.py build running build running build_py copying MySQLdb/release.py -> build/lib.macosx-10.3-i386-2.5/MySQLdb running build_ext building '_mysql' extension gcc -arch i386 -arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk -g -bundle -undefined dynamic_lookup build/temp.macosx-10.3-i386-2.5/_mysql.o -L/usr/local/mysql/lib -lmysqlclient_r -lz -lm -lmygcc -o build/lib.macosx-10.3-i386-2.5/_mysql.so /usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: for architecture ppc /usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: warning build/temp.macosx-10.3-i386-2.5/_mysql.o cputype (7, architecture i386) does not match cputype (18) for specified -arch flag: ppc (file not loaded) /usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: warning /usr/local/mysql//lib/libmysqlclient_r.dylib usrcputype (7,/libexec/ architecture gcc/i686i386) does-apple- not matchdarwin8/4.0.1 cputype (/ld: 18) forfor architecture specified -i386 /arch flag: usr/libexecppc (file/gcc/i686 not loaded-apple-) /usrdarwin8/4.0.1//libexec/gcc/ld: /powerpc-apple-usr/local/mysql/lib/libmysqlclient_r.dylib load command 8 unknown cmd field darwin8/4.0.1/ld: warningcollect2: /usr/ld returned 1 exit statuslocal/ mysql/lib/libmygcc.a archive's cputype (7, architecture i386) does not match cputype (18) for specified -arch flag: ppc (can't load from it) lipo: can't open input file: /var/folders/1D/1DIYDOE7GQ0pbcmmuCcESE+++TI/-Tmp-//ccCeFF5W.out (No such file or directory) error: command 'gcc' failed with exit status 1 I have read countless blogs posts and discussions but haven't found a solution. I am currently using a macbook pro with an intel duo core processor I have running MySQL version 5.0 although i have tried 5.1 and that didn't fix the problem. Please help! Jon | nobody | Jonathan Osborne <jono@fullemployment.org> | 0 | 0 | 0 | 0 | 0 | 0 | |||
8014 | 2008-07-29 02:57:28 | 2008-07-29 03:02:22 | 2022-03-06 03:41:10.343331 | Unreviewed | closed | Uncategorized | dev | invalid | Removal of mysql_old should be noted in Backward Incompatible Changes | Believe it or not, Dreamhost still has an old version of mysqldb. They recently claimed to be addressing that, but in the mean time, many people on Dreamhost who do an SVN update will be unpleasantly surprised. At the very least, please put this in the Backward Incompatible Changes page! | nobody | Beetle_B | mysql, mysql_old | 0 | 0 | 0 | 0 | 0 | 0 | ||
8015 | 2008-07-29 04:02:48 | 2008-07-29 04:26:14 | 2022-03-06 03:41:10.467261 | Unreviewed | closed | Forms | 1.0-alpha | duplicate | OneToOne Fields excluded from ModelForms | Since r8033 all !ModelForms (including those in the admin site) made from a model with a !OneToOne field exclude that field from the form. This means all models with !OneToOne fields raise !ImproperlyConfigured errors in the admin site, unless the !OneToOne field is explicitly excluded using the model's !ModelAdmin configuration. The relevant diff from that changeset: {{{ =================================================================== --- django/db/models/fields/related.py (revision 8032) +++ django/db/models/fields/related.py (revision 8033) @@ -706,6 +706,7 @@ """ def __init__(self, to, to_field=None, **kwargs): kwargs['unique'] = True + kwargs['editable'] = False if 'num_in_admin' not in kwargs: kwargs['num_in_admin'] = 0 super(OneToOneField, self).__init__(to, to_field, OneToOneRel, **kwargs) Index: tests/regressiontests/model_inheritance_regress/models.py =================================================================== }}} r8033 was related to making model inheritance work in the admin site. I'm currently at r8130, and commenting out the {{{"kwargs['editable'] = False"}}} line above makes everything work as expected (!OneToOne fields appear in !ModelForms and !ModelAdmin). I'm not using model inheritance, though, so can't say if removing this line would break that – I assume it would. | nobody | taojian | OneToOne, ModelForm, ModelAdmin | 0 | 0 | 0 | 0 | 0 | 0 | ||
8016 | 2008-07-29 08:47:42 | 2008-07-30 00:52:01 | 2022-03-06 03:41:10.604054 | Unreviewed | closed | contrib.admin | dev | duplicate | Problem with decoding of non ASCII symbols. | I'm using development version django with newforms admin. When I tried to set verbose name for model (verbose_name = 'Mājas lapas tekstu') using latvian symbols, I got an UnicodeDecodeError. Patch attached. {{{ Exception Type: UnicodeDecodeError Exception Value: 'ascii' codec can't decode byte 0xc4 in position 1: ordinal not in range(128) Exception Location: /django/contrib/admin/options.py in add_view, line 506 Python Executable: /usr/bin/python Python Version: 2.5.2 }}} | nobody | aabele | newforms admin | 0 | 1 | 0 | 0 | 0 | 0 | ||
8017 | 2008-07-29 10:28:10 | 2011-09-28 16:12:16 | 2022-03-06 03:41:10.713119 | Unreviewed | closed | Documentation | dev | invalid | Doc page 'model-api' should be updated according with NFA. | The page http://www.djangoproject.com/documentation/model-api/ looks like outdated now. For instance, whether it is correct to use 'validator_list' with NFA? | nobody | niksite | nfa, model-api | 0 | 0 | 0 | 0 | 0 | 0 | ||
8018 | 2008-07-29 10:54:29 | 2008-07-29 12:59:10 | 2022-03-06 03:41:10.830356 | Unreviewed | closed | Database layer (models, ORM) | dev | wontfix | m2m intermediary models (both generic and custom) | Ticket #6095 introduced the idea of custom intermediary models. Refractoring the m2m code to always use (generic) intermediary models would have benefits: * a simplier implementation of m2m * appropriate signals are always sent when a relation is created, modified or deleted (eg. #6778) * extending the generic relations (using 'through=') would be easier Of course, we must maintain compatibility to the m2m api, which consists (as far as I see it) of the ManyToManyField and the ManyRelatedManager. See the attachment for usage examples. | nobody | remo | m2m intermediary | 0 | 0 | 0 | 0 | 0 | 0 | ||
8019 | 2008-07-29 10:57:27 | 2011-09-28 16:12:17 | 2022-03-06 03:41:10.978521 | Unreviewed | closed | Translations | dev | fixed | Updated translation for Serbian language | based on [8133] | nobody | nesh | 0 | 0 | 0 | 0 | 0 | 0 | |||
8020 | 2008-07-29 12:10:05 | 2011-09-28 16:12:17 | 2022-03-06 03:41:11.102954 | Accepted | closed | Contrib apps | dev | fixed | python process crashes when using sitemaps after [8088] | When I go to http://example.com/sitemap.xml, python process crashes without any errors or core dumps. {{{ Django-version: trunk after [8088] DB-backends: PostgreSQL or SQLite3 URLs in sitemap: less than 50000 }}} | nobody | Boo | sitemap | 0 | 1 | 0 | 0 | 0 | 0 | ||
8021 | 2008-07-29 13:03:47 | 2008-07-29 22:42:09 | 2022-03-06 03:41:11.248483 | Unreviewed | closed | Core (Other) | dev | duplicate | save_FIELD_file closes tmpfile before moving it | There seems to be a bug in django/db/models/base.py that prevents files bigger than 2.5 megs to be uploaded. 1) create a model called "SimpleFile" with a FileField 2) register it with the admin site 3) log in the admin app, add a new "SimpleFile" with a file larger than 2.5 megs, SUBMIT At this point I get an IOError because the tmpfile created by the uploadhandler no longer exists. I believe the bug lies in file django/db/models/base.py line 530. If I comment it out everything works and the temp file is deleted correctly. | nobody | mpaolini | uploadhandler tmpfile | 0 | 0 | 0 | 0 | 0 | 0 | ||
8022 | 2008-07-29 13:54:51 | 2009-01-02 15:07:17 | 2022-03-06 03:41:11.376027 | Design decision needed | closed | Generic views | dev | fixed | Extend django.views.generic.simple.redirect_to to support permanent or temporary redirect codes | It's possible that this is completely inappropriate, but I've extended django.generic.simple.redirect_to with an extra, optional argument, 'permanent'. By default, redirect_to returns a 301 return code, but if permanent=True is specified, it'll return a 302 instead. Alternatively, a new generic view function, say temporary_redirect_to, could also do the same thing. {{{ Index: simple.py =================================================================== --- simple.py (revision 8135) +++ simple.py (working copy) @@ -1,5 +1,5 @@ from django.template import loader, RequestContext -from django.http import HttpResponse, HttpResponsePermanentRedirect, HttpResponseGone +from django.http import HttpResponse, HttpResponsePermanentRedirect, HttpResponseGone,HttpResponseRedirect def direct_to_template(request, template, extra_context=None, mimetype=None, **kwargs): """ @@ -17,7 +17,7 @@ t = loader.get_template(template) return HttpResponse(t.render(c), mimetype=mimetype) -def redirect_to(request, url, **kwargs): +def redirect_to(request, url, permanent=True, **kwargs): """ Redirect to a given URL. @@ -30,8 +30,13 @@ ) If the given url is ``None``, a HttpResponseGone (410) will be issued. + If permanent is True, the return code will be 301 - Moved Permanently, + otherwise, the return code will be 302 - Found. """ if url is not None: - return HttpResponsePermanentRedirect(url % kwargs) + if permanent: + return HttpResponsePermanentRedirect(url % kwargs) + else: + return HttpResponseRedirect(url % kwargs) else: return HttpResponseGone() }}} | nobody | David Sauve <dnsauve@gmail.com> | 0 | 1 | 0 | 0 | 0 | 0 | |||
8023 | 2008-07-29 14:00:22 | 2011-09-28 16:12:16 | 2022-03-06 03:41:11.522517 | Unreviewed | closed | Database layer (models, ORM) | dev | fixed | Changeset 8131 breaks filtering from the URL in the admin | The admin allows filtering objects by edting the url in the browser window.[[BR]] Eg: http://youraddress/admin/yourapp/yourmodel/?yourdecimalfield__lt=20 When filtering on a decimal field, changeset #7560 breaks this with the following stacktrace: {{{ File "C:\packages\Python-2.5\lib\site-packages\django\core\handlers\base.py" in get_response 87. response = callback(request, *callback_args, **callback_kwargs) File "C:\packages\Python-2.5\lib\site-packages\django\contrib\admin\views\decorators.py" in _checklogin 61. return view_func(request, *args, **kwargs) File "c:\develop\frepple\contrib\django\freppledb\utils\report.py" in view_report 302. counter = counter.filter( **{smart_str(key): value} ) File "C:\packages\Python-2.5\lib\site-packages\django\db\models\query.py" in filter 479. return self._filter_or_exclude(False, *args, **kwargs) File "C:\packages\Python-2.5\lib\site-packages\django\db\models\query.py" in _filter_or_exclude 497. clone.query.add_q(Q(*args, **kwargs)) File "C:\packages\Python-2.5\lib\site-packages\django\db\models\sql\query.py" in add_q 1176. can_reuse=used_aliases) File "C:\packages\Python-2.5\lib\site-packages\django\db\models\sql\query.py" in add_filter 1123. self.where.add((alias, col, field, lookup_type, value), connector) File "C:\packages\Python-2.5\lib\site-packages\django\db\models\sql\where.py" in add 48. params = field.get_db_prep_lookup(lookup_type, value) File "C:\packages\Python-2.5\lib\site-packages\django\db\models\fields\__init__.py" in get_db_prep_lookup 242. return [self.get_db_prep_value(value)] File "C:\packages\Python-2.5\lib\site-packages\django\db\models\fields\__init__.py" in get_db_prep_value 736. self.decimal_places) File "C:\packages\Python-2.5\lib\site-packages\django\db\backends\__init__.py" in value_to_db_decimal 302. return util.format_number(value, max_digits, decimal_places) File "C:\packages\Python-2.5\lib\site-packages\django\db\backends\util.py" in format_number 126. return u"%.*f" % (decimal_places, value) Exception Type: TypeError at /admin/input/buffer/ Exception Value: a float is required }}} The value argument is a Unicode string while the format string only accepts a float. You can also reproduce the same error from the command line: {{{ >>> works_as_expected = yourapp.yourmodel.objects.all().filter(yourdecimalfield__gt=0) >>> doesnt_work_any_more = yourapp.yourmodel.objects.all().filter(yourdecimalfield__gt=u'0') }}} Changing the format string from %f to %s fixes the problem in both backends I tested (SQLite + PostgreSQL): {{{ return u"%.*f" % (decimal_places, value) # OLD return u"%.*s" % (decimal_places, value) # NEW }}} | mtredinnick | jdetaeye | 0 | 0 | 0 | 0 | 0 | 0 | |||
8024 | 2008-07-29 15:06:47 | 2011-09-28 16:12:16 | 2022-03-06 03:41:11.661059 | Accepted | closed | Uncategorized | dev | fixed | Changeset 8132 breaks labels on ForeignKey Fields | The change in r8132 leads to empty labels in the admin change-forms if the ForeignKey Fields don't have an verbose_name parameter set. To reproduce just create two models: {{{ class ModelA(models.Model): title = models.CharField(max_length=20) class ModelB(models.Model): foo = models.ForeignKey(ModelA) }}} and register the models with the admin app {{{ class ModelAadmin(admin.ModelAdmin): pass class ModelBadmin(admin.ModelAdmin): pass admin.site.register(ModelA, ModelAadmin) admin.site.register(ModelB, ModelBadmin) }}} In the Admin Change-Form of ModelB an empty label is displayed on the ForeignKeyField to ModelA (only a ":" displayed, expected output would be "Model a:") The following patch fixes the problem, but I'm not sure if it breaks the problem which should be fixed by r8132 which was reported in #8011 {{{ --- db/models/fields/related.py (revision 8137) +++ db/models/fields/related.py (working copy) @@ -117,7 +117,7 @@ def set_attributes_from_rel(self): self.name = self.name or (self.rel.to._meta.object_name.lower() + '_' + self.rel.to._meta.pk.name) - if self.verbose_name is None: + if not self.verbose_name: self.verbose_name = self.rel.to._meta.verbose_name self.rel.field_name = self.rel.field_name or self.rel.to._meta.pk.name }}} | mtredinnick | arne | label, verbose_name, model | 0 | 0 | 0 | 0 | 0 | 0 | ||
8025 | 2008-07-29 15:22:31 | 2011-09-28 16:12:16 | 2022-03-06 03:41:11.799784 | Accepted | closed | Core (Other) | dev | invalid | Failed when lookups that span relationships with __isnull. | I have two records like this: {{{ id user name desc parent type 5, 5, 'My favorites', 'The default group of user's group.', , 1 6, 5, 'My traces', 'The default group of my traces.', 5, 2 }}} When I query it with (user's id = 5): {{{ TraceGroup.objects.filter(user=user, parent__parent__isnull=True) }}} I got: [<TraceGroup: My favorites>, <TraceGroup: My traces>] But the first record (My favorites) is not expected result for me. I think this is because <My favorites>'s parent is null, parent__parent__isnull will be matched if parent is null. I have to do this way to get correct result: {{{ TraceGroup.objects.filter(user=user, parent__isnull=False, parent__parent__isnull=True) }}} Is this a bug or it should be commented at documentation? Thanks. | nobody | bear330 | isnull, span | 0 | 0 | 0 | 0 | 0 | 0 | ||
8026 | 2008-07-29 15:29:18 | 2008-07-29 19:49:52 | 2022-03-06 03:41:11.936921 | Unreviewed | closed | Database layer (models, ORM) | dev | invalid | get_or_create fails on related queryset | The following will fail with a cryptic error message, {{{ class Counter(models.Model): name = CharField(max_length = 255) class Point(models.Model): counter = ForeignKey(Counter) counter = Counter.objects.get(name = 'some name') points = counter.points.all() points.get_or_create(**some_parameters) }}} For some reason, get_or_create ends up executing a SQL INSERT statement {{{ INSERT INTO 'point_table' ('counter_id') VALUES (None) }}} Well, that's not the exact output, which I unfortunately can't really copy and paste here, but the point is that get_or_create ends up inserting a Point with a '''None''' value for counter_id. The quick fix right now is, {{{ counter = Counter.objects.get(name = 'some name') points = counter.points.all() some_parameters.update({ 'defaults': { 'counter': counter } }) points.get_or_create(**some_parameters) }}} | nobody | Phoenixfire159@gmail.com | 0 | 0 | 0 | 0 | 0 | 0 | |||
8027 | 2008-07-29 15:39:06 | 2011-09-28 16:12:17 | 2022-03-06 03:41:12.073333 | Accepted | closed | Forms | dev | fixed | wrong fieldset validation? | {{{ class WYSIWYGForm(forms.ModelForm): class Media: js = ( ''.join((MEDIA_URL,"js/tiny_mce/tiny_mce.js")), ''.join((MEDIA_URL, "admin/js/textareas.js")), ) class AdminWYSIWYG(admin.ModelAdmin): form = WYSIWYGForm class SongAdmin(AdminWYSIWYG): fieldsets = ( (None, { 'fields': ('title', 'slug', 'group', 'author_l', 'co_author', 'author_v', 'lyrics') }), ('Перевод и аккорды', { 'classes': ('collapse',), 'fields': ('accords', 'translation') }), ) prepopulated_fields = {"slug": ("title",)} }}} This construction raises error in validation.py, line 182: {{{ for field in flatten_fieldsets(cls.fieldsets): _check_form_field_existsw("fieldsets[%d][1]['fields']" % idx, field) }}} But without validation it works correctly. May be, there is possible to off checking fields if form is subclass of ModelForm? Or validate it in other way? '''---->>>''' {{{ if not issubclass(cls.form, BaseModelForm): for field in flatten_fieldsets(cls.fieldsets): _check_form_field_existsw("fieldsets[%d][1]['fields']" % idx, field) }}} May be, I do something wrong? | jacob | Harut | newforms | 0 | 1 | 0 | 0 | 0 | 0 | ||
8028 | 2008-07-29 15:54:59 | 2011-09-28 16:12:17 | 2022-03-06 03:41:12.213390 | Ready for checkin | closed | Database layer (models, ORM) | dev | fixed | Small docstring fix for BaseDatabaseOperations.value_to_db_* | On #7560 I mistakenly copied two docstrings without tweaking them later. This patch solves this. | nobody | leosoto | 0 | 1 | 0 | 0 | 0 | 0 | |||
8029 | 2008-07-29 18:10:20 | 2008-07-30 09:29:53 | 2022-03-06 03:41:12.358944 | Unreviewed | closed | Testing framework | dev | fixed | admin_scripts regression tests override PYTHONPATH | When running the test suite against a custom external DB backend, the admin_scripts test fail with multiple errors like this: {{{ ====================================================================== FAIL: multiple: manage.py builtin commands succeed if settings are provided as argument ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\ramiro\django-ramiro\tests\regressiontests\admin_scripts\tests.py", line 669, in test_builtin_with_settings self.assertNoOutput(err) File "C:\ramiro\django-ramiro\tests\regressiontests\admin_scripts\tests.py", line 109, in assertNoOutput self.assertEquals(len(stream), 0, "Stream should be empty: actually contains '%s'" % stream) AssertionError: Stream should be empty: actually contains 'Traceback (most recent call last): File "./manage.py", line 11, in <module> execute_manager(settings) File "C:\ramiro\django-ramiro\django\core\management\__init__.py", line 301, in execute_manager utility.execute() File "C:\ramiro\django-ramiro\django\core\management\__init__.py", line 248, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "C:\ramiro\django-ramiro\django\core\management\base.py", line 77, in run_from_argv self.execute(*args, **options.__dict__) File "C:\ramiro\django-ramiro\django\core\management\base.py", line 90, in execute self.validate() File "C:\ramiro\django-ramiro\django\core\management\base.py", line 117, in validate num_errors = get_validation_errors(s, app) File "C:\ramiro\django-ramiro\django\core\management\validation.py", line 22, in get_validation_errors from django.db import models, connection File "C:\ramiro\django-ramiro\django\db\__init__.py", line 34, in <module> (settings.DATABASE_ENGINE, ", ".join(map(repr, available_backends))) django.core.exceptions.ImproperlyConfigured: 'sql_server.pyodbc' isn't an available database backend. Available options are: 'dummy', 'mysql', 'oracle', 'postgresql', 'postgresql_psycopg2', 'sqlite3' ---------------------------------------------------------------------- Ran 93 tests in 32.563s FAILED (failures=25) }}} Suspicion is that the tests override the {{{PYTHONPATH}}} envvar, and this break things ebcause the documented way of specifying an external backend is adding it's path to {{{PYTHONPATH}}} and setting the {{{DATABASE_ENGINE}}} var of the {{{settings}}} file being used for testing. It was confirmed by Alex Gaynor who suggested to try the patch attached that solved the problem. | nobody | ramiro | DATABASE_BACKEND admin_scripts | 0 | 1 | 0 | 0 | 0 | 0 | ||
8030 | 2008-07-29 18:54:32 | 2008-08-01 14:44:38 | 2022-03-06 03:41:12.498379 | Unreviewed | closed | Uncategorized | dev | fixed | BaseModelForm does not use super() | As seen in: http://code.djangoproject.com/browser/django/trunk/django/forms/models.py#L262 This somewhat restricts what can be done with multiple inheritance on form objects, which imo would be the most effective way of adding custom form display methods and such to forms. This can be worked around by simply ensuring that the mixin class comes before the form classes, however there isn't really any reason that this cannot be fixed. | nobody | glenjamin@gmail.com | 0 | 0 | 0 | 0 | 0 | 0 | |||
8031 | 2008-07-29 19:34:22 | 2008-08-05 14:25:42 | 2022-03-06 03:41:12.646121 | Design decision needed | closed | Template system | dev | fixed | Suppressing exceptions in templates harmful for debugging | Even when TEMPLATE_DEBUG is enabled, Django will currently silently suppress all exceptions during template rendering. This makes it hard to find typos in the template (misspelled variable names), but can also hide other errors. The concrete problem I hit was the conversion to permalink and the resolver not knowing functions specified directly as object and not string. As the exception was ignored, all users of the permalink used the empty string. It would be nice if the exceptions can be easily logged either to stderr (manage.py runserver) or some file, potentially using another debug option in settings.py. | lukeplant | joerg@bec.de | 0 | 0 | 0 | 0 | 0 | 0 | |||
8032 | 2008-07-29 21:46:54 | 2011-09-28 16:12:17 | 2022-03-06 03:41:12.772915 | Ready for checkin | closed | Documentation | dev | fixed | Wrong module name in settings documentation | There is a wrong module name in settings.txt for the FILE_UPLOAD_HANDLERS default value. It should be uploadhandler not fileuploadhandler. | mzgur | mzgur | 0 | 1 | 0 | 0 | 0 | 0 | |||
8033 | 2008-07-29 22:53:23 | 2014-06-23 07:38:45 | 2022-03-06 03:41:12.886828 | Ready for checkin | closed | Internationalization | Cleanup/optimization | Normal | dev | fixed | Better error handling for gettext and gettext_lazy issues | It's very common get confused in use of {{{gettext}}} and {{{gettext_lazy}}} functions. An usual error was to use {{{gettext}}} at import time, for example, in any of this cases: * In a parameter of {{{settings.py}}} file: {{{ from django.utils.translation import ugettext as _ ... LANGUAGE_CHOICES = (('es', _('Spanish')), ('en', _('English')),) }}} * In class or field definition of a {{{models.py}}} file: {{{ from django.db import models from django.utils.translation import ugettext as _ class Author(models.Model): name = models.CharField(_(u'Name'), max_length=100) }}} In both cases, if you get an error, the error will be an {{{ImportError}}} usually in another part of code... This is very difficult to debug, because the real error should be ''"Incorrect use of gettext. You can't use gettext at import time"''. The error is due to the fact of not all applications has been imported yet, and {{{gettext}}} resolution need to have all possible translation files loaded ({{{django.po}}} files), which implies loading of all applications. This causes a circular import error problem. In [http://groups.google.com/group/django-developers/browse_frm/thread/fdc392d546fd8da this thread] there is a discussion about this. We are thinking in check in every call to {{{gettext}}} if django apps has been loaded (using {{{django.db.models.loading.app_cache_ready()}}}) and take one of this options: * raise an representative error. * return a dummy string. I personally prefers first one, because {{{gettext}}} should be '''always''' called inside functions (at run time), and '''never''' at import time. I don't imagine a case of we need use {{{gettext}}} before that. | Claude Paroz <claude@2xlibre.net> | msaelices | 0 | 1 | 0 | 0 | 0 | 0 | |
8013 | 2008-07-29 02:38:10 | 2011-07-29 09:41:15 | 2022-03-06 03:41:10.208548 | Ready for checkin | closed | contrib.localflavor | New feature | Normal | dev | fixed | Localflavor for Colombia and Ecuador | This is intended to add a basic localflavor for Colombia and Ecuador. | nobody | ikks | Colombia Ecuador | 0 | 1 | 0 | 0 | 0 | 0 |
8034 | 2008-07-29 23:26:03 | 2011-09-16 22:24:27 | 2022-03-06 03:41:13.015949 | Design decision needed | closed | HTTP handling | New feature | Normal | dev | wontfix | Gzip Middleware And Images | In the random cases where Images (Gifs, JPEGS, PNG, etc) are passed through the Gzip middleware (usually through the static sender), sometimes they get 'truncated' (i think it may be a partial browser bug too) but there is no reason to Gzip image content-types and waste the time/ram/etc in doing them | nobody | magneto | gzip middleware | 0 | 0 | 0 | 0 | 0 | 0 |