Re: How control access to static pages that are *not* part of a Django app?

[Shawn Milochik]

I'm dealing with the same issue, and it looks like I'm probably going to 
adopt django-private-files for this.


http://pypi.python.org/pypi/django-private-files/0.1.2

It's on Read The Docs, bitbucket, and github. It does what I need it to 
do, it works with nginx, and it's been maintained recently.


The closest competitor I found is django-protected-files, but it doesn't 
look like it's been maintained for a long time.


Shawn


--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

How control access to static pages that are *not* part of a Django app?

[Chris Seberino]

My Django app only allows someone to access a /books page, that is
part of the Django app, if they are signed in.

The pages below that URL are just static directory listings of PDFs
all handled by Apache.
For example /books/book_1, /books/book_2, etc.

Because these directory listings aren't handled by Django, they don't
enjoy Django's access controls.  They don't even have a view since
they are just static pages handled by Apache.

Is there any way to somehow prevent access to them unless someone is
signed into my Django app?

chris

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: USE_I18N vs. USE_L10N

[Mike Dewhirst]

On 1/08/2011 8:09am, Lucy Brennan wrote:
I read Wikipedia and Django docs. Now, after all this debate, I see 
that I _did_ understand the definitions when I first read it.


Given those definitions however, the meaning of USE_I18N and USE_L10N 
are not obvious. Far, far, far from obvious. There _absolutely_ has to 
be some additional explanation of what those two settings does. How 
can you even think that it is obvious???


Can I try and summarise from the perspective of a new user? I want to 
include both in my current project so I'm hoping this summary is 
correct. Please correct me if I'm wrong ...


Localisation L10N - if switched on via USE_L10N = True - means try to 
detect the user's browser header which reveals the region set in the 
user's computer. IF detected AND if there is a 
../site-packages/django/conf/locale/[xx_XX]/formats.py which corresponds 
THEN django will magically translate numbers, dates and times accordingly.


Internationalisation i18n - if switched on via USE_I18N = True - means 
to enable translation of string/unicode literals found in the software 
PROVIDED the translation mechanism is being used AND translations of the 
literals exist. This mechanism involves ugettext.py and use of the 
language code deliberately selected by the user from among those on 
offer which you (the developer) have made available. The ugettext 
function goes off and finds the correct prepared translation file 
(../site-packages/django/conf/locale/[xx_XX]/LC_MESSAGES/django.po/.mo) 
and uses the literal as an index into that file and returns the 
translation for display to the user. That's the django translations. For 
your own software translations you have to prepare your own [app].po/.mo 
file.


If there is someone with experience in this area who can comment on this 
or correct it please?


Thanks

Mike




So since I could not figure that out, I started looking for 
explanations. And somewhere I found, that the settings meant 
respectively: translation and localized formatting. And that is why I 
sent this post on quite a detour. Sorry about that.


Do you people realize that if a newbie reads a) Wikipedia on I/L b) 
Django on I/L, c) this thread. They will still not understand what 
those two settings do!


@ Russell: I would not hesitate to help writing the documentation. But 
I simply don't know what those settings do. So I can't write it. 
(tragicomic smiley)


Lucy

--
You received this message because you are subscribed to the Google 
Groups "Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/d9ShQzQ7tnsJ.

To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.


--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Broken INTERNAL links related to django.contrib.auth

[Russell Keith-Magee]

On Mon, Aug 1, 2011 at 1:23 AM, ivan.o...@googlemail.com
 wrote:
> I get a lot of 'broken internal links' mails daily from a Django
> application I
> am hacking: http://grical.org
>
> They look like this::
>
>    Referrer: http://grical.org/accounts/login/e/show/580/
>    Requested URL: /accounts/login/e/show/
> 580/
>    User agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;
> TheFreeDictionary.com; .NET CLR 1.1.4322; .NET CLR 1.0.3705;    .NET
> CLR
> 2.0.50727)
>    IP address: ...
>
> Any idea where can be the problem?

