> `wrap_and_raise()` will appear in the traceback, `raise
> wrap_exception(SomeException())` would be cleaner.
I like that
> Better yet, make all exceptions that are used to reraise other
> exceptions a subclass of WrappingException (pick a better name) that
> either takes a `cause=exc` or
I think I should bring this ticket up before 1.2 is released
http://code.djangoproject.com/ticket/12171.
Unless I'm doing something wrong (highly possible), get_or_create is
broken with the "postgresql" db backend. This would be a pretty
serious problem, either because the backend lacks core funct
I'd like some opinions on the existing patch for
http://code.djangoproject.com/ticket/3349.
This ticket ("If an ImportError occurs within some loaders a rather
confusing exception is raised") seeks to address the difficulty of
debugging ImportErrors raised in template tag library.
The cause of th
Maybe you misunderstood -- I just meant for `firstof` and `cycle`, not
template tag implementation in general.
On Aug 3, 4:53 pm, Malcolm Tredinnick
wrote:
> On Mon, 2009-08-03 at 16:25 -0700, ab wrote:
> > Is this something that could be backwards-incompatible in 1.2?
>
> Please
Is this something that could be backwards-incompatible in 1.2? For
1.1, the options I can think of are to make new tags (cyclesafe) or
add yet another setting. Neither seems good. Any other ideas?
--~--~-~--~~~---~--~~
You received this message because you are subsc
When a template tag takes a variable as input and renders its value
(like the `cycle` or `firstof` tags), that value should respect the
context's autoescape setting. Right now, the values are never escaped.
I'm proposing to make this change, and provide a unified way for
people to implement their
In BaseFormSet, `errors` is a property, while `non_form_errors` is a
method. These two attributes of a FormSet are similar both
semantically and in the implementation (see `_get_errors`), so this
appears to be a straightforward design flaw. Am I missing something,
or should I create a ticket?
--~-
Here's some code we use at Disqus.
def model_bitfield_handler(attr_name, bit_number):
mask = 2**bit_number
def _bit_handler(self, new_val=None):
if new_val is not None:
old_val = (getattr(self, attr_name, 0) or 0)
if new_val:
setattr(self, a
For the api to accept a DSN, alias, or connection anywhere would add
similar code in multiple places. I propose that the aliases are mapped
into django.db.connections. For your example, you could use
django.db.connections.archive. I also propose that you can either
define a single database (as now
