Re: Consistent exception handling in templates.
Could we summarize in few words?
| DEBUG (development) | not DEBUG (production)
TEMPLATE_DEBUG | raise TemplateSyntaxError | ?
not TEMPLATE_DEBUG| ? | ?
On Sat, Jul 9, 2011 at 12:53 PM, Tai Lee wrote:
>
>
> On Jul 9, 12:24 pm, Karen Tracey wrote:
>> I'm strongly against that idea. Swallowing errors makes it incredibly
>> difficult to debug errors. I would prefer for the `TEMPLATE_DEBUG`
setting to
>> turn off much of the error-silencing currently done in template
processing.
>> Yes, that means different behavior during development compared to
>> production. But running with DEBUG (template or otherwise) on IS
different
>> from production, that's a given. And it this case it would allow for more
>> effective development since errors wouldn't be hidden away in nearly
>> impossible-to-find places. In my mind that's a tradeoff well worth
making.
>>
>> See ticket #13167 for one example of where "template errors" have not
been
>> silenced since before 1.0. If that case is to be be "fixed" now, I would
>> very much want that silencing to ONLY happen when TEMPLATE_DEBUG is
False.
>> In my opinion silencing these during development would be a huge step
>> backwards.
>
> I think we are in agreement here. Swallowing errors makes it
> incredible difficult to debug errors. I would like to see the
> circumstances when exceptions are swallowed be more clearly defined,
> and ensure that only exceptions that are expected to be swallowed, are
> swallowed. If we can do that, then there should be no need for the
> behaviour to change based on the `TEMPLATE_DEBUG` setting.
>
> The problem with the inconsistent behaviour associated with this
> setting is exceptions that are expected to be swallowed, that we want
> to be swallowed, are not being swallowed in some cases when
> `TEMPLATE_DEBUG = True`. This can make it impossible to access some
> URLs on a website where such a condition is present, even though there
> is no actual error and the exception is expected to be silenced. It
> also results in some exceptions being transformed into
> `TemplateSyntaxError` sometimes, and the true exception raised other
> times.
>
> See ticket #16147 for an example where `TemplateDoesNotExist` is
> raised when the template DOES exist, because a template tag inside the
> template being loaded raises `TemplateDoesNotExist` at compile time,
> only when `TEMPLATE_DEBUG = True`.
>
> This can make it impractical to develop locally with `TEMPLATE_DEBUG =
> True`, because it can prevent access to working pages, which means you
> miss out on all the enhanced debugging that `TEMPLATE_DEBUG = True`
> provides when you encounter an actual error that needs developer
> attention.
>
> With the intent being that template authors should not be able to
> trigger HTTP 500 errors on a production site, couldn't we achieve that
> by silencing exceptions raised when an invalid argument was passed to
> a template tag (e.g. `ValueError` or `TypeError` in the template tag
> code), but allowing exceptions raised in the code for the object that
> was passed in to the template tag as an argument?
>
> For example, if an object that calculates and returns a number when
> evaluated is passed to `{% widthratio %}`, but there is a bug in the
> code of that object and it raises some kind of exception when
> evaluated, that should not be silenced. It should bubble up so that
> the developer is alerted to a problem in the code for that object (not
> an error that the template author has made by passing an invalid
> argument). However, if there was no exception raised in evaluating the
> object, but it simply returned something other than a number, then
> that should behave the same as if an empty string or missing template
> variable was passed in and no exception should be raised.
>
> I think that a `TemplateSyntaxError` should be raised at compile time
> if an invalid template tag is used (unknown, too few or too many
> arguments). The `render()` function for a template tag should silence
> exceptions raised when arguments with the incorrect type or value are
> provided, but should not silence exceptions raised when evaluating the
> arguments themselves (or properties on the arguments).
>
> Cheers.
> Tai.
>
> --
> You received this message because you are subscribed to the Google Groups
"Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
>
>
--
Best regards, Yuri V. Baburov, Skype: yuri.baburov, MSN: bu...@live.com
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr.
Grouping commands by app in ./manage.py help
Hi everyone, Recently I'm becoming more and more annoyed with ./manage.py help behavior -- in projects with many dependencies it's virtually impossible to find the command you need as there are just too many, and searching for the one you need takes ages (and ages and ages). So I thought that grouping by app can make the output much better, and implemented grouping-by-apps in the help command. One detail I'm not too sure about is that in get_command() for some(?) reason 'startapp' command maps to ProjectCommand, while every other command maps to the corresponding app. I've hardcoded the special-case-check for ProjectCommand, but it would be nice to know why it was done this way in the first place. Corresponding ticket with patch - https://code.djangoproject.com/ticket/16445 See below for the example of how much difference it makes: Available subcommands: backfill_api_keys build_solr_schema changepassword clean_predicates clean_pyc clean_relations cleanup clear_index collectstatic compile_pyc compilemessages convert_to_south create_app create_command create_jobs createcachetable createsuperuser css_slate csv_report customdashboard custommenu datamigration dbshell delete_orphaned_references describe_form diffsettings dumpdata dumpscript export_emails fetch_training_dates find_template findstatic flush generate_secret_key graph_models graphmigrations haystack_info inspectdb loaddata loadmongodata lumpy_migration mail_debug makemessages migrate migrate_legacy migrate_to_mongo mongostack_update passwd print_user_for_session rebuild_index rebuild_mptt rebuild_mptt_direct repair_tree reset reset_db runfcgi runjob runjobs runprofileserver runscript runserver runserver_plus schemamigration set_fake_emails set_fake_passwords shell shell_plus show_recent_edits show_templatetags show_urls sql sqlall sqlclear sqlcustom sqldiff sqlflush sqlindexes sqlinitialdata sqlreset sqlsequencereset startapp startmigration sync_media_s3 syncdata syncdb test testserver thumbnail_cleanup unreferenced_files update_index update_rsscontent validate Compare that to: Available subcommands: admin_tools.dashboard: customdashboard admin_tools.menu: custommenu bios: csv_report compressor: css_slate django.contrib.auth: changepassword createsuperuser django.contrib.staticfiles: collectstatic findstatic runserver django.core: cleanup compilemessages createcachetable dbshell diffsettings dumpdata flush inspectdb loaddata makemessages reset runfcgi shell sql sqlall sqlclear sqlcustom sqlflush sqlindexes sqlinitialdata sqlreset sqlsequencereset startapp validate django_extensions: clean_pyc compile_pyc create_app create_command create_jobs describe_form dumpscript export_emails find_template generate_secret_key graph_models mail_debug passwd print_user_for_session reset_db runjob runjobs runprofileserver runscript runserver_plus set_fake_emails set_fake_passwords shell_plus show_templatetags show_urls sqldiff sync_media_s3 syncdata unreferenced_files easy_thumbnails: thumbnail_cleanup feincms: rebuild_mptt rebuild_mptt_direct update_rsscontent feincmstools: lumpy_migration repair_tree haystack: build_solr_schema clear_index haystack_info rebuild_index update_index legacy: clean_predicates clean_relations fetch_training_dates migrate_legacy migrate_to_mongo mongoadmin: show_recent_edits mongointegrity: delete_orphaned_references mongostack: mongostack_update mongoutils: loadmongodata south: convert_to_south datamigration graphmigrations migrate schemamigration startmigration syncdb test testserver tastypie: backfill_api_keys -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/VbaOUKafrIQJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Deferred constraint checking causing problems during test runs
On Sun, Jul 10, 2011 at 5:35 AM, Jim D. wrote: > The problem is that by default in most of our backends, a transaction runs > with constraint checks deferred. This means that foreign keys are *not* > checked for integrity until a transaction is committed. But here's the rub: > we never commit a transaction during tests, we roll it back instead. > Therefore, none of the queries against the DB are being checked for > integrity. (The exception is MySQL InnoDB, which I'll get to in a sec.) > As part of the work I was doing recently to disable and re-enable constraint > checks during fixture loading, I realized that we were handling this sort of > incorrectly across our backends. Postgresql in fact does provide a facility > for enabling constraint checks: SET CONSTRAINT CHECKS ALL IMMEDIATE. This > statement causes Postgresql to behave as it normally would, when it was > executing queries outside of a transaction. By default, PostgreSQL creates all constraints as NOT DEFERRABLE. To get the observed behaviour we'd need to be explicitly defining constraints as DEFERRABLE INITIALLY DEFERRED. Maintaining the property of deferrable constraints seems important here, so changing the deferrability of constraints, or overriding it using the SET CONSTRAINTS command at the top of the transaction might not be what we want. What I would recommend is that we issue an explicit SET CONSTRAINTS ALL IMMEDIATE command immediately before the ROLLBACK at *end* of test. This will fire any outstanding checks. That way all constraint checks will occur in the same place they would during a commit, yet we can maintain the situation that the test ends with a rollback. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Grouping commands by app in ./manage.py help
On Sunday, July 10, 2011, George Karpenkov wrote: > Hi everyone, > Recently I'm becoming more and more annoyed with ./manage.py help behavior -- > in projects with many dependencies it's virtually impossible to find the > command you need as there are just too many, and searching for the one you > need takes ages (and ages and ages). > So I thought that grouping by app can make the output much better, and > implemented grouping-by-apps in the help command. > One detail I'm not too sure about is that in get_command() for some(?) reason > 'startapp' command maps to ProjectCommand, while every other command maps to > the corresponding app. I've hardcoded the special-case-check for > ProjectCommand, but it would be nice to know why it was done this way in the > first place. > Corresponding ticket with patch - https://code.djangoproject.com/ticket/16445 As I have noted on the ticket; this has been proposed in the past - see #11745. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Grouping commands by app in ./manage.py help
What do you think is required to get it into the trunk? I don't think the objections on #11745 are valid -- 1) If an app overrides builtin command, it would be quite confusing to see that command still under built-in app, as that would give you no hint that the command was overwritten. 2) I'm not quite sure how ./manage.py help --list would help -- if someone is parsing the list, they'll have to change their script anyway. On Jul 10, 9:13 pm, Russell Keith-Magee wrote: > On Sunday, July 10, 2011, George Karpenkov wrote: > > Hi everyone, > > Recently I'm becoming more and more annoyed with ./manage.py help behavior > > -- in projects with many dependencies it's virtually impossible to find the > > command you need as there are just too many, and searching for the one you > > need takes ages (and ages and ages). > > So I thought that grouping by app can make the output much better, and > > implemented grouping-by-apps in the help command. > > One detail I'm not too sure about is that in get_command() for some(?) > > reason 'startapp' command maps to ProjectCommand, while every other command > > maps to the corresponding app. I've hardcoded the special-case-check for > > ProjectCommand, but it would be nice to know why it was done this way in > > the first place. > > Corresponding ticket with patch -https://code.djangoproject.com/ticket/16445 > > As I have noted on the ticket; this has been proposed in the past - see > #11745. > > Yours, > Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Deferred constraint checking causing problems during test runs
On Jul 10, 2011, at 3:13 AM, Simon Riggs wrote: > Maintaining the property of deferrable constraints seems important > here, so changing the deferrability of constraints, or overriding it > using the SET CONSTRAINTS command at the top of the transaction might > not be what we want. Well, that's just it. We want tests to behave as much like production code as possible, so we actually *don't* want constraint checks to be deferred. When you're working with DB normally in production, i.e. outside of a transaction, constraints are checked immediately. It's only when you get into a transaction that they are deferred. Each of our tests run inside of a transaction, which is an artificial construct. So to emulate production, I'm arguing that this property is not something we want (*unless* we are testing a transaction or transaction like behavior, in which case it does make sense to temporarily suspend constraint checks). > What I would recommend is that we issue an explicit SET CONSTRAINTS > ALL IMMEDIATE command immediately before the ROLLBACK at *end* of > test. This will fire any outstanding checks. That way all constraint > checks will occur in the same place they would during a commit, yet we > can maintain the situation that the test ends with a rollback. This would conceivably work I think. I'm pretty sure Ramiro was exploring this approach actually. My feeling, however, is that this still allows you to get away with stuff you might not otherwise get away with in production. I also think it's more helpful seeing exactly where an integrity issue came up so you can address it. This is, for example, what allowed me to understand the handful of bugs that were hiding, i.e. because I could trace the Intergrity Error to the exact line of code that was triggering it. Your questions raise one issue that had not occurred to me though. One possible "problem" with putting constraint checks at the beginning is that there is now way for a test to recover from them. If you try to put bad data into the DB with immediate constraint checks on, you will raise and error *and* if I'm not mistaken the transaction will be rolled back at that very instant. So if for some reason you knew you were putting bad data in and wanted to recover from it in your test and keep going, that would not be possible. I'm not sure that's actually a problem, but it's certainly something to consider. It's another dimension of behavior that is changed. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Issue with Django Tutorial Part 1
I'm doing this Django tutorial
https://docs.djangoproject.com/en/dev/intro/tutorial01/
and was_published_today isn't working. Thanks for your time.
Here's the command line:
Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32
bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more
information.
(InteractiveConsole)
>>> from polls.models import Poll, Choice
>>> Poll.objects.all()
[]
>>> Poll.objects.get(pk=1)
>>> p = Poll.objects.get(pk=1)
>>> p.was_published_today()
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'Poll' object has no attribute
'was_published_today'
Here's models.py
# Create your models here.
from django.db import models
import datetime
class Poll(models.Model):
question = models.CharField(max_length=200)
pub_date = models.DateTimeField('date published')
def __unicode__(self):
return self.question
def was_published_today(self):
return self.pub_date.date() == datetime.date.today()
class Choice(models.Model):
poll = models.ForeignKey(Poll)
choice = models.CharField(max_length=200)
votes = models.IntegerField()
# ...
def __unicode__(self):
return self.question
>>> dir (p)
['DoesNotExist', 'MultipleObjectsReturned', '__class__',
'__delattr__', '__dict_
_', '__doc__', '__eq__', '__format__', '__getattribute__',
'__hash__', '__init__
', '__metaclass__', '__module__', '__ne__', '__new__',
'__reduce__', '__reduce_e
x__', '__repr__', '__setattr__', '__sizeof__', '__str__',
'__subclasshook__', '_
_unicode__', '__weakref__', '_base_manager',
'_collect_sub_objects', '_default_m
anager', '_deferred', '_get_FIELD_display',
'_get_next_or_previous_by_FIELD', '_
get_next_or_previous_in_order', '_get_pk_val',
'_get_unique_checks', '_meta', '_
perform_date_checks', '_perform_unique_checks', '_set_pk_val',
'_state', 'choice
_set', 'clean', 'clean_fields', 'date_error_message', 'delete',
'full_clean', 'g
et_next_by_pub_date', 'get_previous_by_pub_date', 'id', 'objects',
'pk', 'prepar
e_database_save', 'pub_date', 'question', 'save', 'save_base',
'serializable_val
ue', 'unique_error_message', 'validate_unique']
Note: I am also using instantdjango.com 's Instant Django.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Issue with Django Tutorial Part 1
Please ask questions about using Django on django-users. The topic of this list is the development of Django itself. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Decision for ticket #6362 - Remove blank spaces with strip when validating the data
On Sunday, July 10, 2011 12:06:34 AM UTC+12, Andrew Ingram wrote: > > I'm on the fence here, I like the idea of a strip flag, but I do agree that > it seems too specific. Perhaps something more generic, eg: > > myfield = models.CharField(max_length=255, text_filters=[StripFilter, > UpperFilter]) > -1 for 'text_filters' attribute (we've got clean_[fieldname] methods for cases like this, or subclassing the field if you're in to that) +0 for a 'strip' attribute (it's a common case) > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/jsis5aA6K60J. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Decision for ticket #6362 - Remove blank spaces with strip when validating the data
To clarify, didn't even notice we were talking about models.Field, I'm +0 for a 'strip' attribute on the form's field, nothing on the model. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/r9DLUCsK6rUJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