There isn't necessarily a problem anywhere. All this tells you is that
someone, somewhere is requesting a URL that doesn't match a URL
pattern on your site.

The simplest possible cause of this is a dead link on a page -- in
your case, somewhere on the page served by the URL
/accounts/login/e/show/, there is a link that directs the user to
/accounts/login/e/show/580, but that link doesn't resolve. For
whatever reason, people are clicking on that link, so you're getting
notified that there is a problem.

However, it's also possible that this isn't a problem at all. The
internet is filled with lots of robots that wander around; some are
indexing content for search engines (like the GoogleBot); but some are
people probing your site for known security holes. These malicious
robots will frequently construct URLs that don't exist on your site in
an attempt to exploit bugs in the URL handling mechanisms for various
frameworks. There isn't much you can do to stop these people. A
robots.txt file will stop the well behaved robots at the cost of you
losing search engine rank; script kiddie robots don't obey robots.txt.
If you can validate that the link appearing in your log definitely
doesn't exist, and shouldn't exist, and isn't referenced anywhere on
your site, all you can really do here is try and mask these entries
out of your logs.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: USE_I18N vs. USE_L10N

[Lucy Brennan]

I read Wikipedia and Django docs. Now, after all this debate, I see that I 
_did_ understand the definitions when I first read it. 

Given those definitions however, the meaning of USE_I18N and USE_L10N are 
not obvious. Far, far, far from obvious. There _absolutely_ has to be some 
additional explanation of what those two settings does. How can you even 
think that it is obvious???

So since I could not figure that out, I started looking for explanations. 
And somewhere I found, that the settings meant respectively: translation and 
localized formatting. And that is why I sent this post on quite a detour. 
Sorry about that. 

Do you people realize that if a newbie reads a) Wikipedia on I/L b) Django 
on I/L, c) this thread. They will still not understand what those two 
settings do! 

@ Russell: I would not hesitate to help writing the documentation. But I 
simply don't know what those settings do. So I can't write it. (tragicomic 
smiley)

Lucy

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/d9ShQzQ7tnsJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Nested formsets at Django 1.3

[Kev Dwyer]

Kev Dwyer wrote:

> Hello List,
> 
> I've been upgrading an old Django 1.1.x app to use Django 1.3, and am
> having a problem with nested formsets.
> 
...
> 
> 
> 
I omitted one important fact in this write-up.  In Nathan's original code, 
the lowest level formset is created like this:

TenantFormset(data=self.data,
  instance=instance,
  prefix='TENANTS_%s' % pk_value)

where instance is an instance of Building, the "parent" or container 
for tenants and self is an instance of 

class BaseBuildingFormset(BaseInlineFormSet)

which is instantiated like this:

BuildingFormset = inlineformset_factory(models.Block,
models.Building,
formset=BaseBuildingFormset,
extra=1)

I omitted to mention that to get around this I stopped passing in self.data, 
which led to the behaviour that I described in my original post.  Apologies 
if this misled anyone.

Up to Django 1.2.5, Nathan's code works fine.  However at 1.3, if self.data 
is passed to TenantFormset, it turns out to be empty and a ValidationError 
is raised because the ManagementForm information has not been supplied.  
This is the intended consequewnce of #11418, AFAICT.

Working on the assumption that self.data should contain the 
ManagementForm data I've tried populating it with said data, but 
ValidationError is still raised.

My use case is slightly simpler than Nathan's example as I just need to edit 
existing objects, so I'm going to try populating the formsets using 
querysets rather than instances.

Does anyone have any other ideas on how this might be made to work?  

Cheers,

Kev

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: south vs nashvegas

[Shawn Milochik]

I never heard of Nashvegas until your e-mail, and I've been using South 
for years and it's been wonderful. I also met Andrew Godwin at DjangoCon 
last year, and he's a genuinely nice and friendly guy.


So, assume that I'm biased. Having said that, here are my responses:

South is definitely not complicated to use. The documentation is very 
good, and there aren't all that many features or options to memorize.


