I'm the author of the current patch; I'll just add a bit of
background.
On Dec 12, 10:18 pm, ab wrote:
>
> 1. Scope -- the patch generalizes the issue and addresses it
> throughout Django. Are people ok with that?
Since the problem of raising new exceptions and losing the original
one seemed sys
Am 14.12.2009 um 10:53 schrieb Andrew Durdin:
> I'm the author of the current patch; I'll just add a bit of
> background.
>
> On Dec 12, 10:18 pm, ab wrote:
>>
>> 1. Scope -- the patch generalizes the issue and addresses it
>> throughout Django. Are people ok with that?
>
> Since the problem of
On Sat, Dec 12, 2009 at 3:58 PM, Ivan Sagalaev
wrote:
> Mike Malone wrote:
>> On Tue, Dec 8, 2009 at 7:52 PM, Russell Keith-Magee
>> wrote:
>>> 4. I share Mike's concern about using settings.SITE_ID to determine
>>> the current host, but I'm not sure I have any suggestions on how we
>>> could pr
On Dec 12, 5:09 pm, Jacob Kaplan-Moss wrote:
>
> I prefer to think of it like this:
>
> Django 1.2 ships. Users read the release notes, and notice that
> psycopg1 is now deprecated and will be removed. It's still there, and
> still supported, so they can upgrade quickly and not have to be stuck
What do folks think about shipping http://code.google.com/p/django-rosetta
with Django? Enabling it per default even? imho that app is totally
worth being shipped with Django per default.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To p
On Mon, Dec 14, 2009 at 4:41 PM, Suno Ano wrote:
> What do folks think about shipping http://code.google.com/p/django-rosetta
> with Django? Enabling it per default even? imho that app is totally
> worth being shipped with Django per default.
>
>
I don't see it as being critical enough to be wort
> `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 wonder if there is a particular reason why last_login field of is not
defined as "null=True"? It makes sense to me to have it as null which would
mean that the user never logged in. Could there be any dependencies relying
on this field not being null?
Thanks
Sergiy
--
You received this messag
On Tue, Dec 15, 2009 at 5:41 AM, Suno Ano wrote:
> What do folks think about shipping http://code.google.com/p/django-rosetta
> with Django? Enabling it per default even? imho that app is totally
> worth being shipped with Django per default.
The question you need to answer is: "Does the Django p