Re: Proposal: Manage.py custom commands overloading

[Tai Lee]

If it feels wrong to put a command in "project/app1", you can put it
in "project" and simply add "project" to your INSTALLED_APPS. You can
then place any models, management commands, URLs, views, or anything
else that is common to all your "apps" in the "project" app.


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

1.0.1 release blockers?

[mrts]

There has been much reluctancy in letting triagers tag and prioritize
1.0.1 milestone tickets. Now that 1.0.1 is really close, can we
perhaps discuss what are the things that really should be fixed before
it is released?

The only major issue I have encountered is 
http://code.djangoproject.com/ticket/8882
that makes inline formsets that have unique fields (that is, pretty
much every other use case for them) unusable. Looks like brosner is
already working on it -- thanks! -- and it would be perhaps wasteful
if 1.0.1 is released before he has finished.

I believe this does not fall to the often-quoted "this is your
personal issue, go write a patch" category (I have worked around it
and brosner is already on it) -- it is just a common use case that
doesn't work as advertised. There are probably other major bugs and it
would be nice if people brought them up. Also, it would be nice if
some restraint is exercised in regard the attitude-laden remarks that
are quick to arise in this type of discussions.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Absolute paths in settings.py

[Ole Laursen]

On 30 Okt., 22:55, "Valts Mazurs" <[EMAIL PROTECTED]> wrote:
> There should be significantly greater number of Django projects that are
> deployed without any fancy stuff involved.
> Anyway, if someone wants to deploy his project as egg it would be easy to
> just change "PROJECT_DIR =.." as all other settings might stay the same.

Yeah, even without project dir auto-detection, it's better to
construct the absolute paths by concatenating with a PROJECT_DIR if
things are organized that way, DRY. Maybe it's plain, but the idea
didn't occur in my mind until recently. :)

The __file__ trick is a bit of a hack, I suppose Django usually has
some kind of idea of where things are located (or maybe not?).


Ole
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: 1.0.1 release blockers?

[Jacob Kaplan-Moss]

On Fri, Oct 31, 2008 at 4:38 AM, mrts <[EMAIL PROTECTED]> wrote:
> The only major issue I have encountered is 
> http://code.djangoproject.com/ticket/8882

Thanks for the pointer; I'd agree this should get in.

Jacob

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: 1.0.1 release blockers?

[[EMAIL PROTECTED]]

And whoops again, brosner has a patch that covers the parent fkey
issue.  My patch covers the issue of duplicate data within the
formset.

On Oct 31, 9:26 am, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> On Fri, Oct 31, 2008 at 4:38 AM, mrts <[EMAIL PROTECTED]> wrote:
> > The only major issue I have encountered 
> > ishttp://code.djangoproject.com/ticket/8882
>
> Thanks for the pointer; I'd agree this should get in.
>
> Jacob
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: 1.0.1 release blockers?

[[EMAIL PROTECTED]]

Ahh whoops, I have a patch for that(only covers unique right now),
will upload now.

Alex

On Oct 31, 9:26 am, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> On Fri, Oct 31, 2008 at 4:38 AM, mrts <[EMAIL PROTECTED]> wrote:
> > The only major issue I have encountered 
> > ishttp://code.djangoproject.com/ticket/8882
>
> Thanks for the pointer; I'd agree this should get in.
>
> Jacob
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Problem with object values in Django 1.0

[Opel]

I have been following along to the Django Tutorial after downloading
and installing V1.0. Everything is working fine apart from when I try
to use the python shell to return the objects names. I tried to skip
the step but when I tried to create the select menu of Polls for the
Choices all that was returned was "Poll Object" instead of the name.

This is what my model looks like at the moment

class Poll(models.Model):
question = models.CharField(max_length=200)
pub_date = models.DateTimeField('date published')

def __unicode__(self):
return self.question


class Choice(models.Model):
poll = models.ForeignKey(Poll)
choice = models.CharField(max_length=200)
votes = models.IntegerField()

def __unicode__(self):
return self.choice

When I do
>>>from mysite.polls.models import Poll, Choice
>>>Poll.object.all()

I get "poll.object" instead of a name. Could anyone point out where I
am going wrong please?

Thanks

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Problem with object values in Django 1.0

[Dan Fairs]