Nashvegas doesn't do backwards migrations at all and the database 
migrations they do have are database-specific. Those two things alone 
mean you can't confidently deploy to production knowing you can 
roll-back, and you can't reliably develop on one DB and deploy on 
another. Until that's corrected I don't see how Nashvegas is even an 
option except for personal projects where you don't care if you take the 
site down.


South has an active mailing list in which the core developer 
participates and is very helpful.


The only "feature" that Nashvegas claims that South doesn't handle is a 
whole project migration as opposed to individual apps. This is actually 
not true. South allows you to put a requirement line in a migration that 
indicates that it depends on a migration in another app. This, to me, is 
not only "the whole project" but more modular and therefore better.


If you're using a version control system and working with other 
developers, then any schema migrations, from raw SQL to South are going 
to require communication among your group. That's completely unavoidable.


Incidentally, if you do use South and run into trouble, try the South 
mailing list. I subscribe to it and will try to help out, if someone 
doesn't beat me to it.


Shawn

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Django 1.3 CreateView/ModelForm and dynamic filtering of fields

[Paul Walsh]

I am trying to filter a field on a ModelForm. I am subclassing the generic 
CreateView for my view. 

I found many references to my problem on the web, but the solutions do not 
seem to work (for me at least) with Django 1.3's class-based views.

Specifically, my users need to add Subscribers, and each Subscriber has a 
m2m field that assigns him/her to a SubscriberList. When the form to create 
a subscriber loads for a given user, I need to options in subscriber_list to 
be filtered for that user's lists only. 

Here are my models:

#models.py

class Subscriber(models.Model):

user = models.ForeignKey(User)
subscriber_list = models.ManyToManyField('SubscriberList')

class SubscriberList(models.Model):

user = models.ForeignKey(User)
name = models.CharField(max_length=70)

Here is my view:

#views.py

class SubscriberCreateView(AuthCreateView):
model = Subscriber
template_name = "forms/app.html"
form_class = SubscriberForm
success_url = "/app/subscribers/"
 def form_valid(self, form):
self.object = form.save(commit=False)
self.object.user = self.request.user
return super(SubscriberCreateView, self).form_valid(form) 



Here is my original form for adding a Subscriber, with no filter:

#forms.py

class SubscriberForm(ModelForm):
 class Meta:
model = Subscriber
exclude = ('user', 'facebook_id', 'twitter_id')

Here is my modified form, attempting to filter, but doesn't work:

#forms.py

class SubscriberForm(ModelForm):
 class Meta:
model = Subscriber
exclude = ('user', 'facebook_id', 'twitter_id')
 def __init__(self, user, **kwargs):
super(SubscriberForm, self).__init__(**kwargs)
self.fields['subscriber_list'].queryset = 
SubscriberList.objects.filter(user=user)
If I change this modified form as so:

def __init__(self, user=None, **kwargs)

It works - It brings me NO subscriber lists. But any way I try to pass the 
request user, for eg., def __init__(self, user=request.user, **kwargs), I 
invariably get a a name "request" or name "self" not defined error.

So, how can I modify my code to filter subscriber_list by the request.user, 
and still use Django 1.3's CreateView.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/fD7CoioGtgIJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

south vs nashvegas

[bobhaugen]

I'm about to start using a database migration tool on an existing
project.

(Yes, yes, I know, I am crazy for not having done so from the
beginning...)

So: south (the reigning champ) or nashvegas (the upstart)?

I respect the people working on nashvegas a lot, and figure they have
pretty good reasons for starting a new migration tool.  And south
seems more complicated (simpler is better, at least some of the
time...).

I read here 
http://www.issackelly.com/Blog/entry/On_Django_Migrations_South_vs_Nashvegas/
that "Much care has been made to make sure that you can start using
south on your app part-way through development, where Nashvegas should
really be used from the start.  Converting to Nashvegas with a team
requires though and planning, and with South, it requires one
management command from each person (per app)."

Still true?  (Things move fast in the Django world.)

