Re: tutorial site refers to a module which does not exist

[knbk]

Hi,

What version of Django are you using? Starting in 1.9, the startapp command 
definitely creates an apps.py with a PollsConfig class, so you're likely 
using an older version of Django. 

You can either upgrade Django to 1.11 or use the tutorial for whichever 
version you have installed.

Marten

On Saturday, November 4, 2017 at 11:01:15 PM UTC+1, Kyle Foley wrote:
>
> I'm trying to teach myself Django on this site:
>
> https://docs.djangoproject.com/en/1.11/intro/tutorial02/
>
> If you look at this sentence:
>
> To include the app in our project, we need to add a reference to its 
> configuration class in the INSTALLED_APPS 
> 
>  setting. 
> The PollsConfig class is in the polls/apps.py file, so its dotted path is 
> 'polls.apps.PollsConfig'.
>
> They haven't told me what the pollsconfig class consists in, nor have they 
> told me to build the apps.py module.  When I run the command line
>
> python manage.py makemigrations polls
>
> ModuleNotFoundError: No module named 'polls.apps.PollsConfig'; 
> 'polls.apps' is not a package
>
>
> So what am I supposed to put in that module?
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/a2b5122d-18c4-4f32-8d97-ca9c1fe87f1d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Is CSRF middleware to be taken seriously (from a XSRF point of view)?

[knbk]

Hi Steve,

First let's get into how cross-site request forgery works: when you are 
logged in to bank.com, your browser saves a session cookie and sends it 
with every request. Now when you visit evil.com, they may include a piece 
of javascript in their side that sends a POST request to bank.com/transfer/ 
to transfer $1000 from your account into theirs. Your browser executes the 
javascript, and happily sends a request to bank.com/transfer/ along with 
the transfer details and your session cookie. The session cookie 
authenticates the request as coming from you, so the bank has no reason to 
suspect that you didn't want to transfer the money. The issue here is that 
your browser sends the session cookie with *every *request. 

Django uses a so-called double submit cookie[1] to protect against CSRF 
attacks. This is a well-documented pattern for CSRF protection. In addition 
to the session cookie, a CSRF token cookie is set in the browser. This 
contains a randomly generated value that is unique to your browser. This 
value is also included as a form field (or a request header) in any POST 
request you make. When you send a request, Django checks if the two values 
are the same. If they are, then that proves (up to a point) that the 
request is from a party that has legitimate access to the token value. 
Barring any more extensive attacks (such as cross-site scripting), evil.com 
has no way to get the correct value of the CSRF token. Javascript executed 
on evil.com has no access to the cookies for bank.com, and opening a page 
from bank.com in e.g. an iframe also disallows access to the content of 
that iframe. Only a legitimate party (i.e. you filling in a form on 
bank.com) has access to the correct token and can submit the same secret as 
the one in the CSRF token cookie. 

As for the "cipher algorithm", this is actually just a padding algorithm to 
make the value randomized on each page load, while keeping the secret the 
same. You are right that anyone can reverse this, but that is not an issue. 
Randomizing the value prevents a class of attacks that includes BEAST, 
CRIME and BREACH attacks. These attacks work by injecting a value into the 
page in close proximity to the CSRF token (i.e. when a page displays a GET 
parameter) and seeing what effect it has on the compression of that page. 
If the compressed page becomes shorter, then the injected value likely has 
some values in common with the CSRF token. This allows for recovery of the 
secret token byte-by-byte, so that evil.com can bypass the CSRF protection 
in place. Randomizing the value, even if the original value is easily 
recovered, prevents this class of attacks entirely. 

I hope this gives you a better understanding of how CSRF protection works 
in Django. If you have any more questions feel free to ask here or on IRC 
(nick: knbk).

Marten


[1] 
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Double_Submit_Cookie

On Monday, January 15, 2018 at 11:03:22 PM UTC+1, Stephan Doliov wrote:
>
> Just curious, I recently went on a source code studying binge and took a 
> look at the CSRF middleware that comes with Django. I appreciate the work 
> and effort of the authors, but I am not sure I gain anything by deploying 
> it to my site. Here is why:
> The middleware token assigned to a form and to a csrftoken cookie are 
> ciphertexts of the same underlying key (by default, the underlying key is 
> chosen as 32 randomly chosen (with replacement) chars from a set of 62 
> chars. So the easy workaround can be done in one of two ways
>
> 1) Write a script that just harvests the middleware token from a form 
> "protected" with such token and use the value of that as the csrftoken 
> cookie.
> As the middlewaretoken is a cipher of the underlying token, obviously 
> using the the same string as the value to the csrftoken cookie will satisfy 
> the middleware's demand for authorization of the resource (e.g. POSTing to 
> the form)
>
> 2) Learn the easy cipher algorithm the csrf middleware uses and present a 
> csrf token cookie that will decode to the right value.
>
> In either case, I am not convinced that meaningful protection against CSRF 
> types of requests are provided by the middleware. Am I missing something?
>
> Wouldn't it be more secure to just have middleware that whitelists as a 
> series of origins (aka CORS) and then, unlike CORS, actually perform 
> reverse lookups on the dns of the whitelisted domains? (Of course, this 
> assumes that the hosts that might want to make cross-site requests ahve 
> access to managing their reverse DNS).
>
> Am I missing something; or, if serving performance is a top goal of mine, 
> should I just ditch the csrf middleware? (and maybe rate limit client 
> requests to prevent DoS attacks)?
>
> Thanks,
> Steve
>

Re: Is CSRF middleware to be taken seriously (from a XSRF point of view)?

[knbk]

How does using nginx protect against CSRF attacks?

Marten

On Tuesday, January 16, 2018 at 10:49:21 AM UTC+1, Etienne Robillard wrote:
>
> A much more practical way to improve security against XSRF attacks is 
> using nginx.
>
> Regards,
>
> Etienne
>
> Le 2018-01-16 à 04:38, James Bennett a écrit :
>
> If you can demonstrate a practical attack against Django's CSRF system, 
> feel free to email it to secu...@djangoproject.com .
>
> On Tue, Jan 16, 2018 at 1:26 AM, Etienne Robillard  > wrote:
>
>> Hi Stephan,
>>
>> I'm also interested to understand why I should have some form of CSRF 
>> protection for my wsgi app... 
>>
>> perhaps recoding the Django 1.11 CSRF middleware into a proper WSGI 
>> application (CSRFController) would help.
>>
>> but seriously, i don't use/recommend the Django CSRF middleware because 
>> it does not improve security of forms processing. 
>>
>>
>> cheers,
>>
>> Etienne
>>
>>
>>
>> Le 2018-01-15 à 17:03, Stephan Doliov a écrit :
>>
>> Just curious, I recently went on a source code studying binge and took a 
>> look at the CSRF middleware that comes with Django. I appreciate the work 
>> and effort of the authors, but I am not sure I gain anything by deploying 
>> it to my site. Here is why: 
>> The middleware token assigned to a form and to a csrftoken cookie are 
>> ciphertexts of the same underlying key (by default, the underlying key is 
>> chosen as 32 randomly chosen (with replacement) chars from a set of 62 
>> chars. So the easy workaround can be done in one of two ways
>>
>> 1) Write a script that just harvests the middleware token from a form 
>> "protected" with such token and use the value of that as the csrftoken 
>> cookie.
>> As the middlewaretoken is a cipher of the underlying token, obviously 
>> using the the same string as the value to the csrftoken cookie will satisfy 
>> the middleware's demand for authorization of the resource (e.g. POSTing to 
>> the form)
>>
>> 2) Learn the easy cipher algorithm the csrf middleware uses and present a 
>> csrf token cookie that will decode to the right value.
>>
>> In either case, I am not convinced that meaningful protection against 
>> CSRF types of requests are provided by the middleware. Am I missing 
>> something?
>>
>> Wouldn't it be more secure to just have middleware that whitelists as a 
>> series of origins (aka CORS) and then, unlike CORS, actually perform 
>> reverse lookups on the dns of the whitelisted domains? (Of course, this 
>> assumes that the hosts that might want to make cross-site requests ahve 
>> access to managing their reverse DNS).
>>
>> Am I missing something; or, if serving performance is a top goal of mine, 
>> should I just ditch the csrf middleware? (and maybe rate limit client 
>> requests to prevent DoS attacks)?
>>
>> Thanks,
>> Steve
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-users...@googlegroups.com .
>> To post to this group, send email to django...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/django-users.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-users/9c4a794f-aa9e-4c00-ba20-779ad7a87d2a%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> -- 
>> Etienne robillardtka...@yandex.com 
>> https://www.isotopesoftware.ca/
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-users...@googlegroups.com .
>> To post to this group, send email to django...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/django-users.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-users/95bba86c-ed2e-fd8d-e7da-2ec1b80c273c%40yandex.com
>>  
>> .
>>  
>>
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-users...@googlegroups.com .
> To post to this group, send email to django...@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-users/CAL13Cg9mhBTD-2CBB46cvv2N6gd0JzHA8g5o%2BgrG5ZrAmb-%3Dgg%40mail.gmail.com
>  
> 

Re: Is CSRF middleware to be taken seriously (from a XSRF point of view)?

[knbk]

That does seem to be a good effort towards CSRF prevention. However, it's 
currently in draft status, and doesn't provide any protection if not 
supported by your browser. According to caniuse.com[1], the browsers 
supporting this feature currently occupy just under 60% of the browser 
market. About 40% of users would still be vulnerable to CSRF attacks. IMO 
that's too large a chunk of users to leave unprotected. 

When this feature reaches maturity it will likely be a good option to 
combat CSRF, but right now it doesn't provide adequate protection on its 
own. Django's CSRF middleware does provide protection for the remaining 
40%. 

Marten


[1] https://caniuse.com/#search=samesite

