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 aski

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 t

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 D

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 t

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 tha

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 bit

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 a

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

Re: Errors

gt; way 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 ')&

Re: Errors

: > 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,

Re: Errors

asy 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

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 (Contribu

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 t

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 "/Library/Frameworks/Python.framework/Versions/3.8/lib/py

Using QuerySet.iterator() with pgBouncer leads to nonexistent cursor errors (#28062)

Django 1.11 added support for server-side cursors on PostgreSQL: https://github.com/django/django/commit/f3b7c059367a4e82bbfc7e4f0d42b10975e79f0c As reported in https://code.djangoproject.com/ticket/28062, pgBouncer doesn't support using WITH HOLD cursors in transaction pooling mode, so the chan

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

t the code, 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

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)

y 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:

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.Corresp

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

r in non_field_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

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 argume

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 to

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

ore concise when 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('f

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

7;error message') In my models' clean methods, I have to keep track of the errors as I go along. class MyModel(models.Model): def clean(): errors = {} if check1(): errors['field1'] = 'error message' if check2(): err

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

On 11/17/2014 09:48 AM, Tim Graham wrote: > The reasoning for why it wasn't documented is provided here: > https://github.com/django/django/pull/1443#issuecomment-28045150 That comment is actually in favor of documenting it for Model.clean(), just suggested it be done in a separate PR. (Personall

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

ket #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

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 usi

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 s

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 build

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 tracebacks

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.

t;> 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

Re: DisallowedHost causes 500 errors.

UTC-5, 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 s

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 exp

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

On Mon, Aug 19, 2013 at 4:13 PM, VernonCole 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 will vary depending

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_ of the

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 don't

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 test_last_executed_query(self):

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 ra

Re: runserver fails on non-fatal model validation errors

t form. > > 2) Since you're overriding the manager's get_query_set() 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.

Re: runserver fails on non-fatal model validation errors

t). But that idea is completely halfbaked. > I included a patch for same in my original trac ticket 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 pe

runserver fails on non-fatal model validation errors

s, report them to the console, and then continue with its attempt to run the server. I included a patch for same in my original trac ticket 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

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, 20

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 Tr

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 somewhere else too. Whe

Re: Errors in tests

On 11 April 2012 13:37, Vinay Sajip 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': None} >

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 = [bui

Errors in tests

t, self).__init__(dict_) 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

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.

s 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, be > liberal in what you accept from others.

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

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 encoding, but the iss

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 an

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&#x

Re: Tests introduced in patch for #17327 causing errors

rote: > > > > > 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 tick

Re: Tests introduced in patch for #17327 causing errors

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_tha

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 &g

Re: Tests introduced in patch for #17327 causing errors

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_

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 pr

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 non-intrusive fixes

Re: Suppressed template errors in admin

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 will

Re: Suppressed template errors in admin

gt; a promise. If the django core makes a promise that TEMPLATE_STRING_IF_INVALID=RaiseMissingVariable() is supported in admin (and other contrib apps), I will help to get it done. Up to now, that's why I don't use the template language in my apps. Zen of Python: Errors should never pass silently.

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 in the context sounds li

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 bro

Re: Suppressed template errors in admin

On 25 Aug., 06:19, h3 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. Normally you don't

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 this doesn't undermine bro

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/of

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 elsewhere. Excep

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 un

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

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 core developers have

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

Thanks Jacob. At a minimum, I will at least try to wade through and open a few tickets if they aren't already open and upgrade bugs that are causing test suite errors or failures to release blocker. I did want to make sure I was not overstepping any bounds in assuming those were blo

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 th

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

nnoDB 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 k

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: http://docs.djangoproject.com/en/dev/ref/signals/#got-request-exception if you d

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 someon

Re: logging view errors

n error in a 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 &g

logging view errors

cur, 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 preemptively fix bugs. Thank you for your time. Shawn -- You received this m

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 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 SomeForm(ModelForm): class Meta:

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

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

> >>> You're talking about additional 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 pa

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

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 "original point -- that runtime template

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

On Thu, Sep 2, 2010 at 7:40 PM, George Karpenkov 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 least to me) the user

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 env

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

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 > tags instead o

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

rendering 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

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

uld it be > {% for templ in template_list %} >    {% try-include template %} > {% endfor %} > or the opposite to be called > {% require template %} instead of include, > or maybe this whole pattern should be written as >    {% include-first templ %} > > But in most cases {% include

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

e to 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 commo

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

On Thu, Sep 2, 2010 at 1:42 PM, 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 is > silenced when

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, do

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

l" > > 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 the whole inline does not appear at all. > &

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

> 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 a > bug or is there any reasoning behi

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. Note

  1   2   3   >