Any other opinions, tips, warnings, gratefully received.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Broken INTERNAL links related to django.contrib.auth

[ivan.o...@googlemail.com]

I get a lot of 'broken internal links' mails daily from a Django
application I
am hacking: http://grical.org

They look like this::

Referrer: http://grical.org/accounts/login/e/show/580/
Requested URL: /accounts/login/e/show/
580/
User agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;
TheFreeDictionary.com; .NET CLR 1.1.4322; .NET CLR 1.0.3705;.NET
CLR
2.0.50727)
IP address: ...

Any idea where can be the problem?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: jquery

[veva...@yandex.ru]

Thank You! Now I see I don't understand how can I use static files
using the development server. I saw several answers to this question
of other people but they are too breaf for me.
Books on Django I have don't explain this problem. Be so kind to
explain me.
My local computer has Windows. The project folder is c:/djangomysites/
testjquery, it contains subfolders static and templates, static
contains subfolders images and js.
Today I changed Django 1.2.3 to Django 1.3. May I consider images for
simplicity. For the same reason I don't use os function here.

settings.py contains:
STATICFILES_DIRS = (
'c:/djangomysites/testjquery/static',
)
STATIC_ROOT=''
STATIC_URL='/static/'

urls.py contains:
urlpatterns = patterns('',
(r'^', 'testjquery.views.first'),
if settings.DEBUG:
urlpatterns += patterns('',
(r'^static/(?P.*)$', 'django.views.static.serve',
{ 'document_root': 'c:/djangomysites/testjquery/static' })

views.py contains:
def first(request):
return render_to_response('index.html',
context_instance=RequestContext(request))

index.html contains:

As a result, I get  in the
produced html-file. But the image file can't be loaded.
Thank You very much!

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Customizing Form Field HTML Attributes

[SixDegrees]

Thank you.


Stuart MacKay wrote:
> 
> Take a look at the widgets used to display a form. From the
> documentation: https://docs.djangoproject.com/en/dev/ref/forms/widgets/
> 
> "On a real Web page, you probably don't want every widget to look the
> same. You might want a larger input element for the comment, and you
> might want the 'name' widget to have some special CSS class. To do this,
> you use the Widget.attrs argument when creating the widget:
> 
> For example:
> 
> class CommentForm(forms.Form):
> name = forms.CharField(
> widget=forms.TextInput(attrs={'class':'special'}))
> url = forms.URLField()
> comment = forms.CharField(
>widget=forms.TextInput(attrs={'size':'40'}))"
> 
> Regards,
> 
> Stuart MacKay
> Lisbon, Portugal
> 
> 
>> 
>> I would like to use the 'title' attribute of several form fields to hold
>> our
>> help_text, rather than displaying the text alongside the field. I don't
>> see
>> any way, though, to add or modify tag attributes on a form field. How
>> would
>> I do this?
> 
> -- 
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
> 
> 
> 

-- 
View this message in context: 
http://old.nabble.com/Customizing-Form-Field-HTML-Attributes-tp32164210p32164300.html
Sent from the django-users mailing list archive at Nabble.com.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Customizing Form Field HTML Attributes

[Stuart MacKay]

Take a look at the widgets used to display a form. From the
documentation: https://docs.djangoproject.com/en/dev/ref/forms/widgets/

"On a real Web page, you probably don't want every widget to look the
same. You might want a larger input element for the comment, and you
might want the 'name' widget to have some special CSS class. To do this,
you use the Widget.attrs argument when creating the widget:

For example:

class CommentForm(forms.Form):
name = forms.CharField(
widget=forms.TextInput(attrs={'class':'special'}))
url = forms.URLField()
comment = forms.CharField(
   widget=forms.TextInput(attrs={'size':'40'}))"

Regards,

Stuart MacKay
Lisbon, Portugal


> 
> I would like to use the 'title' attribute of several form fields to hold our
> help_text, rather than displaying the text alongside the field. I don't see
> any way, though, to add or modify tag attributes on a form field. How would
> I do this?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Customizing Form Field HTML Attributes

[SixDegrees]

I would like to use the 'title' attribute of several form fields to hold our
help_text, rather than displaying the text alongside the field. I don't see
any way, though, to add or modify tag attributes on a form field. How would
I do this?
-- 
View this message in context: 
http://old.nabble.com/Customizing-Form-Field-HTML-Attributes-tp32164210p32164210.html
Sent from the django-users mailing list archive at Nabble.com.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: No modelue name localeurl ( ">_<)

[Andre Terra]

Then install them on your system's python environment, rather than a
virtual one. Tip: site-packages

On 7/31/11, Kase  wrote:
> oh,  im estupid,  i put the rosetta and transmeta in my  site path but
> not localeurl...
>
> but, i like to put in a generic path and not duplicate in every
> proyect =/
>
> On 31 jul, 03:43, Kase  wrote:
>> i  try  internationalization whit    transmeta,  localeurl and rosette
>>
>> transmetta and rosette works ok
>>
>> all  put in path  /usr/local/pytho27/site-pakage
>>
>> but localeurl dont work!
>>
>> manage.py runserver  trow    Error: No module named localeurl
>>
>> =/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>

-- 
Sent from my mobile device

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

django nani

[Vusal Alishov]

Hello, i've problem with django-nani, in admin panel ist of objects
don't shown.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: No modelue name localeurl ( ">_<)

[Kase]

oh,  im estupid,  i put the rosetta and transmeta in my  site path but
not localeurl...

but, i like to put in a generic path and not duplicate in every
proyect =/

On 31 jul, 03:43, Kase  wrote:
> i  try  internationalization whit    transmeta,  localeurl and rosette
>
> transmetta and rosette works ok
>
> all  put in path  /usr/local/pytho27/site-pakage
>
> but localeurl dont work!
>
> manage.py runserver  trow    Error: No module named localeurl
>
> =/

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

No modelue name localeurl ( ">_<)

[Kase]

i  try  internationalization whittransmeta,  localeurl and rosette

transmetta and rosette works ok

all  put in path  /usr/local/pytho27/site-pakage

but localeurl dont work!

manage.py runserver  trowError: No module named localeurl

=/

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: upgrade Django 1.2.3 to 1.3

[veva...@yandex.ru]

Thank You very much, Kev !!!
You helped me.
Vladimir Vanin

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: upgrade Django 1.2.3 to 1.3

[Kev Dwyer]

veva...@yandex.ru wrote:

> After upgraging I entered python manage.py runserver and got error
> messages:
> File "manage.py", line 11, in 
> execute_manager(settings)
> File "c:\python26\lib\site-packages\django\core\management
> \__init__.py", line 438, in execute_manager
> utility.execute()
> File c:\python26\lib\site-packages\django\core\management
> \__init__.py", line 379, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
> File "c:\python26\lib\site-packages\django\core\management
> \__init__.py", line 261, in fetch_command
> klass=load_command_class
> module=import_module('%s.management.command.%s' % (app_name, name))
> File "c:\python26\lib\site-packages\django\utils\importlib.py, line
> 35, in import_module
> __import__(name)
> File "c:\python26\lib\site-packages\django\core\management\command
> \runserver.py",line 8, in 
> from django.core.handlers.wsgi import WSGIHandler
> File "c:\python26\lib\site-packages\django\core\handlers\wsgi.py",
> line 11, in 
> from django.dispatch import Signal
> File "c:\python26\lib\site-packages\django\dispatch\__init__.py", 
line
> 9, in 
> from django.dispatch.dispatcher import Signal, receiver
> ImportError: cannot import name receiver
> 
> Could you point to my mistake? Many thanks!
> 


See http://stackoverflow.com/questions/4883802/problem-with-django-1-3-
beta.

In your case your using Windows rather than Linux, but the same advice 
applies - remove the django folder (and any django eggs) from the 
c:\python26\lib\site-packages folder and re-install 1.3.  Or use 
virtualenv to maintain separate environments.

Cheers,

Kev

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.