On Tuesday, January 16, 2018 at 6:19:17 PM UTC+1, Etienne Robillard wrote:
>
> See this: https://www.owasp.org/index.php/SameSite
>
> Cheers,
>
> Etienne
>
> Le 2018-01-16 à 10:36, knbk a écrit :
>
> How does using nginx protect against CSRF attacks?
>
> Marten
>
> On Tuesday, January 16, 2018 at 10:49:21 AM UTC+1, Etienne Robillard 
> wrote: 
>>
>> A much more practical way to improve security against XSRF attacks is 
>> using nginx.
>>
>> Regards,
>>
>> Etienne
>>
>> Le 2018-01-16 à 04:38, James Bennett a écrit :
>>
>> If you can demonstrate a practical attack against Django's CSRF system, 
>> feel free to email it to secu...@djangoproject.com.
>>
>> On Tue, Jan 16, 2018 at 1:26 AM, Etienne Robillard  
>> wrote:
>>
>>> Hi Stephan,
>>>
>>> I'm also interested to understand why I should have some form of CSRF 
>>> protection for my wsgi app... 
>>>
>>> perhaps recoding the Django 1.11 CSRF middleware into a proper WSGI 
>>> application (CSRFController) would help.
>>>
>>> but seriously, i don't use/recommend the Django CSRF middleware because 
>>> it does not improve security of forms processing. 
>>>
>>>
>>> cheers,
>>>
>>> Etienne
>>>
>>>
>>>
>>> Le 2018-01-15 à 17:03, Stephan Doliov a écrit :
>>>
>>> Just curious, I recently went on a source code studying binge and took a 
>>> look at the CSRF middleware that comes with Django. I appreciate the work 
>>> and effort of the authors, but I am not sure I gain anything by deploying 
>>> it to my site. Here is why: 
>>> The middleware token assigned to a form and to a csrftoken cookie are 
>>> ciphertexts of the same underlying key (by default, the underlying key is 
>>> chosen as 32 randomly chosen (with replacement) chars from a set of 62 
>>> chars. So the easy workaround can be done in one of two ways
>>>
>>> 1) Write a script that just harvests the middleware token from a form 
>>> "protected" with such token and use the value of that as the csrftoken 
>>> cookie.
>>> As the middlewaretoken is a cipher of the underlying token, obviously 
>>> using the the same string as the value to the csrftoken cookie will satisfy 
>>> the middleware's demand for authorization of the resource (e.g. POSTing to 
>>> the form)
>>>
>>> 2) Learn the easy cipher algorithm the csrf middleware uses and present 
>>> a csrf token cookie that will decode to the right value.
>>>
>>> In either case, I am not convinced that meaningful protection against 
>>> CSRF types of requests are provided by the middleware. Am I missing 
>>> something?
>>>
>>> Wouldn't it be more secure to just have middleware that whitelists as a 
>>> series of origins (aka CORS) and then, unlike CORS, actually perform 
>>> reverse lookups on the dns of the whitelisted domains? (Of course, this 
>>> assumes that the hosts that might want to make cross-site requests ahve 
>>> access to managing their reverse DNS).
>>>
>>> Am I missing something; or, if serving performance is a top goal of 
>>> mine, should I just ditch the csrf middleware? (and maybe rate limit client 
>>> requests to prevent DoS attacks)?
>>>
>>> Thanks,
>>> Steve
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Django users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to django-users...@googlegroups.com.
>>> To post to this group, send email to django...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/django-users.
>>> To view this discussion on the web visit 
>&g

Re: (Another) Authentication Question

[knbk]

Hi Jason,

Your form inputs in the login form are missing a name attribute, so the 
data you input into the form won't be sent to the server on submit. Without 
any data, the form is invalid, and is redisplayed. If you add the correct 
name attribute to the input tags, your form should work as expected.

Marten

On Thursday, April 21, 2016 at 1:25:53 PM UTC+2, Jason Wolosonovich wrote:
>
> Hello All, 
>
> I'm completely new to Django and I've been following along with the 
> excellent video series from CodingEntrepreneurs on YouTube and applying 
> what I can to my project. I'm stuck on the authentication process. I don't 
> believe that the request is being passed to my template correctly because 
> in the template, I'm checking for authentication and if present, I'm 
> displaying the content (or trying to anyway) and if not, I'm rendering a 
> message informing the user that they're not logged in. 
>
> my app is title 'theapp' and I have a single view called 'index' that is 
> decorated with '@login_required' and redirecting to '/accounts/login'. I 
> have two users, both of which I created and activated. When I enter 
> credentials, I'm redirected right back to the login page. My view is pretty 
> simple: 
>
>
> def index(request): 
> return render(request, 'index.html', {}) 
>
>
> If my project is called 'thesite', in 'thesite/urls.py' I have these 
> patterns: 
>
>
>
> urlpatterns = [ 
>
> url(r'^theapp/', 
> include('theapp.urls')), 
>
> url(r'^admin/', 
> admin.site.urls), 
>
> url(r'^login/$', 
> 'django.contrib.auth.views.login', 
> {'template_name': 'login.html'}, 
> name='login') 
>
> ] 
>
>
>
>
>
>
>
> In my app urls ('theapp/urls.py') I have this pattern: 
>
>
>
>
>
>
> urlpatterns = [ 
> url(r'^$', 
> views.index, 
> name='index'), 
>
> ] 
>
>
>
>
>
>
> My 'base' form is like so: 
>
>
>
>
>
>
> http://getbootstrap.com/favicon.ico";> 
>
> Login 
>
>  
> http://getbootstrap.com/dist/css/bootstrap.min.css"; 
> rel="stylesheet"> 
>
>  
> http://getbootstrap.com/assets/css/ie10-viewport-bug-workaround.css"; 
> rel="stylesheet"> 
>
>  
> http://getbootstrap.com/examples/signin/signin.css"; 
> rel="stylesheet"> 
>
>  
>  
>
>
> 

Re: [django1.9] Url template tag, dotted path and decorator

[knbk]

In order to reverse a view by its dotted path, Django needs to know the 
actual path of the function. It uses the magic view.__module__ and 
view.__name__ attributes to determine the name. If your decorator doesn't 
copy these attributes from the inner function to the decorated function, 
Django doesn't know the path to the original function, and you can't 
reverse by dotted path.

As mentioned by Camilo, you can use functools.wraps() to fix this issue. 

On Sunday, April 24, 2016 at 3:54:20 AM UTC+2, Camilo Torres wrote:
>
> On Saturday, April 23, 2016 at 1:17:26 PM UTC-4:30, François Magimel wrote:
>>
>> Hi! 
>>
>> I'm facing an issue reversing a dotted path with django 1.9.4. Here are 
>> more details. 
>>
>> I pass a dotted path to the django template tag "url": 
>> "{% url 'my.app.view.func' arg %}" 
>> And the function "my.app.view.func" has a decorator which is using "arg". 
>> My problem is : when displaying my template, I get a NoReverseMatch error. 
>> But I don't have any error: 
>>   - when I use the name of the url (defined in my urls.py file) or 
>>   - when I use the dotted path and remove my (simple) decorator. 
>>
>> I know that passing a dotted path to url is deprecated since django 1.8 
>> [0][1], but not removed yet. So, I think there is something wrong with 
>> dotted path and decorators, but I can't find what… 
>>
>> PS: my decorator only redirects to another view… 
>>
>> Thanks, 
>> François 
>>
>>
>> [0] 
>> https://docs.djangoproject.com/en/1.8/releases/1.8/#passing-a-dotted-path-to-reverse-and-url
>>  
>> [1] https://docs.djangoproject.com/en/1.8/ref/templates/builtins/#url 
>>
>
> Hi,
> May be you can use functools.wraps from Python standard library.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/17117f55-47ee-4fe8-9550-b9d9f9650c9b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: New to Django (stuck at the end of the tutorial)

[knbk]

Since 1.9, admin.site.urls is a special case, and you should not use 
include(). If you do, you'll trigger some deprecation warnings due to 
changes to include().
 
On Tuesday, April 26, 2016 at 6:33:40 PM UTC+2, Nikhil Beniwal wrote:
>
> The Problem is in your line 21. 
>
> admin.site.urls should be wrapped inside include like :-
>
> url(r'^admin/', include(admin.site.urls)),
>
> On Tuesday, April 26, 2016 at 1:03:09 PM UTC+5:30, Cronos Cto wrote:
>>
>>
>> Hello Django Lovers.
>>
>> So I started on Django as project of mine. Seems like a great first 
>> framework to start on. At the moment I am stuck at this:
>>
>>
>>
>> 
>> This was after what I encountered at the end of the Django oficial post 
>> app tutorial.
>>
>> I tried several ways to solve it. The problem seems to lay in the url.py 
>> file, but I can not seem to solve it.
>>
>>
>> 
>>
>> Thank you to anyone that can help me solve it.
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/88fb3e35-1bd0-4070-ab02-1683263273a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Strange named parameter passing style

[knbk]

Python 2 does not support named arguments after *fields, and raises a 
SyntaxError. As long as Django supports Python 2, we're stuck with the 
current approach. I'm sure the new style will be used once Python 2 support 
is dropped.

