Test Errors, if `getpass.getuser` fails, i.e. tox on windows

There are 4 tests in `auth_test/test_management.py` which fail when run by tox on windows. - `test_system_username` - Raises an `ImportError` - `test_non_ascii_verbose_name` - mock input mapping assumes default username, and raise an error - `test_default_username` - Enters an infinite loop

Re: Django Channels redis backend more explicit errors

Hi! I think you've found the wrong mailing list for this post. This mailing list is for discussing the development of Django itself, not for support using Django. This means the discussions of bugs and features in Django itself, rather than in your code using it. People on this list are unlikely

Django Channels redis backend more explicit errors

Hi, I recently came across a situation my redis backend was improperly configured and I got this log. I thought the problem was related to a blocked port or something related to the container/image I was using because of the OSError: [Errno 22] Invalid argument, I think it would be more obvious

Re: Propagating X-Frame-Options header to debug view responses on errors

Thinking again: since it’s a debug view, Django could set the most permissive X-Frame-Options header on debug 500 responses. This would help every kind of framed view. If anyone agrees, we could make a ticket. On Fri, 28 Jan 2022 at 08:13, 'Ben Dickinson' via Django developers (Contributions to

Re: Propagating X-Frame-Options header to debug view responses on errors

Thanks Adam, that makes sense. The middleware is good idea, I hadn't thought of that. I think that's the way to go, at least that way we can keep it scoped to our URLs. Cheers! On Wednesday, 26 January 2022 at 19:04:33 UTC Adam Johnson wrote: > I was wondering if it would be possible to copy

Re: Propagating X-Frame-Options header to debug view responses on errors

> > I was wondering if it would be possible to copy the value of the > X-Frame-Options from the view that threw an error The problem here is that, because the view threw an error, there is no response object to copy the X-Frame-Options header from. So there's no way for the middleware to know

Propagating X-Frame-Options header to debug view responses on errors

Hi all, I'm one of the maintainers of django-pattern-library , which allows Django templates to be rendered with dummy context provided in static files. These rendered versions of the templates are show in an iframe, which means we have a

Re: Errors

; page: >>> https://docs.djangoproject.com/en/3.2/faq/help/ . This will help you >>> find people who are willing to support you, and to ask your question in a >>> way that makes it easy for them to answer. >>> >>> Thanks for your understanding and al

Re: Errors

>>> For support, please follow the "Getting Help" page: >>> https://docs.djangoproject.com/en/3.2/faq/help/ . This will help you find >>> people who are willing to support you, and to ask your question in a way >>> that makes it easy for t

Re: Errors

ay that makes it easy for them to answer. >> >> Thanks for your understanding and all the best, >> >> Adam >> >> On Tue, 10 Aug 2021 at 13:05, Rana Zain wrote: >> >>> I am facing this errors : >>> >>> > ',' or ')' expected >&g

Re: Errors

t; https://docs.djangoproject.com/en/3.2/faq/help/ . This will help you find > people who are willing to support you, and to ask your question in a way > that makes it easy for them to answer. > > Thanks for your understanding and all the best, > > Adam > > On Tue, 10 A

Re: Errors

y for them to answer. Thanks for your understanding and all the best, Adam On Tue, 10 Aug 2021 at 13:05, Rana Zain wrote: > I am facing this errors : > > > ',' or ')' expected > > Unexpected indent > > Statement expected, found Py:DEDENT > > for the last 2,3 days. K

Re: Errors

Can you send the screenshot On Tue, 10 Aug 2021, 6:19 PM Rana Zain, wrote: > I am facing this errors : > > > ',' or ')' expected > > Unexpected indent > > Statement expected, found Py:DEDENT > > for the last 2,3 days. Kindly help me out. > > -- >

Errors

I am facing this errors : > ',' or ')' expected > Unexpected indent > Statement expected, found Py:DEDENT for the last 2,3 days. Kindly help me out. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django

Re: getting errors from my Django app

Hi! I think you've found the wrong mailing list for this post. This mailing list is for discussing the development of Django itself, not for support using Django. This means the discussions of bugs and features in Django itself, rather than in your code using it. People on this list are unlikely

getting errors from my Django app

this is what I get when I run: python3 manage.py createsuperuser Traceback (most recent call last): File "manage.py", line 21, in main() File "manage.py", line 17, in main execute_from_command_line(sys.argv) File

Re: What is the contract of a cache backend regarding errors?

, Django's memcache backend makes no contract about errors, delegating that to the underlying library: https://github.com/django/django/blob/master/django/core/cache/backends/memcached.py . So I think all three points of your understanding are more to do with how python-memcached works rather than a contract

What is the contract of a cache backend regarding errors?

Hello, I am considering writing a cache backend for Django based on a recent Couchbase SDK (2.0+). While it is quite straightforward to write, I would like to know what is expected from a cache backend when errors happen. With my experience using the python-memcached backend, my understanding

Re: Migration Errors (fields.E300)

ngo application. > >I encounter the following errors when trying to migrate: >ERRORS: >accounts.Availability.channel: (fields.E300) Field defines a relation >with >model 'Channel', which is either not installed, or is abstract. >accounts.Correspondence.channel: (fields.E300)

Migration Errors (fields.E300)

I'm having an issue with migrating my Django application. I encounter the following errors when trying to migrate: ERRORS: accounts.Availability.channel: (fields.E300) Field defines a relation with model 'Channel', which is either not installed, or is abstract. accounts.Correspondence.channel

Re: Documenting reporting errors on individual fields in Model.clean (#16986)

errors. I realize that add_error() is a useful internal API, just not clear that it makes sense to have two public APIs for adding errors. "Easier to add errors from a view" doesn't carry weight for me: poking errors into a form from outside the form is smelly (violates the encapsulation of

Re: Documenting reporting errors on individual fields in Model.clean (#16986)

One possible way forward is to add "errors" argument to the clean() method. Then it would be possible to use the same API everywhere by doing errors.add_error('my_field', 'My Error message'). I don't know how strongly we feel about breakages caused by new arguments to methods. We broke

Re: Documenting reporting errors on individual fields in Model.clean (#16986)

Neither will go away, `ValidationError(dict)` is used internally to carry errors from the model layer to the form layer, and `add_error()` is used internally to interpret the `ValidationError` raised throughout the system; basically any `raise ValidationError` is followed by a call

Re: Documenting reporting errors on individual fields in Model.clean (#16986)

n you don't want to raise > an exception immediately. > > class MyForm(forms.Form): > def clean(): > if check1(): > self.add_error('field1', 'error message') > if check2(): > self.add_error('field2', 'error message') > > In my mod

Re: Documenting reporting errors on individual fields in Model.clean (#16986)

keep track of the errors as I go along. class MyModel(models.Model): def clean(): errors = {} if check1(): errors['field1'] = 'error message' if check2(): errors['field2'] = 'error message' if errors: raise ValidationError(errors) H

Re: Documenting reporting errors on individual fields in Model.clean (#16986)

16986 (Model.clean cannot report errors on individual fields) > > was fixed in Django 1.7, but the new feature is not documented. The > > Model.clean() docs still state: > > > >> Any ValidationError exceptions raised by Model.clean() will be stored > >> i

Re: Documenting reporting errors on individual fields in Model.clean (#16986)

Hi Alasdair, On 11/17/2014 09:05 AM, Alasdair Nicol wrote: > Ticket #16986 (Model.clean cannot report errors on individual fields) > was fixed in Django 1.7, but the new feature is not documented. The > Model.clean() docs still state: > >> Any ValidationError exceptions rai

Documenting reporting errors on individual fields in Model.clean (#16986)

Hi, Ticket #16986 (Model.clean cannot report errors on individual fields) was fixed in Django 1.7, but the new feature is not documented. The Model.clean() docs still state: > Any ValidationError exceptions raised by Model.clean() will be stored > in a special key error dictiona

Adding checks for common URLpattern configuration errors

Hi Django-Developers I would like to add additional system checks to the existing bunch. In particular, checks regarding common configuration errors around URLpatterns. An example check is described in the ticket here: https://code.djangoproject.com/ticket/23813 Please suggest any other common

Re: Cleaning up broken pipe errors in runserver

An opinion from Emil Stenström posted on the pull request (I'm inclined to agree with it unless there are objections or if someone can propose another solution): I agree that we should use the latest version of handle() from CPython to make sure we are as protected as we can be, even when

Re: Cleaning up broken pipe errors in runserver

Naive / over-obvious suggestion: if there's a genuine stalemate, bundling the changes into a third-party app that supplants core runserver (similar to how django-devserver does it) would avoid the need for individuals to monkey-patch while also making it possible to release versions with more

Re: Cleaning up broken pipe errors in runserver

I had a look at the patch. As I mentioned on the ticket, "I am not really happy with that patch which copies the simple_server.WSGIRequestHandler.handle() method from Python's version in order to override it. The copied version is not in sync with the latest Python and I'd prefer not to be in

Re: Cleaning up broken pipe errors in runserver

I'm +1 for this, for the same reasons; I have a monkey patch for my selenium tests which does the same thing as this PR. On Saturday, 2 August 2014 18:20:18 UTC-6, Matthew Somerville wrote: > > Hi, > > I have created a branch at > https://github.com/dracos/django/compare/pipe-cleaning that

Cleaning up broken pipe errors in runserver

Hi, I have created a branch at https://github.com/dracos/django/compare/pipe-cleaning that builds upon a previous patch posted to this list and outputs "Broken pipe" instead of a traceback for such an error. As the history below shows, practically speaking all reports of broken pipe

Re: DisallowedHost causes 500 errors.

, February 13, 2014 6:27:37 PM UTC+1, J. Clifford Dyer wrote: > > Django devs, > > I've noticed that the new ALLOWED_HOSTS causes the site > to return HTTP-500 errors whenever a user submits a request with an > HTTP_HOST header that is not allowed. This is flooding my deve

Re: DisallowedHost causes 500 errors.

ngo devs, >> >> I've noticed that the new ALLOWED_HOSTS causes the site >> to return HTTP-500 errors whenever a user submits a request with an >> HTTP_HOST header that is not allowed. This is flooding my developers' >> inboxes with spurious error messages. The

Re: DisallowedHost causes 500 errors.

, J. Cliff Dyer wrote: > > Django devs, > > I've noticed that the new ALLOWED_HOSTS causes the site > to return HTTP-500 errors whenever a user submits a request with an > HTTP_HOST header that is not allowed. This is flooding my developers' > inboxes with spurious erro

DisallowedHost causes 500 errors.

Django devs, I've noticed that the new ALLOWED_HOSTS causes the site to return HTTP-500 errors whenever a user submits a request with an HTTP_HOST header that is not allowed. This is flooding my developers' inboxes with spurious error messages. The site is refusing the requests as expected

Re: tests failing/throwing errors - not sure where to start

On Mon, Aug 19, 2013 at 4:13 PM, VernonCole <vernondc...@gmail.com> wrote: > Kris: > 9 failures and 17 errors are not an unusual number (out of 556 tests) > given the complexity of django and the number of platforms it works on. > The number and selection of failed tests w

Re: tests failing/throwing errors - not sure where to start

Kris: 9 failures and 17 errors are not an unusual number (out of 556 tests) given the complexity of django and the number of platforms it works on. The number and selection of failed tests will vary depending on the exact implementation you are running. However, I notice that _none_

Re: Tests -- Errors vs. Failures

I'm in favor of the second version because the first one hides the stack trace. `self.fail` is almost always the wrong answer, because the actual failure happened earlier in the test! I usually include a comment like "# this should not raise an exception" in such tests to explain why they

Re: Tests -- Errors vs. Failures

Hi Shai, On 07/08/2013 02:55 PM, Shai Berger wrote: > I just pushed a fix to a test failure on Oracle -- the last-executed-query > test. However, I want to ask about the preferred style in writing the test > itself. The test, as it is written now, is: > > def

Tests -- Errors vs. Failures

Hi all, I just pushed a fix to a test failure on Oracle -- the last-executed-query test. However, I want to ask about the preferred style in writing the test itself. The test, as it is written now, is: def test_last_executed_query(self): """ last_executed_query should not

Re: runserver fails on non-fatal model validation errors

) anyway, Instead > of > using the "ordering" meta option, just add the "order_by" clause to the > customized queryset. Admittedly, this is more of a workaround than a > solution. > I tried this, and can confirm that it gets me the result I'm looking for with no va

Re: runserver fails on non-fatal model validation errors

ket report. In the > worst case, it will end up running a server with models that don't work > properly ... in which case the user has ignored the model validation errors > at their own peril. Since runserver is not even intended for production > use, I don't see much of a downside. > T

Re: Updating default errors in contrib.auth.forms.PasswordResetForm

The canonical way of handling this so as not to leak information like that is to do exactly the same thing UX wise for success and failures, and just update the message to state that if an email address by that account has been registered they will get an email soon. On Friday, November 2,

Re: Updating default errors in contrib.auth.forms.PasswordResetForm

Hi Lee, What you propose certainly sounds reasonable -- anything that reduces the exposure of valid accounts to an external source is a good thing, IMHO. Did you have an alternative wording to suggest? If you do, please open a ticket. Yours, Russ Magee %-) On Fri, Nov 2, 2012 at 9:42 PM, Lee

Updating default errors in contrib.auth.forms.PasswordResetForm

Hi all, I wasn't sure if it was best to open a ticket or post to the dev group so here I am... I was curious what others thought about changing the default error in the PasswordResetForm which currently displays "That e-mail address doesn't have an associated user account. Are you sure you've

Re: Errors in tests

On Apr 11, 2:50 pm, Łukasz Rekucki wrote: > As for the error, it's quite a puzzle. If update() tries to iterate > thru value, it means it's a non-empty sequence that's not a subclass > of dict, right? Did you manage to track what type of value it is? > There must be a bug

Re: Errors in tests

On 11 April 2012 13:37, Vinay Sajip <vinay_sa...@yahoo.co.uk> wrote: > The errors seem to be related to Aymeric's change in r17894. If I > change > >    def _reset_dicts(self, value=None): >        builtins = {'True': True, 'False': False, 'None': No

Re: Errors in tests

The errors seem to be related to Aymeric's change in r17894. If I change def _reset_dicts(self, value=None): builtins = {'True': True, 'False': False, 'None': None} if value: builtins.update(value) self.dicts = [builtins] to the seemingly equivalent

Errors in tests

File "/home/vinay/projects/django/django/template/context.py", line 18, in __init__ self._reset_dicts(dict_) File "/home/vinay/projects/django/django/template/context.py", line 23, in _reset_dicts builtins.update(value) ValueError: dictionary update sequence element #0 has

Re: Django should not use `force_unicode(..., errors='replace')` when parsing POST data.

/ corruption issue. Depending on the actual data being submitted and the web site in question, this may be a non-issue, it may be inconvenient but acceptable, it may be critical, and it may cause errors down the line (like the `DatabaseError` exception). However, neither users or developers currently

Re: Django should not use `force_unicode(..., errors='replace')` when parsing POST data.

T data that is incorrectly encoded, and how this can >> send someone (like me) down the rabbit hole trying to debug it, thanks to >> "current transaction aborted" database errors. >> > > This reminds me of Postel's Law, "Be conservative in what you do, b

Re: Django should not use `force_unicode(..., errors='replace')` when parsing POST data.

e trying to debug it, thanks to "current > transaction aborted" database errors. > This reminds me of Postel's Law, "Be conservative in what you do, be liberal in what you accept from others." I see the reason behind your desire to respond to this unicode error at the point of

Re: Django should not use `force_unicode(..., errors='replace')` when parsing POST data.

Tai, The idea behind errors='replace' is that any chars that cannot be properly decoded as unicode will be replaced with an acceptable unicode char (something like '?'). So, if you want to avoid crashing your program on bad input, this is the only acceptable approach and, I assume, why

Django should not use `force_unicode(..., errors='replace')` when parsing POST data.

I've just created an essay *cough* I mean ticket about the way Django silently mangles POST data that is incorrectly encoded, and how this can send someone (like me) down the rabbit hole trying to debug it, thanks to "current transaction aborted" database errors. This shouldn't norma

Re: Tests introduced in patch for #17327 causing errors

l.com)> wrote: > > > > > Thanks. I stumbled upon the same problem. > > > > > > On Wednesday, March 7, 2012 4:40:56 PM UTC+8, Ryan Kaskel wrote: > > > Hi all. > > > > > > I've pulled in the latest changes and it seems like ticket #17327

Re: Tests introduced in patch for #17327 causing errors

Hi all. > > I've pulled in the latest changes and it seems like ticket #17327 [1] > introduces a few new tests that are raising errors when I run contrib.auth > tests via my project: > > - > auth.MultiDBChangepasswordManagementCommandTestCase.test_that_changepasswo

Re: Tests introduced in patch for #17327 causing errors

Thanks. I stumbled upon the same problem. On Wednesday, March 7, 2012 4:40:56 PM UTC+8, Ryan Kaskel wrote: > > Hi all. > > I've pulled in the latest changes and it seems like ticket #17327 [1] > introduces a few new tests that are raising errors when I run contrib.auth > te

Re: Tests introduced in patch for #17327 causing errors

and it seems like ticket #17327 [1] > introduces a few new tests that are raising errors when I run contrib.auth > tests via my project: > > - > auth.MultiDBChangepasswordManagementCommandTestCase.test_that_changepassword_command_with_da

Tests introduced in patch for #17327 causing errors

Hi all. I've pulled in the latest changes and it seems like ticket #17327 [1] introduces a few new tests that are raising errors when I run contrib.auth tests via my project

Re: Suppressed template errors in admin

Am 25.08.2011 06:19, schrieb h3: But this would have side effects on the non-admin templates too.. so it's not ideal. Maybe something like this: TEMPLATE_STRING_IF_INVALID = {'default: '!! Invalid var !!', 'django.contrib.admin': ''} I do a hack in my admin.py:

Re: Suppressed template errors in admin

On 6 Sep., 09:17, Thomas Guettler wrote: > Ole, can you please set up a a branch at github or bitbucket? Eh, is that not overkill? I don't think discussing this is worth anyone's time. No need to promise anything or elevate this to a Big Decision as long as it's about trivial

Re: Suppressed template errors in admin

in in the future. If we can fix it now with >> relatively little incovenience, fine, but I don't want that to turn into >> a promise. > > If the django core makes a promise that > TEMPLATE_STRING_IF_INVALID=RaiseMissingVariable() is > supported in admin (and other contrib apps), I wil

Re: Suppressed template errors in admin

Hi Luke, On Sat, Sep 3, 2011 at 9:13 PM, Luke Plant wrote: > On 25/08/11 00:39, Russell Keith-Magee wrote: > >> On principle, I have no objection to the idea of making the admin >> templates more robust in the presence of TEMPLATE_STRING_IF_INVALID; >> adding dummy values

Re: Suppressed template errors in admin

On 25/08/11 00:39, Russell Keith-Magee wrote: > On principle, I have no objection to the idea of making the admin > templates more robust in the presence of TEMPLATE_STRING_IF_INVALID; > adding dummy values in the context sounds like a reasonable approach > -- *if* doing this doesn't undermine

Re: Suppressed template errors in admin

On 25 Aug., 06:19, h3 <hainea...@gmail.com> wrote: > I'm not sure suppressing templates errors for the admin is such a > great idea. The suggestion on the table is to fix the couple of places where admin is sloppy and doesn't include all the variables it uses in the context. Normal

Re: Suppressed template errors in admin

On 25 Aug., 01:39, Russell Keith-Magee wrote: > On principle, I have no objection to the idea of making the admin > templates more robust in the presence of TEMPLATE_STRING_IF_INVALID; > adding dummy values in the context sounds like a reasonable approach > -- *if* doing

Re: Suppressed template errors in admin

I'm not sure suppressing templates errors for the admin is such a great idea. I work on two projects[1] where I would lose a useful debugging information and it would be the same lost to anyone working on the admin or extending the admin. Of course we could use a settings to toggle on/off

Re: Suppressed template errors in admin

On Wed, Aug 24, 2011 at 11:44 PM, Ole Laursen wrote: > Hi! > > I have a project where setting TEMPLATE_STRING_IF_INVALID has been > invaluable in finding problems (for various reasons). The caveat > mentioned in the docs don't kick in here because no templates are > inherited from

Re: Suppressed template errors in admin

On 08/24/2011 05:44 PM, Ole Laursen wrote: Hi! I have a project where setting TEMPLATE_STRING_IF_INVALID has been invaluable in finding problems (for various reasons). The caveat mentioned in the docs don't kick in here because no templates are inherited from elsewhere. Except the admin which

Suppressed template errors in admin

Hi! I have a project where setting TEMPLATE_STRING_IF_INVALID has been invaluable in finding problems (for various reasons). The caveat mentioned in the docs don't kick in here because no templates are inherited from elsewhere. Except the admin which unfortunately breaks down in some places. I

Re: Should test failures/errors in the Django test suite when executed under MySQL be considered blockers?

And if is a real problem in the MySQL support, I'm willing to look into it. I use it in production. You might have to poke me directly but I am trying to pay attention lately. On Thu, Jun 23, 2011 at 5:53 PM, Jacob Kaplan-Moss wrote: > Hi Jim -- > > Historically, most Django

Re: Should test failures/errors in the Django test suite when executed under MySQL be considered blockers?

Hi Jim -- Historically, most Django core developers have been PostgreSQL users (and advocates to some degree). This has meant that, yes, MySQL support has lagged behind. It's not that MySQL support isn't considered important, but it is a matter of priorities. I, at least, am going to prioritize

Should test failures/errors in the Django test suite when executed under MySQL be considered blockers?

backend. The results weren't pretty. I had to make a few changes to get the tests to even execute (related to a missing "pk" field in regression_tests/admin_views), and once I did I got FAILED (failures=91, errors=219, skipped=21, expected failures=2)*.* It's a bit hard to know w

Re: logging view errors

Hi, On May 10, 11:33 pm, Shawn Milochik wrote: > You and someone on django-users both told me about process_exception, > which I had been unaware of. It looks perfect for what I need. There is also a signal for it:

Re: logging view errors

On 05/10/2011 04:52 PM, Michael Blume wrote: A developer can currently do this pretty easily with middleware by setting a process_exception method. We could provide some contrib middleware for logging exceptions, but I don't see any need to bring this into core. -Mike Mike, You and

Re: logging view errors

view a 500 (or a > 403 for a missing CSRF token) error will occur, but nothing is logged and > there is no obvious way to figure out what broke. This is mainly useful > during development. > > 2. In production, it would be helpful to be able to check the log for these > errors to p

logging view errors

and there is no obvious way to figure out what broke. This is mainly useful during development. 2. In production, it would be helpful to be able to check the log for these errors to preemptively fix bugs. Thank you for your time. Shawn -- You received this message because you are subscribed

Re: Ticket #15860: modelform.is_valid() and modelform.errors fail to anticipate database integrity errors, allows exceptions to reach the user

Hi, On Apr 20, 8:00 am, legutierr <leguti...@gmail.com> wrote: > modelform.is_valid() fails to anticipate database integrity errors > when those errors involve any fields that are not part of that form > itself. That is wanted behaviour, eg consider my workflow: class Som

Ticket #15860: modelform.is_valid() and modelform.errors fail to anticipate database integrity errors, allows exceptions to reach the user

I hope it's OK to copy the body of the ticket here, even if it is redundant, in order to spur discussion. I'm willing to work on a patch if there is a consensus as to the proper solution... modelform.is_valid() fails to anticipate database integrity errors when those errors involve any fields

Re: Inline template rendering in admin shouldn't silence errors

to break when including templates fails, no matter if that >>> was in the parse time or rendering time. >>> >>> To address your "original point -- that runtime template errors are >>> considered unacceptable" I suggested that we have 2 different template >>>

Re: Inline template rendering in admin shouldn't silence errors

ditional problems for templates with variable names. >> >> However main point that George made was that he wanted template >> rendering to break when including templates fails, no matter if that >> was in the parse time or rendering time. >> >> To address your

Re: Inline template rendering in admin shouldn't silence errors

On Thu, Sep 2, 2010 at 7:40 PM, George Karpenkov <true.chesh...@gmail.com> wrote: > Dear Russ, > > I still don't quite get why "runtime template errors are > unacceptable". My understanding is that if user has DEBUG=True, and > TEMPLATE_DEBUG=True, then clearly (at

Re: Inline template rendering in admin shouldn't silence errors

Dear Russ, I still don't quite get why "runtime template errors are unacceptable". My understanding is that if user has DEBUG=True, and TEMPLATE_DEBUG=True, then clearly (at least to me) the user does want to see all of the errors. DEBUG flags should be off in the production environm

Re: Inline template rendering in admin shouldn't silence errors

wanted template > rendering to break when including templates fails, no matter if that > was in the parse time or rendering time. > > To address your "original point -- that runtime template errors are > considered unacceptable" I suggested that we have 2 different template > ta

Re: Inline template rendering in admin shouldn't silence errors

time. To address your "original point -- that runtime template errors are considered unacceptable" I suggested that we have 2 different template tags instead of include, one that will break, another one that will not, because me and George wanted to have not the current version of include t

Re: Inline template rendering in admin shouldn't silence errors

in most cases {% include %}  is used as "require", so in my > opinion it should raise errors! > > I'd also consider a require-once pattern to fix common widget chrome > problems (i.e. different parts of the page might include jquery in > headers). Either I'm completely missing

Re: Inline template rendering in admin shouldn't silence errors

be called {% require template %} instead of include, or maybe this whole pattern should be written as {% include-first templ %} But in most cases {% include %} is used as "require", so in my opinion it should raise errors! I'd also consider a require-once pattern to fix common widget c

Re: Inline template rendering in admin shouldn't silence errors

On Thu, Sep 2, 2010 at 1:42 PM, burc...@gmail.com <burc...@gmail.com> wrote: > Hi George, > > I believe this is a bug since any other errors in admin (not related > to inlines) don't pass silently. > > Silencing errors should always be documented, especially if error

Re: Inline template rendering in admin shouldn't silence errors

Hi George, I believe this is a bug since any other errors in admin (not related to inlines) don't pass silently. Silencing errors should always be documented, especially if error is silenced when DEBUG is turned on. So it's either documentation or implementation bug. By the way, does it show

Re: Inline template rendering in admin shouldn't silence errors

gt; with a custom template, say "a.html" > > 2) Write anything to "a.html" which will raise TemplateSyntaxError - > > ie "{% extends "a.html" %} > > 3) Observe the change_form for A. Note that you do not see any errors, > > but instead th

Re: Inline template rendering in admin shouldn't silence errors

will raise TemplateSyntaxError - > ie "{% extends "a.html" %} > 3) Observe the change_form for A. Note that you do not see any errors, > but instead the whole inline does not appear at all. > > I find this behavior extremely confusing and annoying. Is it just

Inline template rendering in admin shouldn't silence errors

Steps to reproduce: 1) Specify a custom admin class (say A) which mentions a custom inline with a custom template, say "a.html" 2) Write anything to "a.html" which will raise TemplateSyntaxError - ie "{% extends "a.html" %} 3) Observe the change_form for A.

Re: django.contrib.views.login errors

'django-fathers' :-) On Wed, Aug 25, 2010 at 8:49 PM, Sergej dergatsjev eecho wrote: > I think, much less such emails will appear if this group will be renamed. > *contributors* for example... > > 2010/8/25 Karen Tracey >> >> Please ask questions

Re: django.contrib.views.login errors

I think, much less such emails will appear if this group will be renamed. **contributors* for example...* * * 2010/8/25 Karen Tracey > Please ask questions about using Django on django-users, not here. The > topic of this list is discussion of the development of Django

Re: django.contrib.views.login errors

Please ask questions about using Django on django-users, not here. The topic of this list is discussion of the development of Django itself. Thanks, Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to

Ticket #13844 - Errors when using character fields for aggregation

I wanna to call attention to this bug. When using a aggregate in a CharField, we get a value_error because returned value are cast to float, so a single query like Link_A.objects.all().aggregate(Max('short_link')) raise value error and need to be done with connection.cursor().execute(...). All

Re: Proposal: errors with URLs in them

On 2010-01-21, at 3:53 PM, Russell Keith-Magee wrote: > On Fri, Jan 22, 2010 at 1:35 AM, Andy McKay <a...@clearwind.ca> wrote: >> >> This is of course won't be possible for all errors or all parts of Django, >> but would work for some of the more common errors that c

  1   2   >