>
> This is what my model looks like at the moment
>
> class Poll(models.Model):
>question = models.CharField(max_length=200)
>pub_date = models.DateTimeField('date published')
>
> def __unicode__(self):
>return self.question


Your indentation is wrong. The 'def __unicode__' line needs to be  
intended to the same level as question and pub_date, else it won't be  
considered part of the Poll class.

Cheers,
Dan

--
Dan Fairs <[EMAIL PROTECTED]> | http://www.fezconsulting.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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Problem with object values in Django 1.0

[Dan Fairs]

Sorry - should also have mentioned that this should be on django-users.

On 31 Oct 2008, at 14:28, Opel wrote:

>
> I have been following along to the Django Tutorial after downloading
> and installing V1.0. Everything is working fine apart from when I try
> to use the python shell to return the objects names. I tried to skip
> the step but when I tried to create the select menu of Polls for the
> Choices all that was returned was "Poll Object" instead of the name.
>
> This is what my model looks like at the moment
>
> class Poll(models.Model):
>question = models.CharField(max_length=200)
>pub_date = models.DateTimeField('date published')
>
> def __unicode__(self):
>return self.question
>
>
> class Choice(models.Model):
>poll = models.ForeignKey(Poll)
>choice = models.CharField(max_length=200)
>votes = models.IntegerField()
>
> def __unicode__(self):
>return self.choice
>
> When I do
 from mysite.polls.models import Poll, Choice
 Poll.object.all()
>
> I get "poll.object" instead of a name. Could anyone point out where I
> am going wrong please?
>
> Thanks
>
> >

--
Dan Fairs <[EMAIL PROTECTED]> | http://www.fezconsulting.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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: 1.0.1 release blockers?

[Karen Tracey]

On Fri, Oct 31, 2008 at 6:38 AM, mrts <[EMAIL PROTECTED]> wrote:

>
> There has been much reluctancy in letting triagers tag and prioritize
> 1.0.1 milestone tickets. Now that 1.0.1 is really close, can we
> perhaps discuss what are the things that really should be fixed before
> it is released?
>

Really, there is not reluctance to get input on what should be fixed before
1.0.1 is released.  It's just that input in the form of working patches with
tests and doc is far more valuable than a simple bit on a ticket.  The list
of tickets that are ready for checkin is not so big (and some of them are
enhancements so not candidates for 1.0.1.) that we need some other bit to
say "look at this before releasing 1.0.1".


> The only major issue I have encountered is
> http://code.djangoproject.com/ticket/8882
> that makes inline formsets that have unique fields (that is, pretty
> much every other use case for them) unusable. Looks like brosner is
> already working on it -- thanks! -- and it would be perhaps wasteful
> if 1.0.1 is released before he has finished.
>

It really depends on how close a fix is as to whether it would be worthwhile
holding up a bugfix release on any one ticket. I'm not talking about this
ticket in particular (which I haven't looked at and it sounds like it's
already on others' radars so likely will get in, assuming it's not too
terribly difficult to fix) -- I'm trying to get across that holding up a
bugfix release in hopes of a not-yet-existent fix for a bug that's already
in a shipped release doesn't make much sense, unless you've got some reason
to believe a fix will be appearing real soon now.  There are already many
bugs that have been fixed in the 1.0.X branch and will benefit users.  1.0.1
will be better than 1.0, and 1.0.1 released in the very near future with n-x
bugs fixed is better than 1.0.1 released at some unknown future data with
those those additional x bugs fixed.

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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: 1.0.1 release blockers?

[Joey Wilhelm]

I would like to suggest the following:
http://code.djangoproject.com/ticket/9245
http://code.djangoproject.com/ticket/6710

They both have fully functional patches... although granted the second has
no tests.

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: 1.0.1 release blockers?

[James Bennett]

On Fri, Oct 31, 2008 at 5:38 AM, mrts <[EMAIL PROTECTED]> wrote:
> There has been much reluctancy in letting triagers tag and prioritize
> 1.0.1 milestone tickets. Now that 1.0.1 is really close, can we
> perhaps discuss what are the things that really should be fixed before
> it is released?

We certainly can discuss such things. To open a discussion on a
particular ticket, post a working patch with unit tests.


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Problem with object values in Django 1.0

[Andrew Cetnarskyj]