On Thursday, December 15, 2016 at 1:40:02 PM UTC+1, Alexey Gerasimov wrote:
>
>
> Why "flat" keyword is accepted that way? Why not just as def 
> values_list(self, *fields, flat=False)? Because of that I cannot have 
> support in my IDE (autocomplete)
>
> def values_list(self, *fields, **kwargs):
> flat = kwargs.pop('flat', False)
> if kwargs:
> raise TypeError('Unexpected keyword arguments to values_list: 
> %s' % (list(kwargs),))
>
> if flat and len(fields) > 1:
>raise TypeError("'flat' is not valid when values_list is 
> called with more than one field.")
>
> _fields = []
> expressions = {}
>
> for field in fields:
>if hasattr(field, 'resolve_expression'):
>field_id = str(id(field))
>expressions[field_id] = field
>_fields.append(field_id)
>else:
>_fields.append(field)
>
> clone = self._values(*_fields, **expressions)
> clone._iterable_class = FlatValuesListIterable if flat else 
> ValuesListIterable
> return clone
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/c35a620c-e864-446c-99fc-93d8af407943%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Questions on Django queryset iterator - wrt select_related and prefetch_related and how it works

[knbk]

Django uses client-side cursors. 1.11, which is currently in beta, switches 
to server-side cursors on PostgreSQL [1], but other databases still use 
client-side cursors. When a client-side cursor executes a query, it loads 
all results in memory before the results can be accessed.

But that's just the raw results. Without iterator(), these raw results are 
immediately converted to model instances, and related objects that have 
been loaded with select_related() or prefetch_related are converted to 
model instances as well. This can cause a spike in CPU and memory usage. 
When using iterator(), most of the CPU usage is in the database itself, and 
the raw results use quite a bit less memory than model instances. The CPU 
resources needed to convert the raw results to model instances is spread 
out in the loop iterations, and the model instances can in most situations 
be garbage-collected after the iteration moves on the next instance. 


[1] https://docs.djangoproject.com/en/1.11/releases/1.11/#database-backends 
(third item)

On Friday, March 17, 2017 at 10:47:57 AM UTC+1, Web Architect wrote:
>
> Hi,
>
> Thanks for your response. But I have observed the following:
>
> Without Iterator: It takes a bit of a time before the for loop is executed 
> and also the CPU spikes up during that period and so does the Memory - 
> which implies the DB is accessed to fetch all the results.
>
> With iterator: The for loop execution starts immediately and the memory 
> usage is also low. This probably implies that not all the results are 
> fetched with a single query. 
>
> Based on what you have mentioned, I am not sure how to understand the 
> above behaviour. 
>
> Thanks,
>
> On Friday, March 17, 2017 at 11:27:52 AM UTC+5:30, Shawn Milochik wrote:
>>
>> I think the benefit of using the iterator is best explained by an example:
>>
>> Without iterator:
>>
>> You loop through the queryset, using each item for  whatever you're 
>> doing. As you do this, all the items are now in your local scope, using up 
>> RAM. If, after the loop, you should want to loop through the data again, 
>> you can. Upside: Can re-use the data. Downside: memory usage.
>>
>> With iterator:
>>
>> You loop through the queryset, using each item for  whatever you're 
>> doing. As you do this, read items are garbage-collected. If you want to 
>> loop through the data again, you'll have to hit the database again. Upside: 
>> Memory usage.
>>
>>
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/9bc7ce18-6b20-4329-8479-20f02f3c6c8a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ORM for structured Logs

[knbk]

Hi Thomas,

The primary purpose of logging is to catch and examine errors. If something 
went wrong, you want to know *when *and *why*. Logging to a database 
increases the complexity and greatly increases the number of things that 
can go wrong. The last thing you want to find out when retracing an error 
is that you don't have any logs because the logging system failed. You may 
also need to log errors that happened during startup, before a database 
connection can be established. Logging to file is the simplest method, and 
has the least chance of failure. That's why you should always log to file. 

The two options are not mutually exclusive. Like you said, times have 
changed, and the overhead to store logs both in a file and in a database 
are nowadays acceptable. If you have a good reason to store the logs in a 
database, then go ahead. Just remember that it should be *in addition to 
*file-based 
logging. 

Kind regards,

Marten

On Tuesday, April 4, 2017 at 2:18:42 PM UTC+2, guettli wrote:
>
> In the past I was told: Don't store logs in the database.
>
> Time (and hardware) has changed.
>
> I think it is time to store logs where I have great tools for analyzing 
> logs.
>
> Storing in a model which I can access via django orm is my current 
> strategy.
>
> It seems no one has done this before. I could not find such a project up 
> to now.
>
> My first draft looks like this:
>
>
> class Log(models.Model):
> datetime=models.DateTimeField(default=datetime.datetime.now, 
> db_index=True)
> data=jsonfield.JSONField()
> host=models.CharField(max_length=256, default='localhost', db_index=True)
> system=models.CharField(max_length=256, default='', db_index=True)
>
> I am missing two things:
>
>  Missing1: Log level: INFO, WARN, ...
>
>  Missing2: A way to store exceptions.
>
>
> What do you think?
>
> What's wrong with this, what could be improved?
>
> Regards,
>   Thomas Güttler
>
>
>
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/21746446-93c7-40d7-b2fa-6adaad9f4aee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: vs {{ form }}

[knbk]

On Tuesday, May 16, 2017 at 9:51:07 AM UTC+2, guettli wrote:
>
>
> This is a basic fact, and AFAIK this basic question is not solved yet.
>
> {{ form }}  *  vs   * {{ form }}
>

That question is actually answered by the documentation 

:


>- For flexibility, the output does *not* include the  and 
> tags, nor does it include the  and  tags or an 
> tag. It’s your job to do that.
>
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/ee89870f-368d-4b90-8569-2a0e34071e2f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Same tutorial different day

[knbk]

You should move the `polls/` subdirectory to the outer `mysite/` directory, 
rather than the inner `mysite/mysite/` directory. The tutorial does 
actually say this, but admittedly it's easy to miss:

Your apps can live anywhere on your Python path 
> . In this 
> tutorial, we’ll create our poll app right next to your manage.py file so 
> that it can be imported as its own top-level module, rather than a 
> submodule of mysite.


 You don't need to `import polls` in your urls.py, since it doesn't 
actually use the `polls` module, it only has a string reference to that 
module. Django takes care of importing whatever you pass to `include()` if 
it's a string reference. 

On Tuesday, June 6, 2017 at 3:51:18 AM UTC+2, kit...@gmail.com wrote:
>
> I was attempting the tutorial titled "Writing your first Django app".  The 
> tutorial appears to be very simple, but it does not seem to work.  I have 
> frustrated myself by attempting to do it from scratch after failing last 
> week.  If I could get this app to work I could fix the tutorial for you. 
>  It looks like a lot of people have similar gripes about the directions not 
> working.
>
> I get errors like ModuleNotFoundError: No module named 'polls'
>
> my directory structure looks like this : 
>
> /home/me/parent/mysite/
>db.sqlite3
>manage.py
>mysite/
>
> /home/me/parent/mysite/mysite/
>__init__.py
>polls/
>settings.py
>urls.py
>wsgi.py
>
> the content of urls.py is : 
>
> from django.conf.urls import include, url
>
> from django.contrib import admin
>
>
> urlpatterns = [
>
> url(r'^polls/', include('polls.urls')),
>
> url(r'^admin/', admin.site.urls),
>
> ]
>
>
> /home/me/parent/mysite/mysite/polls/
>__init__.py
>admin.py
>apps.py
>migrations
>models.py
>tests.py
>urls.py
>views.py
>   
> the content of urls.py is : 
>
> from django.conf.urls  import url
>
>
> from . import views
>
>
> urlpatterns = [
>
> url(r'^$', views.index, name='index'),
>
> ]
>
>
>
>
> the content of views.py is : 
>
>
> from django.shortcuts import render
>
> from django.http import HttpResponse
>
>
>
> # Create your views here.
>
>
> def index(request):
>
> return HttpResponse("Hello, Mothers Fuckers!  You're at the polls 
> index!")
>
>
>
> So can somebody please tell me why I get ModuleNotFoundError: No module 
> named 'polls'.
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/4a9e3c66-2369-4493-a2e7-0efbc3ba54dd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: A lot of Problems with Migrating (conceptual)

[knbk]

There are various reasons why you should never execute queries at startup. 
One you've seen: it makes it impossible to migrate a new database. Other 
reasons include that the choices are cached and are only renewed when the 
server restarts, and that when running tests, the query is executed before 
the test database is set up and will run on the main database. 

The solution in this case is to use a ModelChoiceField[1], i.e.:

category = forms.ModelChoiceField(queryset=Category.objects.all(), 
required=False)

This allows to pass in a queryset which is evaluated whenever the field is 
used to make sure the values are up-to-date. Since querysets are lazy, this 
won't execute any queries on startup. 

[1] 
https://docs.djangoproject.com/en/1.11/ref/forms/fields/#modelchoicefield

On Saturday, August 19, 2017 at 12:14:48 AM UTC+2, subaru_87 wrote:
>
> Here’s a “problem” with migrations that I’ve had. It only occurs on a 
> first time installation (like a first-time upload to Heroku, for example).
>
> In forms.py, I have a field dependent upon a column in another table 
> (Category):
> category = forms.TypedChoiceField(required=False, choices=[(
> category.pk, category.name) for category in Category.objects.all()])
>
> Running makemigrations or migrate if there’s no pre-existing database with 
> a table named “Category” gives an error saying as much. However, I’m 
> expecting migrate to create the tables required. Therefore, it’s a 
> catch-22. 
>
> Of course, the “easy” answer is to comment out the above code, add in:
>  category = forms.CharField(max_length=12) 
> And run the initial migrations. Then, turn around and comment out that 
> same code, uncomment the real code shown above, and run migrations again. 
> It works, but it seems a bit awkward.
>
> Has anyone else had this issue? Or am I doing something wrong?
>
> Thanks much,
> Jim Illback
>
>
> On Aug 18, 2017, at 1:21 AM, James Bennett  > wrote:
>
> On Thu, Aug 17, 2017 at 1:03 PM, Antonis Christofides <
> ant...@djangodeployment.com > wrote:
>
>> Second, just to make things clear, the word "migration" has two meanings. 
>> The original meaning of migration is to switch to another software system 
>> (e.g. migrate from MySQL to PostgreSQL, or migrate a repository from 
>> subversion to git). In Django, the term "migration" means something else: 
>> to update the database to the new schema. In my opinion this terminology is 
>> wrong and confusing (apparently it comes from Ruby on Rails, but I'm not 
>> certain), and a better one would have been "dbupdate" or something, but 
>> since it's migration we'll keep it and you'll have to understand which 
>> meaning is meant in each case.
>>
>
> An important thing worth knowing is that Django's migration framework does 
> *not* only track the database schema. It also tracks the state of the 
> Python classes which define the models, including options which do not 
> affect the underlying DB schema, and making such changes to a model will 
> create the need for a migration.
>
> This is absolutely necessary, though, because the migration framework 
> generates a frozen snapshot of the state at each migration, so that you can 
> access the ORM to do things like data updates via the RunPython migration 
> operator. If you were to change, say, the default ordering of a model 
> without also generating a migration to record that change (even though it 
> has no effect on the database schema), you could run into trouble if you 
> later removed a field referenced by the old ordering, since one of the 
> intermediate ORM snapshots would attempt to order queries by a 
> now-nonexistent column.
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-users...@googlegroups.com .
> To post to this group, send email to djang...@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-users/CAL13Cg_0p1pMtMR2y2eGry1UhQaSRpswntcnMWtHNdPgV1Ph9w%40mail.gmail.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/d878688d-00a3-452d-8cb8-956dcf41a52e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: List of available Jinja2 global symbols

[knbk]

I don't believe there's a list in the documentation, but you can get them 
from the source code at 
https://github.com/django/django/blob/master/django/template/backends/jinja2.py#L66
:

if request is not None:
context['request'] = request
context['csrf_input'] = csrf_input_lazy(request)
context['csrf_token'] = csrf_token_lazy(request)

On Sunday, November 22, 2015 at 1:17:59 PM UTC+1, JirkaV wrote:
>
> Hi there, I'm not a Jinja2 user, but standard Django templates get these 
> variables via context processors‎. Check out 
> https://docs.djangoproject.com/en/1.8/topics/templates/#context-processors
>
>  HTH
>
>Jirka
>
> *From: *Patrick Spencer
> *Sent: *neděle, 22. listopadu 2015 5:45
> *To: *Django users
> *Reply To: *django...@googlegroups.com 
> *Subject: *List of available Jinja2 global symbols
>
> I'm using Django 1.8.6 with the built in JInja2 support. I spent a while 
> trying to figure out how to pass a csrf token to a JInja2 template. After a 
> while I realized one could just write {{ csrf_token }} in the template, 
> without passing this value through a view, and it would just print out the 
> token. I also realized you could reference a request object without passing 
> it through the view i.e. {{ request.user }} returns the current user. Is 
> there a place in the documentation with all the available global symbols 
> one can use in a Jinja2 template?
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-users...@googlegroups.com .
> To post to this group, send email to django...@googlegroups.com 
> .
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-users/537bd366-180e-4876-8b91-5791f8e22d44%40googlegroups.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/3841c96b-9adc-465a-8a8a-a611571b792a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: AttributeError: 'RegexURLResolver' object has no attribute '_urlconf_module'

[knbk]

Python 3 displays the original exception alongside the new exception when a 
new exception occurs in an except block. The AttributeError is expected, so 
this doesn't tell you anything about what goes wrong. The second error 
occurs when importing `self.urlconf_name`. The traceback should point you 
to the exact cause of this second error, that's the error you will have to 
solve to resolve this issue. 

On Monday, November 23, 2015 at 1:07:29 PM UTC+1, KwangYoun Jung wrote:
>
> Did you solve the issue?
>
> On Tuesday, July 2, 2013 at 8:14:00 PM UTC+9, Pratik Mandrekar wrote:
>>
>> Hello,
>>
>>
>> I keep getting the error *AttributeError: 'RegexURLResolver' object has 
>> no attribute '_urlconf_module' *and the only trace available is as shown 
>> below:
>>
>> 'RegexURLResolver' object has no attribute '_urlconf_module'
>>
>> My Sentry Error reporting normally shows the above error along with 
>> another error, both of which seem to happen simultaneously
>>
>>
>> django.core.urlresolvers in urlconf_module 
>> 
>>
>> AttributeError: 'RegexURLResolver' object has no attribute 
>> '_urlconf_module'
>>
>>
>> The trace for which is
>>
>>
>>
>>1. 
>>
>> @property
>>
>>2. 
>>
>>def urlconf_module(self):
>>
>>3. 
>>
>>try:
>>
>>4. 
>>
>>return self._urlconf_module
>>
>>5. 
>>
>>except AttributeError:
>>
>>6. 
>>
>>self._urlconf_module = import_module(self.urlconf_name)
>>
>>7. 
>>
>>return self._urlconf_module
>>
>>8. 
>>
>>9. 
>>
>>@property
>>
>>
>>
>> 'self'
>>
>> 
>>
>>
>> I'm on Django 1.4. I have been unable to debug this for weeks. Any help 
>> would be appreciated. 
>>
>>
>> Thanks,
>>
>> Pratik
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/5a1ab7e7-16cd-4c54-8ad1-ce3978813682%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Problem with login and register form

[knbk]

It's a good idea to use render() instead of render_to_response(), 
see https://docs.djangoproject.com/en/1.8/topics/http/shortcuts/#render. 
That will fix the issue with the CSRF token. render() takes the request as 
the first argument, and uses a RequestContext. This is needed to run the 
context processors, which add the csrf_token to the template. 

On Wednesday, November 25, 2015 at 7:05:26 PM UTC+1, Dariusz Mysior wrote:
>
> Hmm I forget about it but I change names on form_l and form_r and effect 
> is the same, I had also info
>
>
> C:\Python34\lib\site-packages\django\template\defaulttags.py:66: 
>> UserWarning: A {% csrf_token %} was used in a template, but the context did 
>> not provide the value.  This is usually cause
>> d by not using RequestContext.
>>   "A {% csrf_token %} was used in a template, but the context "
>>
>>
> W dniu wtorek, 24 listopada 2015 21:34:30 UTC+1 użytkownik Dariusz Mysior 
> napisał:
>>
>> Hi I had a problem with display a form of login and register, please look 
>> on it.
>>
>> my template access_ownsite.html
>>
>> {% load staticfiles %}
>>
>> 
>> 
>> 
>> {% block title %}{% endblock %}
>> 
>>
>>
>> 
>> 
>> {% block content %}
>> 
>> {% if user.is_authenticated %}
>> Jesteś zalogowany {{ user.username 
>> }}
>> wyloguj
>> {% else %}
>> Login
>> {% csrf_token 
>> %}
>> {{form.as_p}}
>> 
>> 
>> {% endif %}
>> 
>> 
>> 
>> {% block logout_msg %}
>>  {{ info }} 
>> Nikt nie jest zalogowany w tym momencie.
>> {% endblock %}
>> 
>> 
>> {% if user.is_authenticated == False %}
>> Register
>> {% 
>> csrf_token %}
>> {{form.as_p}}
>> 
>> 
>> {% endif %}
>> 
>> 
>> 
>> copyright © Dariusz Mysior
>> 
>> {% endblock %}
>> 
>> 
>>
>>
>>
>> my view.py
>>
>> from django.contrib.auth.forms import UserCreationForm, AuthenticationForm
>> from django.shortcuts import render_to_response, render
>> from django.http import  HttpResponseRedirect
>> from django.core.context_processors import csrf
>> from django.contrib.auth import authenticate, login, logout
>>
>>
>> def login_view(request):
>> if request.method == 'POST':
>> username = request.POST['username']
>> password = request.POST['password']
>> user = authenticate(username=username, password=password)
>> if user is not None:
>> if user.is_active:
>> login(request, user)
>> return HttpResponseRedirect('/accounts/my_view')
>> else:
>> # Return a 'disabled account' error message
>> ...
>> else:
>> 
>>
>> ...
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/e4504d21-0587-4ebf-8a76-a69aa1afaa81%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Timezone import error

[knbk]

Hi Ahmed,

When an error happens in an expect: block, python 3 shows the original 
error caught by the try/expect block, as well as the new error. In this 
case, the ImportError is the original error, and it's nothing you should 
worry about: Django catches it and handles it accordingly. Admittedly, the 
error is slightly confusing. The ImportError has nothing to do with 
timezones or pytz. 

The real error is the second one, the MultipleObjectsReturned exception. 
Question.objects.get() expects that exactly one object is returned by the 
database. If there are no objects returned, or more than one is returned, 
it will raise an expection. If you want to get all objects published in the 
current year, you can use 
Question.objects.filter(put_date__year=current_year) instead.

Marten

On Sunday, November 29, 2015 at 4:17:29 PM UTC+1, ahmed.ab...@gmail.com 
wrote:
>
> Hi,
>
> I'm practicing Django v 1.8.6 (Writing your first Django app, part 1) and 
> getting error when trying to import timezone, also I have installed pytz, 
> when I try to use the import timezone package I'm getting ImportError. 
>
> My settings.py has USE_TZ set to true by default, also, I had to change 
> the TIME_ZONE from UTC to Asia/Bahrain but still I'm getting the below 
> error, kindly if anyone have advice on the below error?
>
> >>> from polls.models import Question, Choice
> >>> Question.objects.all()
> [, ]
> >>> Question.objects.filter(id=1)
> []
> >>> Question.objects.filter(id=2)
> []
> >>> Question.objects.filter(id=3)
> []
> >>> Question.objects.filter(question_text__startswith='What')
> [, ]
> >>> from django.utils import timezone
> >>> current_year = timezone.now().year
> >>> Question.objects.get(pub_date__year=current_year)
> Traceback (most recent call last):
>   File 
> "C:\Users\abdullaha\AppData\Local\Programs\Python\Python35\lib\site-packages\django\core\management\commands\shell.py",
>  
> line 69, in h
> andle
> self.run_shell(shell=options['interface'])
>   File 
> "C:\Users\abdullaha\AppData\Local\Programs\Python\Python35\lib\site-packages\django\core\management\commands\shell.py",
>  
> line 61, in r
> un_shell
> raise ImportError
> ImportError
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>   File "", line 1, in 
>   File 
> "C:\Users\abdullaha\AppData\Local\Programs\Python\Python35\lib\site-packages\django\db\models\manager.py",
>  
> line 127, in manager_metho
> d
> return getattr(self.get_queryset(), name)(*args, **kwargs)
>   File 
> "C:\Users\abdullaha\AppData\Local\Programs\Python\Python35\lib\site-packages\django\db\models\query.py",
>  
> line 338, in get
> (self.model._meta.object_name, num)
> polls.models.MultipleObjectsReturned: get() returned more than one 
> Question -- it returned 2!
> >>>
>
> Best regards,
> Ahmed Abdullah
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/58d4cbd4-0cd4-46a1-b978-79d2544b7215%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to write Model.get_absolute_url()?

[knbk]

Namespaces are a mess, and have been for a while. 1.9 cleans this up a bit. 
Some advice for 1.8 to stay in line with the 1.9 changes:

   - Always define an application namespace when using an instance 
   namespace.
   - An app shouldn't depend on the project's url configuration, so always 
   use the application namespace in the view name, i.e. 
   reverse('polls:view'), not reverse('author-polls:view').
   - A project that uses an app may point to a specific instance namespace 
   of that app when necessary, i.e. on the front page with links to both 
   author-polls and publisher-polls.
   - The currently active instance namespace is available as 
   request.resolver_match.namespace.
   - You can set request.current_app = request.resolver_match.namespace before 
   rendering templates, and the {% url %} template tag will use the current 
   namespace for urls in the same application namespace.
   - You can explicitly pass the current namespace to current_app in 
   reverse() to do the same. 

The rationale behind the 1.9 changes it that an application namespace 
should define the name of a view, which the app must be able to know and 
reverse. The instance namespace defines a specific location for that view, 
and a project defines the exact location of that view and may even specify 
multiple locations. The application should typically reverse views for the 
currently active instance namespace, while the project may point to a 
specific instance namespace. By giving the app the ability to define its 
own application namespace, it is fully in control of its own url 
configuration and doesn't require any additional action from the user of 
the app. Since instance namespaces can no longer exist without an 
application namespace (well, it's deprecated anyway), it is always possible 
to reverse a view using the application namespace.

In 1.9, you can then just move the application namespace to the app's 
urlconf, and remove the request.current_app = 
request.resolver_match.namespace, since 1.9 does this for you. 

I hope this helps a bit. If you have any more questions feel free to ask. 

On Monday, December 7, 2015 at 10:45:07 PM UTC+1, Jon Ribbens wrote:
>
> On Monday, 7 December 2015 21:14:45 UTC, Caique Reinhold wrote:
>>
>> Well, as this is implemented you have to know your namespaces during 
>> development. But now i see what's your problem.
>>
>> I'm not sure, but i don't think it is encouraged to have multiple 
>> instances of the same app in one project. I think the sites 
>> contrib app or 
>> some other method of having this author/publisher distinction within the 
>> same app would better suit your needs.
>>
>
> I don't have any needs (the author/publisher thing is from the Django 
> docs, not my app), I'm just trying to write an utterly simple app and I'm 
> trying to find out the "best practices" way of doing it.
>
> The impression I'm getting is that the documentation is misleading and the 
> "instance namespace" feature does not actually really work. And that the 
> answer to my question is that I should use an app namespace and put as part 
> of the installation instructions for my app that the user must put 
> app_name="foo" in their site's urls.py or the app will fail. I guess this 
> is why one of the changes in 1.9 is that now you can define the app_name in 
> the app rather than in the site.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/78bd3615-f8eb-4236-b440-642c899bdf8b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to write Model.get_absolute_url()?

[knbk]

>
> It seems a bit weird that that's not automatic.
>

That's what I thought, so it's automatic in 1.9.

That still leaves the question of what Model.get_absolute_url() should do, 
> given that it has no way to get the current app that I can see. Thank you 
> for your very helpful comments though.
>

It can't know the current app. I never use it for anything but the helpful 
"View on site" link in the admin. I have some plans to revisit this API, 
but that depends on some other work I'm still finishing. 

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/714862a0-d252-4aaf-9ca3-852d41d4cff7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: SyntaxError: invalid syntax when installing Django from pip

[knbk]

This is an issue with setuptools 5.5.x. It is safe to ignore, or you can 
upgrade setuptools by upgrading pip: pip install -U pip

On Wednesday, December 9, 2015 at 11:47:42 AM UTC+1, Chethan Kumar R wrote:
>
> Hi, all
>
> Im new to django, just now installed django through pip and got below 
> syntax error, so can anyone tell me is that fine or need to correct that. 
>
> Thanks in advance.
>
> sudo pip install Django
> Downloading/unpacking Django
>   Downloading Django-1.9-py2.py3-none-any.whl (6.6MB): 6.6MB downloaded
> Installing collected packages: Django
> Compiling /tmp/pip_build_root/Django/django/conf/app_template/apps.py ...
>   File "/tmp/pip_build_root/Django/django/conf/app_template/apps.py", 
> line 4
> class {{ camel_case_app_name }}Config(AppConfig):
>   ^
> SyntaxError: invalid syntax
>
> Compiling /tmp/pip_build_root/Django/django/conf/app_template/models.py ...
>   File "/tmp/pip_build_root/Django/django/conf/app_template/models.py", 
> line 1
> {{ unicode_literals }}from django.db import models
>  ^
> SyntaxError: invalid syntax
>
> Successfully installed Django
> Cleaning up...
>
>
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/0f7f1fc6-a7fd-45a1-b221-a08b4b34cd8c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: a bug in model.Manager.values_list?

[knbk]

Models and querysets are not serializeable using the default `json` tools, 
but Django provides its own set of tools that allow you to serialize models 
and querysets. Take a look at serializing django objects 

. 

On Saturday, December 12, 2015 at 5:41:16 PM UTC+1, Derek wrote:
>
> "Its not a bug, its a feature."
>
> See: 
> https://docs.djangoproject.com/en/1.9/ref/models/querysets/#when-querysets-are-evaluated
>
> If you were designing Django's internals, you might have decided that the 
> Queryset "should behave" in a certain way, but the designers have chosen 
> this approach.  There is no "disguise" about this; it's well-known and 
> well-documented.
>
>
> On Friday, 11 December 2015 15:43:45 UTC+2, Ws Hu wrote:
>>
>> import json
>> from myapp.models import MyModel
>>
>>
>> x = json.dumps(MyModel.objects.values_list('myField', flat=True)) # "[] 
>> is not JSON serializable"
>> x = json.dumps([x for x in MyModel.objects.values_list('myField', flat=
>> True)]) #ok
>>
>>
>>
>> 
>> It seems that the database is accessed only if the result of 
>> objects.filter()/all()/values_list()/... is printed/iterated/... .
>> It's fine, but I think the methods of model manager like 
>> filter()/all()/values_list() should behave as if it is processing python 
>> objects. I have not yet digged into json module, but it did penetrated 
>> django's disguise.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/1a244212-cb4a-4917-b6a4-901081e555d0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: not clear about the name= part of url rooting

[knbk]

Django allows you to reconstruct urls with the reverse() function and {% 
url %} template tag. You can reverse the url for a view by passing the view 
function itself, but this is not very practical. By setting a name for a 
view, you can reverse the url by referencing this name instead. This allows 
you to easily construct links to other pages on your site. For example, if 
question is an instance of your Question model, you can link to it in a 
template like this:

{{ question.title }}


The {% url %} tag will generate a link to the 'detail' view for this 
question. 

On Sunday, December 13, 2015 at 6:45:31 PM UTC+1, krmane wrote:
>
> hello all, 
> I was going through the basic tutorial for django 1.8 
> I see in the 3rd part on views this line. 
> url(r'^(?P[0-9]+)/$', views.details, name='detail'), 
> I have not understood the name = 'details' part? 
> is 'details' a parameter that will have a input value? 
> I am confused because we have already associated the views.detail 
> function to the root. 
> Can some one explain? 
> happy hacking. 
> Krishnakant. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/bdec2e3e-5bb5-49d3-b71d-26e20f43f5a7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: application not recognized as URL namespace

[knbk]

Hi Axel,

An installed application and a registered URL namespace are two distinct 
concepts. A URL namespace can only be defined by setting the app_name 
attribute in your urlconf. In this case, you haven't set a URL namespace 
for your authentication app, so your urls are not namespaced.

Also, the urlconf parameter to reverse() should point to the root urlconf, 
not to the urlconf in which your current url is defined. Since it defaults 
to the root urlconf defined in your project, it's easiest to omit it in 
most cases. If you don't, and use 'authentication.urls' as your root 
urlconf, the generated url will miss the 'authentication/' part of your 
url. 

To reverse the password_change url, simply use this:

reverse('password_change')

Marten


On Monday, December 14, 2015 at 1:37:56 PM UTC+1, axel...@chaos1.de wrote:
>
> In my root url, I have: 
>
> url(r'^authentication/', include('authentication.urls')), 
>
> in authentication/urls.py, I have no app_name declared. 
>
> In a module in authentication, I have 
>
> from django.core.urlresolvers import reverse 
>
> from django.apps import apps 
> print('authentication installed? ' + 
> str(apps.is_installed('authentication'))) 
>
> 
> reverse('authentication:password_change',urlconf='authentication.urls') 
>
>   
> and receive 
> django.core.urlresolvers.NoReverseMatch: 'authentication' is not a 
> registered namespace 
> while the above debug print gives 
> authentication installed? True 
>
> What am I doing wrong here? 
>
> Please advice, 
> Axel 
> — 
> PGP-Key:29E99DD6  ☀ +49 160 9945 7889  ☀ computing @ chaos claudius 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/fc585533-0cb4-4419-8944-b38cbf4b472c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: application not recognized as URL namespace

[knbk]

Could you show your full root urls.py and authentication/urls.py?

On Monday, December 14, 2015 at 3:22:14 PM UTC+1, axel...@chaos1.de wrote:
>
> Thanks for taking the time,
>
>
> Am 14.12.2015 um 14:06 schrieb knbk >:
>
> Hi Axel,
>
> An installed application and a registered URL namespace are two distinct 
> concepts. A URL namespace can only be defined by setting the app_name 
> attribute in your urlconf. In this case, you haven’t set a URL namespace 
> for your authentication app, so your urls are not namespaced.
>
> OK. (I misunderstood the 1.9 docu as this would be required only with 
> instance namespaces).
>
>
> Also, the urlconf parameter to reverse() should point to the root 
> urlconf, not to the urlconf in which your current url is defined. Since it 
> defaults to the root urlconf defined in your project, it's easiest to omit 
> it in most cases. If you don’t, and use 'authentication.urls' as your 
> root urlconf, the generated url will miss the 'authentication/' part of 
> your url.
>
> I understand.
>
>  
>
> To reverse the password_change url, simply use this:
>
> reverse(‚password_change')
>
> Making both changes gives:
> django.core.urlresolvers.NoReverseMatch: Reverse for 'password_change' 
> with arguments '()' and keyword arguments '{}' not found. 0 pattern(s) 
> tried: []
>
> I then tried to reference the views directly instead of strings:
>
> from . import views
> reverse(views.password_change),
>
> with views.py containing:
>
> class PasswordChangeView(LoginRequiredMixin, AuthDecoratorsMixin, 
> WithCurrentSiteMixin, FormView):
> ...
> 
> password_change = PasswordChangeView.as_view()
>
> and got;
>
> django.core.urlresolvers.NoReverseMatch: Reverse for 
> 'authentication.views.PasswordChangeView' with arguments '()' and keyword 
> arguments '{}' not found. 0 pattern(s) tried: []
>
> Axel
>
>
>
> Marten
>
>
> On Monday, December 14, 2015 at 1:37:56 PM UTC+1, axel...@chaos1.de wrote:
>>
>> In my root url, I have: 
>>
>> url(r'^authentication/', include('authentication.urls')), 
>>
>> in authentication/urls.py, I have no app_name declared. 
>>
>> In a module in authentication, I have 
>>
>> from django.core.urlresolvers import reverse 
>>
>> from django.apps import apps 
>> print('authentication installed? ' + 
>> str(apps.is_installed('authentication'))) 
>>
>>
>> 
>> reverse('authentication:password_change',urlconf='authentication.urls') 
>>
>>   
>> and receive 
>> django.core.urlresolvers.NoReverseMatch: 'authentication' is not 
>> a registered namespace 
>> while the above debug print gives 
>> authentication installed? True 
>>
>> What am I doing wrong here? 
>>
>> Please advice, 
>> Axel 
>> — 
>> PGP-Key:29E99DD6  ☀ +49 160 9945 7889  ☀ computing @ chaos claudius 
>>
>>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-users...@googlegroups.com .
> To post to this group, send email to django...@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-users/fc585533-0cb4-4419-8944-b38cbf4b472c%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/django-users/fc585533-0cb4-4419-8944-b38cbf4b472c%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
> ---
> PGP-Key:29E99DD6  ☀ +49 160 9945 7889  ☀ computing @ chaos claudius
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/e8700750-d783-4636-926e-6a73c2fb6f6b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: application not recognized as URL namespace

[knbk]

>
> authentication/urls.py:
>
 

from django.conf.urls import url
> from . import views
>
 

app_name = 'authentication'
>

I thought you didn't have an app_name, but you do have one. In that case, 
the only problem was that you passed the wrong urlconf to reverse(). You 
should be able to reverse the url with:

reverse('authentication:password_change')



On Monday, December 14, 2015 at 3:53:24 PM UTC+1, axel...@chaos1.de wrote:
>
>
> Am 14.12.2015 um 15:29 schrieb knbk >:
>
> Could you show your full root urls.py and authentication/urls.py?
>
>
> urls.py:
>
> from django.conf.urls import include, url
> from django.views.generic import TemplateView
>
> # Uncomment the next two lines to enable the admin:
> from django.contrib import admin
>
> urlpatterns = (
> url(r'^$', TemplateView.as_view(template_name='base.html')),
> url(r'^authentication/', include('authentication.urls')),
> url(r'^admin/', include(admin.site.urls)),
> )
>
> if settings.DEBUG:
> import debug_toolbar
> urlpatterns += (url(r'^__debug__/', include(debug_toolbar.urls)),)
>
> authentication/urls.py:
>
> from django.conf.urls import url
> from . import views
>
> app_name = 'authentication'
>
> urlpatterns = [
> url(r'^$', views.index, name='index'),
> url(r'^login/$', views.login, name='login'),
> url(r'^loggedin/$', views.loggedin, name='loggedin'),
> url(r'^logout/$', views.logout, name='logout'),
> url(r'^password/$', views.password, name='password'),
> url(r'^password_change/$', views.password_change, 
> name='password_change'),
> url(r'^password_change/done/$', views.password_change_done, 
> name='password_change_done'),
> url(r'^password_reset/$', views.password_reset, name='password_reset'),
> url(r'^password_reset/done/$', views.password_reset_done, 
> name='password_reset_done'),
> url(r'^reset/done/$', views.password_reset_complete, 
> name='password_reset_complete'),
> 
> url(r'^reset/(?P[0-9A-Za-z]{1,13})-(?P[0-9A-Za-z]{1,13}-[0-9A-Za-z]{1,20})/$',
> views.password_reset_confirm,
> name='password_reset_confirm'),
> url(r'^profile/$', views.profile, name='profile')
> ]
>
> Axel
>
>
> On Monday, December 14, 2015 at 3:22:14 PM UTC+1, axel...@chaos1.de wrote:
>>
>> Thanks for taking the time,
>>
>>
>> Am 14.12.2015 um 14:06 schrieb knbk :
>>
>> Hi Axel,
>>
>> An installed application and a registered URL namespace are two distinct 
>> concepts. A URL namespace can only be defined by setting the app_name 
>> attribute in your urlconf. In this case, you haven’t set a URL namespace 
>> for your authentication app, so your urls are not namespaced.
>>
>> OK. (I misunderstood the 1.9 docu as this would be required only with 
>> instance namespaces).
>>
>>
>> Also, the urlconf parameter to reverse() should point to the root 
>> urlconf, not to the urlconf in which your current url is defined. Since it 
>> defaults to the root urlconf defined in your project, it's easiest to omit 
>> it in most cases. If you don’t, and use 'authentication.urls' as your 
>> root urlconf, the generated url will miss the 'authentication/' part of 
>> your url.
>>
>> I understand.
>>
>>  
>>
>> To reverse the password_change url, simply use this:
>>
>> reverse(‚password_change')
>>
>> Making both changes gives:
>> django.core.urlresolvers.NoReverseMatch: Reverse for 'password_change' 
>> with arguments '()' and keyword arguments '{}' not found. 0 pattern(s) 
>> tried: []
>>
>> I then tried to reference the views directly instead of strings:
>>
>> from . import views
>> reverse(views.password_change),
>>
>> with views.py containing:
>>
>> class PasswordChangeView(LoginRequiredMixin, AuthDecoratorsMixin, 
>> WithCurrentSiteMixin, FormView):
>> ...
>> 
>> password_change = PasswordChangeView.as_view()
>>
>> and got;
>>
>> django.core.urlresolvers.NoReverseMatch: Reverse for 
>> 'authentication.views.PasswordChangeView' with arguments '()' and keyword 
>> arguments '{}' not found. 0 pattern(s) tried: []
>>
>>

Re: ModelForm.is_valid() doesn't work the first time but does the second

[knbk]

>>> uf = UsersForm(u)

Here you are passing the user instance as if it were the POST data. The 
form expects a dictionary or None as the first argument. `form.is_bound` 
simply checks `data is not None`, which is True in this case.

If you want a bound form, you should pass a dictionary with the appropriate 
values as the first argument, and pass the user instance as the `instance=` 
argument. Forms are meant to handle user input in a POST request -- that's 
why it only accepts a dictionary such as request.POST as the input data. 

On Sunday, January 3, 2016 at 2:53:02 PM UTC+1, Vijay Khemlani wrote:
>
> Well, it's not supposed to be bound if you don't pass any data to it
>
> the "instance" in the ModelForm (if i remember correctly) just sets the 
> initial values for the fields when you render the form in HTML and modifies 
> that instance when you call "save" on the ModelForm.
>
> On Sun, Jan 3, 2016 at 1:29 AM, Michael Molloy  > wrote:
>
>> Thank you for your help. I apologize for the typo, but I am calling 
>> is_valid() with the parenthesis:
>>
>>
>> >>> uf = UsersForm(u)
>>
>> >>> uf.is_valid()
>>
>> Traceback (most recent call last):
>>
>>  File "", line 1, in 
>>
>>  File 
>> "/var/lib/openshift/5678c24389f5cff0330001cd/python/virtenv/venv/lib64/python3.3/site-packages/django/forms/forms.py"
>> , line 184, in is_valid
>>
>>return self.is_bound and not self.errors
>>
>>  File 
>> "/var/lib/openshift/5678c24389f5cff0330001cd/python/virtenv/venv/lib64/python3.3/site-packages/django/forms/forms.py"
>> , line 176, in errors
>>
>>self.full_clean()
>>
>>  File 
>> "/var/lib/openshift/5678c24389f5cff0330001cd/python/virtenv/venv/lib64/python3.3/site-packages/django/forms/forms.py"
>> , line 392, in full_clean
>>
>>self._clean_fields()
>>
>>  File 
>> "/var/lib/openshift/5678c24389f5cff0330001cd/python/virtenv/venv/lib64/python3.3/site-packages/django/forms/forms.py"
>> , line 401, in _clean_fields
>>
>>value = field.widget.value_from_datadict(self.data, self.files, self.
>> add_prefix(name))
>>
>>  File 
>> "/var/lib/openshift/5678c24389f5cff0330001cd/python/virtenv/venv/lib64/python3.3/site-packages/django/forms/widgets.py"
>> , line 223, in value_from_datadict
>>
>> return data.get(name, None)
>>
>> AttributeError: 'Users' object has no attribute 'get'
>>
>>
>> >>> uf.is_valid()
>>
>> True
>>
>>
>> As for creating the form instance with the instance keyword, I tried that 
>> first as I saw it in the materials I was reading, but it doesn't work. Note 
>> the code below. is_bound = False if I use instance=u. If I just pass the 
>> Users instance without the 'instance' keyword, is_bound returns True.
>>
>> >>> u = Users()
>>
>> >>> u.email = 'je...@home.net '
>>
>> >>> uf = UsersForm(u)
>>
>> >>> uf.is_bound
>>
>> True
>>
>> >>> uf = UsersForm(instance=u)
>>
>> >>> uf.is_bound
>>
>> False
>>
>>
>> --M
>>
>> On Saturday, January 2, 2016 at 10:16:38 PM UTC-6, Vijay Khemlani wrote:
>>>
>>> "First, why does uf.is_valid() return"
>>>
>>> because you called "uf.is_valid" (note the lack of parenthesis), that's 
>>> just a reference to the method and does not call it.
>>>
>>> "Second, why does uf.save() return that stacktrace the first time I call 
>>> it, but the second time I call it, the object saves? "
>>>
>>> As far as I know ModelForm subclasses take a dictionary as a first 
>>> parameter, not the object itself, you would need to do something like this:
>>>
>>> uf = UsersForm(instance=u)
>>>
>>> I don't know why it works the second time (if it does indeed work)
>>>
>>>
>>> On Sun, Jan 3, 2016 at 1:13 AM, Sergiy Khohlov  
>>> wrote:
>>>
 Sorry I missed. You have valid unknown at the start. Why are you not 
 used django user model and author? Study purpose ,?
 3 січ. 2016 05:53 "Michael Molloy"  пише:

 I'm not sure what could be wrong with the database settings. If I just 
> create an instance of the model and save it, it saves to the database:
>
>
> 
>
> >>> u.email = 'jo...@test.com'
>
> >>> u.save()
>
>
>
> 
>
> --M
>
> On Saturday, January 2, 2016 at 9:48:39 PM UTC-6, Sergiy Khohlov wrote:
>>
>> Is_valid is working. You have 
>> problem with save. Check database setting.
>>
>> 3 січ. 2016 04:18 "Michael Molloy"  пише:
>> >ve
>> > This is running in Openshift with Python 3.3 and Django 1.8.4
>> >
>> > Here's my model:
>> >
>> > class Users(models.Model):
>> > first_nm = models.CharField('First Name', max_length=100)
>> > last_nm = models.CharField('Last Name', max_length=100)
>> > email = models.CharField('Email Address', max_length=200, 
>> unique=True)
>

Re: ImportError: No module named security

[knbk]

Seems like you have SecurityMiddleware in your middleware settings, which 
wasn't added until 1.8. If you started your project on 1.8+. your default 
settings file would include the new middleware and cause this error on 1.7. 

On Tuesday, January 5, 2016 at 2:56:51 AM UTC+1, Gary Roach wrote:
>
> I've been trying different things with django and different tutorials. I 
> was using Ninja as my IDE but had to give it up because of lack of 
> support. I just switched to Eclipse with the PyDev plugin. (No I cant 
> get Pycharm). The IDE is complicated but seems to do everything I wish 
> it to do if I work at it long enough. 
>
> The problem: 
> I am working on Tango With Django tutorial and have a virtual 
> environment setup with Python 2.7 and Django 1.7 . Debian Linux is still 
> stuck with Eclipse 3.8 so I installed Eclipse Mars (4.5) from source. 
> The project properties show that python 2.7 is sourced from the virtual 
> environment's local/bin/ directory. Both Python 2.7 and Django 1.7 were 
> installed in the virtual environment using pip with the no site packages 
> switch. So everything should be walled off from the rest of the system. 
> Further, the project was working OK until I tried to access the /admin/ 
> app. It hasn't worked since. 
>
> When I run debug on the project no errors show and the internal web 
> server starts fine. When I try to access either the rango/ app, the 
> admin/ app or just the 127.0.0.1:8000 basic url the browser shows "A 
> server error occurred.  Please contact the administrator." The Eclipse 
> console shows the following: 
>
> Traceback (most recent call last): 
>File "/usr/lib/python2.7/wsgiref/handlers.py", line 85, in run 
>  self.result = application(self.environ, self.start_response) 
>File 
> "/home/gary/workspace/TangoWithDjango/local/lib/python2.7/site-packages/django/contrib/staticfiles/handlers.py",
>  
>
> line 64, in __call__ 
>  return self.application(environ, start_response) 
>File 
> "/home/gary/workspace/TangoWithDjango/local/lib/python2.7/site-packages/django/core/handlers/wsgi.py",
>  
>
> line 168, in __call__ 
>  self.load_middleware() 
>File 
> "/home/gary/workspace/TangoWithDjango/local/lib/python2.7/site-packages/django/core/handlers/base.py",
>  
>
> line 44, in load_middleware 
>  mw_class = import_string(middleware_path) 
>File 
> "/home/gary/workspace/TangoWithDjango/local/lib/python2.7/site-packages/django/utils/module_loading.py",
>  
>
> line 26, in import_string 
>  module = import_module(module_path) 
>File "/usr/lib/python2.7/importlib/__init__.py", line 37, in 
> import_module 
>  __import__(name) 
> ImportError: No module named security 
> [05/Jan/2016 00:21:51] "GET / HTTP/1.1" 500 59 
>
> I notice that the first and last items on the traceback list are pulling 
> data from the global (system) python package. I've searched the net for 
> information. This problem shows up several times but It is obvious that 
> no one really understands what is causing it. I rebooted the system but 
> the problem persisted. Any help will be sincerely appreciated. 
>
> Gary R. 
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/aa6f7641-a431-4ede-8805-07254713a78c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: empty request object

[knbk]

The `__repr__` method on HttpRequest was simplified in 1.9[1]. It is not an 
accurate description of what is actually contained in the request, and I 
doubt it has anything to do with the actual issues you're facing. 

[1] 
https://docs.djangoproject.com/en/1.9/releases/1.9/#httprequest-details-in-error-reporting

On Saturday, February 27, 2016 at 11:09:28 PM UTC+1, larry@gmail.com 
wrote:
>
> On Sat, Feb 27, 2016 at 5:02 PM, James Schneider 
> > wrote: 
> > 
> > On Feb 27, 2016 1:55 PM, "Larry Martell"  > wrote: 
> >> 
> >> Anyone have any insights on this? Is there anything special I need to 
> >> do get the request structure? The way this 1.9 site is now, it doesn't 
> >> work at all because the request structure is not getting passed in. 
> >> 
> > 
> > I'd be most suspicious of middle ware not handling the request 
> correctly. 
>
> I tried removing all the middleware, but I got the same result. This 
> is the middleware that was in place: 
>
> 'django.middleware.security.SecurityMiddleware', 
> 'django.contrib.sessions.middleware.SessionMiddleware', 
> 'django.middleware.common.CommonMiddleware', 
> 'django.middleware.csrf.CsrfViewMiddleware', 
> 'django.contrib.auth.middleware.AuthenticationMiddleware', 
> 'django.contrib.auth.middleware.SessionAuthenticationMiddleware', 
> 'django.contrib.messages.middleware.MessageMiddleware', 
> 'django.middleware.clickjacking.XFrameOptionsMiddleware', 
> 'django.middleware.security.SecurityMiddleware', 
>
>
> > Have you tried moving to a fresh venv to ensure Django and other 
> packages 
> > aren't damaged? 
> > 
> > Can you replicate the issue on a separate test server? 
>
> No, I haven't tried either one yet. I guess I will have to do that, 
> but I really would like to just get this setup working. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/890bb238-7980-4b12-bdf2-400379b31ee7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: empty request object

[knbk]

I was referring to the wrong release notes. The rights one can be found in 
the 1.8 release notes in the miscellaneous section[1]:

HttpRequest 
> <https://docs.djangoproject.com/en/1.9/ref/request-response/#django.http.HttpRequest>
>  now 
> has a simplified repr (e.g. ). This won’t 
> change the behavior of theSafeExceptionReporterFilter 
> <https://docs.djangoproject.com/en/1.9/howto/error-reporting/#django.views.debug.SafeExceptionReporterFilter>
>  class.


Printing the request in your debugger is nothing more than calling repr on 
the request and displaying the result. The conclusion is the same: the 
request is not empty, but the string representation of the request has 
changed. This is unrelated to whatever issue you're facing. 

[1] https://docs.djangoproject.com/en/1.9/releases/1.8/#miscellaneous

On Saturday, February 27, 2016 at 11:21:18 PM UTC+1, larry@gmail.com 
wrote:
>
> On Sat, Feb 27, 2016 at 5:14 PM, knbk > 
> wrote: 
> > The `__repr__` method on HttpRequest was simplified in 1.9[1]. It is not 
> an 
> > accurate description of what is actually contained in the request, and I 
> > doubt it has anything to do with the actual issues you're facing. 
> > 
> > [1] 
> > 
> https://docs.djangoproject.com/en/1.9/releases/1.9/#httprequest-details-in-error-reporting
>  
>
> I am printing the request object from the debugger: 
>
> (Pdb) request 
>  
>
> This is not in the debug page. I'm pretty sure it's empty as when I 
> call login(request) I get a blank page with a 200 back. 
>
> > 
> > On Saturday, February 27, 2016 at 11:09:28 PM UTC+1, larry@gmail.com 
> > wrote: 
> >> 
> >> On Sat, Feb 27, 2016 at 5:02 PM, James Schneider 
> >>  wrote: 
> >> > 
> >> > On Feb 27, 2016 1:55 PM, "Larry Martell"  
> wrote: 
> >> >> 
> >> >> Anyone have any insights on this? Is there anything special I need 
> to 
> >> >> do get the request structure? The way this 1.9 site is now, it 
> doesn't 
> >> >> work at all because the request structure is not getting passed in. 
> >> >> 
> >> > 
> >> > I'd be most suspicious of middle ware not handling the request 
> >> > correctly. 
> >> 
> >> I tried removing all the middleware, but I got the same result. This 
> >> is the middleware that was in place: 
> >> 
> >> 'django.middleware.security.SecurityMiddleware', 
> >> 'django.contrib.sessions.middleware.SessionMiddleware', 
> >> 'django.middleware.common.CommonMiddleware', 
> >> 'django.middleware.csrf.CsrfViewMiddleware', 
> >> 'django.contrib.auth.middleware.AuthenticationMiddleware', 
> >> 'django.contrib.auth.middleware.SessionAuthenticationMiddleware', 
> >> 'django.contrib.messages.middleware.MessageMiddleware', 
> >> 'django.middleware.clickjacking.XFrameOptionsMiddleware', 
> >> 'django.middleware.security.SecurityMiddleware', 
> >> 
> >> 
> >> > Have you tried moving to a fresh venv to ensure Django and other 
> >> > packages 
> >> > aren't damaged? 
> >> > 
> >> > Can you replicate the issue on a separate test server? 
> >> 
> >> No, I haven't tried either one yet. I guess I will have to do that, 
> >> but I really would like to just get this setup working. 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "Django users" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to django-users...@googlegroups.com . 
> > To post to this group, send email to django...@googlegroups.com 
> . 
> > Visit this group at https://groups.google.com/group/django-users. 
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/django-users/890bb238-7980-4b12-bdf2-400379b31ee7%40googlegroups.com.
>  
>
> > 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/3e31049c-82cc-4587-bb18-c06e683e65a7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: empty request object

[knbk]

That would happen if the AuthenticationMiddleware hasn't run. In what 
context is request.user missing?

On Monday, February 29, 2016 at 3:54:24 PM UTC+1, larry@gmail.com wrote:
>
> So does anyone know why there would be a no user attr? I would expect 
> this: 
>
> (Pdb) request.user 
>  
>
> But I get this: 
>
> (Pdb) request.user 
> *** AttributeError: 'WSGIRequest' object has no attribute 'user' 
>
> On Sat, Feb 27, 2016 at 6:31 PM, Larry Martell  > wrote: 
> > Yes, you are absolutely correct. Thanks for directing me away from 
> > that red herring. But it seems request.user no longer exists. 
> > 
> > There is code that does this: 
> > 
> > if request.user.is_authenticated(): 
> > 
> > which throws: 
> > 
> > AttributeError: "'WSGIRequest' object has no attribute 'user'" 
> > 
> > On Sat, Feb 27, 2016 at 5:48 PM, knbk > 
> wrote: 
> >> I was referring to the wrong release notes. The rights one can be found 
> in 
> >> the 1.8 release notes in the miscellaneous section[1]: 
> >> 
> >>> HttpRequest now has a simplified repr (e.g.  >>> '/somepath/'>). This won’t change the behavior of 
> >>> theSafeExceptionReporterFilter class. 
> >> 
> >> 
> >> Printing the request in your debugger is nothing more than calling repr 
> on 
> >> the request and displaying the result. The conclusion is the same: the 
> >> request is not empty, but the string representation of the request has 
> >> changed. This is unrelated to whatever issue you're facing. 
> >> 
> >> [1] https://docs.djangoproject.com/en/1.9/releases/1.8/#miscellaneous 
> >> 
> >> On Saturday, February 27, 2016 at 11:21:18 PM UTC+1, 
> larry@gmail.com 
> >> wrote: 
> >>> 
> >>> On Sat, Feb 27, 2016 at 5:14 PM, knbk  wrote: 
> >>> > The `__repr__` method on HttpRequest was simplified in 1.9[1]. It is 
> not 
> >>> > an 
> >>> > accurate description of what is actually contained in the request, 
> and I 
> >>> > doubt it has anything to do with the actual issues you're facing. 
> >>> > 
> >>> > [1] 
> >>> > 
> >>> > 
> https://docs.djangoproject.com/en/1.9/releases/1.9/#httprequest-details-in-error-reporting
>  
> >>> 
> >>> I am printing the request object from the debugger: 
> >>> 
> >>> (Pdb) request 
> >>>  
> >>> 
> >>> This is not in the debug page. I'm pretty sure it's empty as when I 
> >>> call login(request) I get a blank page with a 200 back. 
> >>> 
> >>> > 
> >>> > On Saturday, February 27, 2016 at 11:09:28 PM UTC+1, 
> larry@gmail.com 
> >>> > wrote: 
> >>> >> 
> >>> >> On Sat, Feb 27, 2016 at 5:02 PM, James Schneider 
> >>> >>  wrote: 
> >>> >> > 
> >>> >> > On Feb 27, 2016 1:55 PM, "Larry Martell"  
> wrote: 
> >>> >> >> 
> >>> >> >> Anyone have any insights on this? Is there anything special I 
> need 
> >>> >> >> to 
> >>> >> >> do get the request structure? The way this 1.9 site is now, it 
> >>> >> >> doesn't 
> >>> >> >> work at all because the request structure is not getting passed 
> in. 
> >>> >> >> 
> >>> >> > 
> >>> >> > I'd be most suspicious of middle ware not handling the request 
> >>> >> > correctly. 
> >>> >> 
> >>> >> I tried removing all the middleware, but I got the same result. 
> This 
> >>> >> is the middleware that was in place: 
> >>> >> 
> >>> >> 'django.middleware.security.SecurityMiddleware', 
> >>> >> 'django.contrib.sessions.middleware.SessionMiddleware', 
> >>> >> 'django.middleware.common.CommonMiddleware', 
> >>> >> 'django.middleware.csrf.CsrfViewMiddleware', 
> >>> >> 'django.contrib.auth.middleware.AuthenticationMiddleware', 
> >>> >> 
> 'django.contrib.auth.middleware.SessionAuthenticationMiddleware', 
> >>> >> 'django.contrib.messages.middleware.MessageMiddleware', 
> >>> >> 'django.middleware.clickjacking.XFrameOptionsMiddleware', 
> >>> >> 'django.middleware.security.SecurityMiddleware', 
> >>> >> 
> >>> >> 
> >>> >> > Have you tried moving to a fresh venv to ensure Django and other 
> >>> >> > packages 
> >>> >> > aren't damaged? 
> >>> >> > 
> >>> >> > Can you replicate the issue on a separate test server? 
> >>> >> 
> >>> >> No, I haven't tried either one yet. I guess I will have to do that, 
> >>> >> but I really would like to just get this setup working. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/d9ea027a-4e64-4e43-a5f9-8fe484710574%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Problem with create new instance

[knbk]

Any reason you're not using `manage.py shell`? It automatically loads the 
Django environment, and supports IPython. 

On Wednesday, March 9, 2016 at 7:35:45 PM UTC+1, Dariusz Mysior wrote:
>
> Ok I have it. I put it to starting scripts
>
> W dniu środa, 9 marca 2016 18:48:15 UTC+1 użytkownik Dariusz Mysior 
> napisał:
>>
>> I have Django 1.8 Python 3.4 
>>
>> My app contact. I have model and form like below and when I run command 
>>
>>  
>>
>>> from contact.forms import MessageForm
>>>
>>  and next 
>>
>>> form = MessageForm()
>>>
>>
>> I have error
>>
>> In[2]: from contact.forms import MessageForm
 In[3]: form = MessageForm()
 Traceback (most recent call last):
   File 
 "/home/darek/.virtualenvs/kurs/lib/python3.4/site-packages/django/utils/translation/trans_real.py",
  
 line 161, in _add_installed_apps_translations
 app_configs = reversed(list(apps.get_app_configs()))
   File 
 "/home/darek/.virtualenvs/kurs/lib/python3.4/site-packages/django/apps/registry.py",
  
 line 137, in get_app_configs
 self.check_apps_ready()
   File 
 "/home/darek/.virtualenvs/kurs/lib/python3.4/site-packages/django/apps/registry.py",
  
 line 124, in check_apps_ready
 raise AppRegistryNotReady("Apps aren't loaded yet.")
 django.core.exceptions.AppRegistryNotReady: Apps aren't loaded yet.

 During handling of the above exception, another exception occurred:

 Traceback (most recent call last):
   File 
 "/home/darek/.virtualenvs/kurs/lib/python3.4/site-packages/IPython/core/interactiveshell.py",
  
 line 3066, in run_code
 exec(code_obj, self.user_global_ns, self.user_ns)
   File "", line 1, in 
 form = MessageForm()
   File 
 "/home/darek/.virtualenvs/kurs/lib/python3.4/site-packages/django/forms/models.py",
  
 line 329, in __init__
 error_class, label_suffix, empty_permitted)
   File 
 "/home/darek/.virtualenvs/kurs/lib/python3.4/site-packages/django/forms/forms.py",
  
 line 129, in __init__
 self.label_suffix = label_suffix if label_suffix is not None else 
 _(':')
   File 
 "/home/darek/.virtualenvs/kurs/lib/python3.4/site-packages/django/utils/translation/__init__.py",
  
 line 84, in ugettext
 return _trans.ugettext(message)
   File 
 "/home/darek/.virtualenvs/kurs/lib/python3.4/site-packages/django/utils/translation/trans_real.py",
  
 line 317, in gettext
 return do_translate(message, 'gettext')
   File 
 "/home/darek/.virtualenvs/kurs/lib/python3.4/site-packages/django/utils/translation/trans_real.py",
  
 line 300, in do_translate
 _default = _default or translation(settings.LANGUAGE_CODE)
   File 
 "/home/darek/.virtualenvs/kurs/lib/python3.4/site-packages/django/utils/translation/trans_real.py",
  
 line 206, in translation
 _translations[language] = DjangoTranslation(language)
   File 
 "/home/darek/.virtualenvs/kurs/lib/python3.4/site-packages/django/utils/translation/trans_real.py",
  
 line 116, in __init__
 self._add_installed_apps_translations()
   File 
 "/home/darek/.virtualenvs/kurs/lib/python3.4/site-packages/django/utils/translation/trans_real.py",
  
 line 164, in _add_installed_apps_translations
 "The translation infrastructure cannot be initialized before the "
 django.core.exceptions.AppRegistryNotReady: The translation 
 infrastructure cannot be initialized before the apps registry is ready. 
 Check that you don't make non-lazy gettext calls at import time.
>>>
>>>
>> models.py
>>  
>>
>> from django.db import models
>>
>> # Create your models here.
>>
>> class Message(models.Model):
>> name = models.CharField(max_length=250)
>> email = models.EmailField()
>> message = models.TextField()
>>
>> def __str__(self):
>> return "message from {name}".format(name=self.name)
>>
>>
>>
>>
>> forms.py
>>
>> #!/usr/bin/env python
>> from django import forms
>> from .models import Message
>>
>> class MessageForm(forms.ModelForm):
>> class Meta:
>> model = Message
>> fields = ['name', 'email', 'message']
>>
>>
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/d1d1bb08-8e5c-4f74-afb2-5266fc32ab42%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Getting NoReverseMatch at /logout/

[knbk]

On Monday, March 28, 2016 at 7:23:22 PM UTC+2, James Schneider wrote:
>
> That's not entirely accurate. It is perfectly valid to assign a name to an 
> included set of URL's. This creates a namespace for the URL's that are 
> being included. See here:
>

Actually, the name parameter is completely ignored[1] when using include(). 
You can set a namespace by passing the namespace (and app_name) parameter 
to include()[2], or in 1.9+, by setting the app_name attribute in the 
target URLconf[3]. That means the name that should be used with the current 
code is just 'home'.

[1] 
https://github.com/django/django/blob/859fc64338f760508f9618c100ad92b925802b18/django/conf/urls/__init__.py#L78
[2] 
https://docs.djangoproject.com/en/1.8/topics/http/urls/#url-namespaces-and-included-urlconfs
[3] 
https://docs.djangoproject.com/en/1.9/topics/http/urls/#url-namespaces-and-included-urlconfs

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/dd0f1587-ea92-43d2-bba0-1bdd0723afab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.