On 1/6/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> > * Move auth to django.contrib.admin (and change dependencies)
>
> Did you mean move auth to django.contrib.auth here? Or do you really
> want it moved into admin?
My mistake -- I meant django.contrib.auth.
Adrian
--
Adrian Holovaty
hol
On 1/6/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> * Move auth to django.contrib.admin (and change dependencies)
Did you mean move auth to django.contrib.auth here? Or do you really
want it moved into admin?
Joseph
On 1/6/06, Ian Holsman <[EMAIL PROTECTED]> wrote:
>
> Hi.
> I'm using packages.
> I think it is a good place to put stuff like package-specific preferences.
I'm going to leave them as is for now. There's actually quite a bit
that depends on them that I need to take a closer look at. I'm
starting
Hi.
I'm using packages.
I think it is a good place to put stuff like package-specific preferences.
ie.. the preference of the text markup you would like
(bbcode/markup/textile) is stored against the 'text' package.
if you like delicious/furl/digg is stored against the 'bookmark' package.
FWIW
On 1/6/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> Should sites be installed by init? I think it's used rarely enough
> that it shouldn't.
It's used by various bits and pieces, such as the RSS and redirect
frameworks, that need to know the fully-qualified domain name for an
object. Maybe t
On 1/6/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> In the magic-removal branch most traces of automatic pluralization
> have been removed, but the table names are still pluralized by
> default. I don't think they should be. Is this just a change that's
> meant to happen, but hasn't yet? I s
In the magic-removal branch most traces of automatic pluralization
have been removed, but the table names are still pluralized by
default. I don't think they should be. Is this just a change that's
meant to happen, but hasn't yet? I seem to remember a thread where
people wanted to get rid of all a
On 1/6/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> > If no one is using packages I'll just drop it.
>
> This is a bit easier said than done...The content-types table depends
> on it. How about splitting this patch into several stages --
>
> * Move sessions from core to django.contrib.sessio
On 1/6/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> Now that I think about it a little more I agree that core should be split
> into:
>
> django.contrib.sessions
> django.contrib.sites
Sounds good.
> If no one is using packages I'll just drop it.
This is a bit easier said than done...The
On 1/6/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> One more idea, though, would be to split "core" into
> django.contrib.sessions, django.contrib.contenttypes and
> django.contrib.sites. Packages would go away, because they're not
> really necessary (we used them heavily about 1.5 years ago
On 1/6/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 1/6/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> > Treating django.models.core and django.models.auth as special cases is
> > kind of confusing. They should be regular apps, but we don't want to
> > have to add 2 extra steps (insta
On 1/6/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
On 1/6/06, Amit Upadhyay <[EMAIL PROTECTED]> wrote:> What is the rigth way of catching IntegrityError, the traceback I get> suggests using _mysql_exceptions.IntegrityError, which is
> wrong because it assumes mysql, as well as it goes against th
On 1/6/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> Treating django.models.core and django.models.auth as special cases is
> kind of confusing. They should be regular apps, but we don't want to
> have to add 2 extra steps (installing the 2 apps) to get a django
> project up and running. Here
Treating django.models.core and django.models.auth as special cases is
kind of confusing. They should be regular apps, but we don't want to
have to add 2 extra steps (installing the 2 apps) to get a django
project up and running. Here's a few ideas for fixing the problems.
Create 2 new apps, djan
On 1/6/06, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> What is the rigth way of catching IntegrityError, the traceback I get
> suggests using _mysql_exceptions.IntegrityError, which is
> wrong because it assumes mysql, as well as it goes against the general
> python guideline of not using "hidden"
Hi there. What kind of time anticipated time line for no magic branch to
be tagged as a release? I am accumulating a fair amount of code and am
getting nervous about the number of changes that I will need to make
once this is stable.
Many thanks
David
At the current code, we could only hopes that all database backend
modules fully support Python DB API 2.0, in this case the Exception
tree. I did a simple dir() and looks like MySQLdb, psyopg1, and sqlite3
all support the exceptions, therefore you can reliably catch
IntegrityError exception
Hi,What is the rigth way of catching IntegrityError, the traceback I get suggests using _mysql_exceptions.IntegrityError, which is wrong because it assumes mysql, as well as it goes against the general python guideline of not using "hidden" members of modules.
Here is my traceback:>>> u = users.Us
On 1/6/06, Ian Holsman <[EMAIL PROTECTED]> wrote:
Hi Amit.if you modify the 'domain' column in the 'site' table and put hostname:port#it should work ok.Hi Ian,Thanks, I played with the admin, and figured out this thing myself soon after I posted that mail. Is this documented somewhere?
Thanks for
Hi Amit.
if you modify the 'domain' column in the 'site' table and put hostname:port#
it should work ok.
regards
Ian
On 1/6/06, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> On 1/5/06, Jason Davies <[EMAIL PROTECTED]> wrote:
>
> > Amit Upadhyay wrote:
> >
> > [snip]
> >
> > > But when I open the o
20 matches
Mail list logo
