Re: New to Django; walking through djangoproject tutorial; can't get poll to work

[Deron]

Sorry, Karen. Thanks for the reply. I'll head over there!

On Tuesday, December 18, 2012 10:34:27 PM UTC-5, Karen Tracey wrote:
>
> Please ask questions about using Django on django-users. The topic of this 
> list is the development of Django itself.
>
> Thanks,
> Karen
>

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

Re: New to Django; walking through djangoproject tutorial; can't get poll to work

[Karen Tracey]

Please ask questions about using Django on django-users. The topic of this
list is the development of Django itself.

Thanks,
Karen

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

New to Django; walking through djangoproject tutorial; can't get poll to work

[Deron]

Hi,

First post here. I'm extremely new to Django and I have been fumbling my 
way through the DjangoProject "poll" app tutorial for a couple weeks now. I 
understand a lot of what's going on, but a lot of things are completely 
lost on me as well. That said, I'm to the point of actually using the poll 
app. I've created a view so you can view the poll, select a choice and then 
click "vote." Problem is, when I view the page (/polls/1/) I see my heading 
which is "What's Up?" and I see a "vote" input button, but no radio button. 
I'm not exactly sure why it's not showing up. Anyone want to take a shot in 
the dark on this one? Here's my "detail.html" view (copied straight from 
the tutorial):

*{{ poll.question }}
{% if error_message %}{{ error_message }}{% endif %}

{% csrf_token %}
{% for choice in poll.choice_set.all %}

{{ choice.choice }}
{% endfor %}

*

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

Re: URLField definition on creation.py

[maxi]

Ok, then, what about SlugField?
Is not the same case?

Regards.

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

Re: broken pipe issue with runserver #4444

[Julien Phalip]

On Dec 18, 2012, at 5:18 AM, Emil Stenström  wrote:

> On Monday, 2 June 2008 02:45:07 UTC+2, Ludvig Ericson wrote:
> I'd rather see this be leaved as-is, since I haven't seen a single  
> report on these broken pipe 'issues'.
> 
> Here's a report:
> 
> I'm using PhantomJS (headless webkit browser) to test for javascript errors 
> on my site. Using the LiveServerTestCase it's possible to spawn a test 
> server, and using Python's subprocess I can call PhantomJS to access that 
> server and assert that there are no errors.
> 
> Problem is, the test server is spitting back broken pipe errors. By reading 
> explanations elsewhere I've understood that this is a browser problem, that 
> they are not supposed to break connections like that, but the fact is that 
> they are. It feels strange to read recommendations that I should just ignore 
> the errors, since having random stacktrace printouts in my tests feels 
> extremely sloppy. 
> 
> Given that browsers behave like they do, and we're not able to change that, I 
> suggest that ticket # is reconsidered, and no marked as wontfix.
> 
> As a workaround I would have hoped for a way to ignore the messages in some 
> other way. I've tried setting up logging to ignore the errors, but failed. My 
> guess is that these errors don't go through the logger. Maybe this couple me 
> the recommended (and documented) way of handling this?
> 
> (Here's the code if you want to reproduce: 
> http://stackoverflow.com/questions/13287490/is-there-a-way-to-use-phantomjs-in-python/13933894#13933894
>  )

Those errors are indeed extremely noisy and confusing. I'm in favor of 
modifying Django to reduce that noise, but only if it gets proven that ignoring 
those errors won't either cause the tests to fail or to pass as false positives.

Julien

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