thanks Dan I had used tabs instead of spaces, I will subscribe to  
django-users for future problems

Andy



On 31 Oct 2008, at 14:46, Dan Fairs wrote:

>
> Sorry - should also have mentioned that this should be on django- 
> users.
>
> On 31 Oct 2008, at 14:28, Opel wrote:
>
>>
>> I have been following along to the Django Tutorial after downloading
>> and installing V1.0. Everything is working fine apart from when I try
>> to use the python shell to return the objects names. I tried to skip
>> the step but when I tried to create the select menu of Polls for the
>> Choices all that was returned was "Poll Object" instead of the name.
>>
>> This is what my model looks like at the moment
>>
>> class Poll(models.Model):
>>question = models.CharField(max_length=200)
>>pub_date = models.DateTimeField('date published')
>>
>> def __unicode__(self):
>>return self.question
>>
>>
>> class Choice(models.Model):
>>poll = models.ForeignKey(Poll)
>>choice = models.CharField(max_length=200)
>>votes = models.IntegerField()
>>
>> def __unicode__(self):
>>return self.choice
>>
>> When I do
> from mysite.polls.models import Poll, Choice
> Poll.object.all()
>>
>> I get "poll.object" instead of a name. Could anyone point out where I
>> am going wrong please?
>>
>> Thanks
>>
>>>
>
> --
> Dan Fairs <[EMAIL PROTECTED]> | http://www.fezconsulting.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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Mysql Ping and performance

[bo]

Not sure if this is a Django issue or the supporting Mysqldb (1.2.2)
python package .. (i'll stop this here if its not, but it seems worthy
of at least letting other know this)

however while profiling a page i came across this seemingly
performance hole.


   Ordered by: internal time

   ncalls  tottime  percall  cumtime  percall
filename:lineno(function)
  2300.3430.0010.3430.001 {method 'query' of
'_mysql.connection' objects}
  2280.1160.0010.1160.001 {method 'ping' of
'_mysql.connection' objects}
  2340.0290.0000.0470.000 query.py:
473(get_default_columns)
  9720.0210.0000.0480.000 __init__.py:
487(__init__)
 13030.0190.0000.0220.000 __init__.py:
633(__init__)
 20680.0170.0000.2160.000 __init__.py:
690(_resolve_lookup)
---

#1 time sink is the queries themselves (i figured that would be the
case) .. but #2 is "ping" and it seems to ping on every query.  This
issue is probably not so bad on Localhost or Socket based connections,
but on remote Mysql server, as you can see, it is not so good.

again not sure if django can solve (or even wants to solve this) ..

bo


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

ANN: Django 1.0.1 beta available

[James Bennett]

See the weblog entry:

http://www.djangoproject.com/weblog/2008/oct/31/101-beta/

And the downloads page:

http://www.djangoproject.com/download/

As previously mentioned, this is mainly a preview to let people get a
feel for what's been fixed/improved in the 1.0.X line since the 1.0
release, and a reminder to anyone who's interested in helping to fix
an issue in the 1.0.X codebase that time is running short leading up
to the 1.0.1 release :)


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Arbitrary objects in urlconf

[ludvig.ericson]

On Oct 29, 8:06 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> You can already do what your proposal would allow in middleware as
> seen here:http://www.b-list.org/weblog/2007/nov/06/urlconf/

Yes, that's one way.

But there's an issue with this: it breaks reverse mappings, which I
use a lot.

I realize that this is a limitation with Django, the URL system
doesn't care about hosts. Only paths.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Arbitrary objects in urlconf

[[EMAIL PROTECTED]]

There is a ticket about reverse not respecting request.urlconf.

Alex

On Oct 31, 7:50 pm, "ludvig.ericson" <[EMAIL PROTECTED]> wrote:
> On Oct 29, 8:06 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> wrote:
>
> > You can already do what your proposal would allow in middleware as
> > seen here:http://www.b-list.org/weblog/2007/nov/06/urlconf/
>
> Yes, that's one way.
>
> But there's an issue with this: it breaks reverse mappings, which I
> use a lot.
>
> I realize that this is a limitation with Django, the URL system
> doesn't care about hosts. Only paths.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

1.0.1 Feature UserProfile inline Filter in User

[Cornbread]

I've ran into an issue I think that many will run into.