Re: Charset for URL decoding (#19468)

[Aymeric Augustin]

2012/12/18 Łukasz Rekucki 
>
> I wonder if  UTF-8 with "surrogates escape" error mode makes sense here.
> Python 3 uses it for decoding file-system paths, where it's not always
> possible to determine the charset.  I think it's pretty much the same case.
> After all, the %-coded bytes can be some binary data that's not possible to
> reasonably decode with any charset.
>

Hi Łukasz,

This proposal is about error handling, which was settled in #5738.

(Off-topic: another fallback strategy is to use iso-8859-1, because it maps
1-to-1 to bytes. WSGI on Python 3 takes advantage of this.)

-- 
Aymeric.

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

Re: Django 1.1 is not installable

[Tom Evans]

On Wed, Dec 12, 2012 at 3:56 PM, Michael Elsdörfer  wrote:
> $ pip install django==1.1

If you mean "The most recent point release in the 1.1 family", then
that is "Django>1.1,<1.2"*.
If you mean 1.1.1, then that is "Django==1.1.1"

Cheers

Tom

* If you are using pypi, then "Django<1.2" will do the trick. However,
if you are running your own cheeseshop, you may have imported 1.0.x
and 1.2.x but no 1.1.x - being explicit about the versions you want
avoids confusion.

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

Re: Charset for URL decoding (#19468)

[Aymeric Augustin]

2012/12/18 Karen Tracey 

> https://code.djangoproject.com/ticket/5738
>
> Comment #10 notes that utf-8 is what Django will use but with the last fix
> noted against that ticket it is easier for the request class to be
> subclassed to change things for an installation where a different charset
> for decoding might be desired.


Hi Karen,

Indeed, thanks.

I reviewed that ticket and I agree with the final fix. Sure, it's a bit
sloppy to use a protocol-level message for an application-level requirement
(in other words, to reply to a well-formed HTTP request with 400 Bad
Request), but I can't think of a better solution when the URL cannot be
decoded with the "expected charset".

Now, I'm proposing something slightly different. I think that the "expected
charset" to be DEFAULT_CHARSET rather than "utf-8". If the URL cannot be
decoded, the error handling designed in #5738 would still kick in.

I consider that Django already "strongly recommends" utf-8, as it's the
default value of DEFAULT_CHARSET. If a developper changes this setting, I
believe it should apply to the HTTP side of the application as a whole, and
specifically, to the entire URL.

-- 
Aymeric.

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

Re: Charset for URL decoding (#19468)

[Karen Tracey]

On Tue, Dec 18, 2012 at 3:34 AM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

>
> Currently, Django uses utf-8. As far as I can tell, that's more a
> side-effect of (ab)using force_str than anything else. It also has the
> drawback of making it impossible to serve perfectly legit HTTP URLs such
> as /caf%E9/ — try it: https://www.djangoproject.com/caf%E9/ — that
> returns a 400 with no content. I think I once saw a ticket about this, but
> I can't locate it right now.
>


I think it is:

https://code.djangoproject.com/ticket/5738

Comment #10 notes that utf-8 is what Django will use but with the last fix
noted against that ticket it is easier for the request class to be
subclassed to change things for an installation where a different charset
for decoding might be desired.

Karen

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

Re: broken pipe issue with runserver #4444

[Emil Stenström]

On Monday, 2 June 2008 02:45:07 UTC+2, Ludvig Ericson wrote:
>
> I'd rather see this be leaved as-is, since I haven't seen a single  
>
> report on these broken pipe 'issues'.
>
Here's a report:

I'm using PhantomJS (headless webkit browser) to test for javascript errors 
on my site. Using the LiveServerTestCase it's possible to spawn a test 
server, and using Python's subprocess I can call PhantomJS to access that 
server and assert that there are no errors.

Problem is, the test server is spitting back broken pipe errors. By reading 
explanations elsewhere I've understood that this is a browser problem, that 
they are not supposed to break connections like that, but the fact is that 
they are. It feels strange to read recommendations that I should just 
ignore the errors, since having random stacktrace printouts in my tests 
feels extremely sloppy. 

Given that browsers behave like they do, and we're not able to change that, 
I suggest that ticket # is reconsidered, and no marked as wontfix.

As a workaround I would have hoped for a way to ignore the messages in some 
other way. I've tried setting up logging to ignore the errors, but failed. 
My guess is that these errors don't go through the logger. Maybe this 
couple me the recommended (and documented) way of handling this?

(Here's the code if you want to reproduce: 
http://stackoverflow.com/questions/13287490/is-there-a-way-to-use-phantomjs-in-python/13933894#13933894
 
)

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

Re: Charset for URL decoding (#19468)

[Łukasz Rekucki]

On 18 December 2012 09:34, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> (complete version follows)
>
> Hello,
>
> I'm looking for some feedback on #19468 before making a decision. It's one
> of the tickets that currently block the 1.5 release.
>
> Here's a summary of the problem.
>
> Django must decode environ['PATH_INFO'] to obtain request.path, where
> decoding means :
>   1 - URL-decoding to a bytestring
>   2 - "charset-decoding" to an unicode string
>
> The question is : which charset should be used in step 2?
> settings.DEFAULT_CHARSET or utf-8 (hardcoded)?
>
>
I wonder if  UTF-8 with "surrogates escape" error mode makes sense here.
Python 3 uses it for decoding file-system paths, where it's not always
possible to determine the charset.  I think it's pretty much the same case.
After all, the %-coded bytes can be some binary data that's not possible to
reasonably decode with any charset.


-- 
Łukasz Rekucki

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

ModelMultipleChoiceField, clean and to_python

[Matt Hoskins]

The validation documentation for forms says that to_python on the form 
field is the first step in validation. I've written some code (the details 
of which don't really matter) which makes use of to_python on fields in 
doing so I discovered that "to_python" on ModelMultipleChoiceField doesn't 
work. The reason for this is that ModelMultipleChoiceField inherits from 
ModelChoiceField but then puts everything into "clean" and doesn't do 
anything about "to_python".

I would guess it was quicker/easier to put everything together in "clean" 
when the method was originally authored?

Given "to_python" is documented in forms as being a first step it feels to 
me untidy, at least, that this "to_python" is hanging around on 
ModelMultipleChoiceField in a non-working state and also that everything is 
put into "clean" - it would feel tidier to move the "to_python"-ish parts 
of ModelMultipleChoiceField out of "clean" and into "to_python". I also 
wonder if the "required" and "invalid_choice" tests from "clean" ought to 
be put into a "validate" method to make it consistent with how other fields 
behave, although I note from ModelChoiceField that an invalid choice cannot 
be converted to python since an instance can't be found for it so maybe 
to_python is the appropriate place for the invalid_choice test at least! I 
describe as "untidy" rather than as a bug as I'm not clear whether the 
documentation on validation is suggesting fields should have a "to_python" 
method and/or whether it's reasonable to expect "to_python" methods (if 
they exist) on form fields should work.

Worth me raising this as a ticket? Or is it a non-issue or there's a valid 
reason for keeping things as they are in ModelMultipleChoiceField's clean 
method?

Matt

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

Charset for URL decoding (#19468)

[Aymeric Augustin]

(complete version follows)

Hello,

I'm looking for some feedback on #19468 before making a decision. It's one
of the tickets that currently block the 1.5 release.

Here's a summary of the problem.

Django must decode environ['PATH_INFO'] to obtain request.path, where
decoding means :
  1 - URL-decoding to a bytestring
  2 - "charset-decoding" to an unicode string

The question is : which charset should be used in step 2?
settings.DEFAULT_CHARSET or utf-8 (hardcoded)?

Of course, since the default value of DEFAULT_CHARSET is utf-8, this only
makes a difference for the websites where it's been changed. They're
probably a minority.

Currently, Django uses utf-8. As far as I can tell, that's more a
side-effect of (ab)using force_str than anything else. It also has the
drawback of making it impossible to serve perfectly legit HTTP URLs such
as /caf%E9/ — try it: https://www.djangoproject.com/caf%E9/ — that returns
a 400 with no content. I think I once saw a ticket about this, but I can't
locate it right now.

If we switch to DEFAULT_CHARSET, we'll also have to change the reverse()
function and the {% url %} tag to honor DEFAULT_CHARSET when it encodes
URLs, so that URLs round-trip properly.

Arguments for DEFAULT_CHARSET / against UTF-8:
- The query string is already decoded with DEFAULT_CHARSET; it's weird to
decode different parts of the URL with different charsets (principle of
least astonishment).
- It should be possible to serve any valid HTTP URL with Django (see
example above).

Arguments for UTF-8 / against DEFAULT_CHARSET:
- Browsers default to UTF-8 when they open non-ASCII URLs.
- Everyone should use UTF-8 everywhere anyway; HTTP only allows non-ASCII
URLs for legacy reasons.

Do you have experience on this topic? What do you think?

-- 
Aymeric.

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