In our project we have a profile for each user and we have integrated
that inline with the user settings page. We have also added items from
the profile (address, city, state, zip, is_boss, etc) into the auth
users view.

The issue comes up when we want to filter through those users by our
user profile items.

I'm not extremely familar to the inner workings to django. I was
thinking that it would be nice in the admin when registering the
Profile maybe in Meta: show_user_profile. then user_profile_fields =
('address', 'city', 'state', 'zip', etc).

Reported here: http://code.djangoproject.com/ticket/9463

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: 1.0.1 release blockers?

[Steve Holden]

Karen Tracey wrote:
> On Fri, Oct 31, 2008 at 6:38 AM, mrts <[EMAIL PROTECTED]
> > wrote:
>
>
> There has been much reluctancy in letting triagers tag and prioritize
> 1.0.1 milestone tickets. Now that 1.0.1 is really close, can we
> perhaps discuss what are the things that really should be fixed before
> it is released?
>
>
> Really, there is not reluctance to get input on what should be fixed
> before 1.0.1 is released.  It's just that input in the form of working
> patches with tests and doc is far more valuable than a simple bit on a
> ticket.  The list of tickets that are ready for checkin is not so big
> (and some of them are enhancements so not candidates for 1.0.1.
> ) that we need some other bit to say "look at this
> before releasing 1.0.1".
>
>
> The only major issue I have encountered is
> http://code.djangoproject.com/ticket/8882
> that makes inline formsets that have unique fields (that is, pretty
> much every other use case for them) unusable. Looks like brosner is
> already working on it -- thanks! -- and it would be perhaps wasteful
> if 1.0.1 is released before he has finished. 
>
>
> It really depends on how close a fix is as to whether it would be
> worthwhile holding up a bugfix release on any one ticket. I'm not
> talking about this ticket in particular (which I haven't looked at and
> it sounds like it's already on others' radars so likely will get in,
> assuming it's not too terribly difficult to fix) -- I'm trying to get
> across that holding up a bugfix release in hopes of a not-yet-existent
> fix for a bug that's already in a shipped release doesn't make much
> sense, unless you've got some reason to believe a fix will be
> appearing real soon now.  There are already many bugs that have been
> fixed in the 1.0.X branch and will benefit users.  1.0.1 will be
> better than 1.0, and 1.0.1 released in the very near future with n-x
> bugs fixed is better than 1.0.1 released at some unknown future data
> with those those additional x bugs fixed.
>
Well right, that'll be 1.0.2 if it's needed. Though with 1.1 on the way
it seems less than likely.

regards
 Steve


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: 1.0.1 Feature UserProfile inline Filter in User

[[EMAIL PROTECTED]]

This just seems like a generalization of this: 
http://code.djangoproject.com/ticket/3400

On Oct 31, 7:28 pm, Cornbread <[EMAIL PROTECTED]> wrote:
> I've ran into an issue I think that many will run into.
>
> In our project we have a profile for each user and we have integrated
> that inline with the user settings page. We have also added items from
> the profile (address, city, state, zip, is_boss, etc) into the auth
> users view.
>
> The issue comes up when we want to filter through those users by our
> user profile items.
>
> I'm not extremely familar to the inner workings to django. I was
> thinking that it would be nice in the admin when registering the
> Profile maybe in Meta: show_user_profile. then user_profile_fields =
> ('address', 'city', 'state', 'zip', etc).
>
> Reported here:http://code.djangoproject.com/ticket/9463
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: #7611 contrib.auth PasswordResetTest requires specific templates for tests to pass

[Siddhi]

On Sep 7, 6:32 am, sciyoshi <[EMAIL PROTECTED]> wrote:
> On Jul 19, 2:15 am, "Russell Keith-Magee" <[EMAIL PROTECTED]>
> wrote:
>
> Not sure if this should be considered a related issue - theauthtests
> use a different urlconf that only include theauthurls, so if you
> provide custom registration templates that do reverse lookups with {%
> url %} for other urls in your projects, the tests fail...

Exactly, I ran into this problem as well. By overriding the urls, all
the other reverse lookups in the template start failing. Maybe reverse
lookups should fail silently while running under a unit tests?

--
Siddharta Govindaraj
http://siddhi.blogspot.com
http://www.silverstripesoftware.com/blog/
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---