Improving Class based views names
Hi, I'm in the middle of re-factoring a pretty active open parliament project into 1.3. I've been an early adaptor of class based views, using it of Jacob's fork. Migration to the beta was quite smooth except for two names that broke my code: `pk` & `get_context_data`. The first comes from `models` and is now used instead of `object_id` in urls and views. It also broke compatibility with django-backlinks and I was forced to support both `pk` and `object_id` in the view wrapper, ugly. The second name can be rinsed and lose it's last 5 chars. Thanks, Benny -- 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.
State of X-Sendfile support?
Hi, I want to use X-Sendfile to serve some medium-sized files. There doesn't seem to be built-in support for this, although the soc2009/ http-wsgi-improvements branch looks like somebody attempted to implement HttpResponseSendFile (although it seems to use the slow path). Building a proper response manually is not the problem (since the apache extension does the content-type guessing and length calculation) but I would like an automatic fall-back so `manage.py runserver` doesn't put out an empty response leaking the header but serves the file like a proper server should. So: is there a class that detects the server and uses the X-Sendfile header if supported, or a branch where core.handlers.wsgi.WSGIHandler supports X-Sendfile? cheers, -- pascal -- 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.
dumpdata, json, management commands and utf8
./manage.py dumpdata --format=json
command produces unreadable output for non-ascii symbols now (they are
encoded as \u ).
Such encoding is not required according to http://www.ietf.org/rfc/rfc4627.txt
(section 2.5):
"All Unicode characters may be placed within the quotation marks
except for the characters that must be escaped: quotation mark,
reverse solidus, and the control characters (U+ through U+001F)."
There is a snippet ( http://djangosnippets.org/snippets/2258/ ) with a
quick fix but it is incorrect.
The encoding is performed by django.core.serializers.json.Serializer.
Output is not nice because ensure_ascii argument is not set (and it is
True by default):
def end_serialization(self):
simplejson.dump(self.objects, self.stream,
cls=DjangoJSONEncoder, **self.options)
It seems there is no way to pass additional options to serializer with
existing dumpdata command:
return serializers.serialize(format, objects, indent=indent,
use_natural_keys=use_natural_keys)
But wait, we can define custom serializers! This is undocumented but
quite easy:
# serializers/pretty_json.py
from django.core.serializers.json import Serializer as JSONSerializer
from django.core.serializers.json import Deserializer as
JSONDeserializer
from django.core.serializers.json import DjangoJSONEncoder
from django.utils import simplejson
class Serializer(JSONSerializer):
def end_serialization(self):
simplejson.dump(self.objects, self.stream,
cls=DjangoJSONEncoder,
ensure_ascii=False, **self.options)
Deserializer = JSONDeserializer
Then it can be added to SERIALIZATION_MODULES (by the way, this option
is not mentioned in serializer docs):
SERIALIZATION_MODULES = {'json-pretty': 'serializers.pretty_json'}.
After that, I expect this to work:
./manage.py dumpdata --format=json-pretty
But it doesn't work and fails with an UnicodeEncodeError:
Traceback (most recent call last):
File "./manage.py", line 11, in
execute_manager(settings)
File "/Users/kmike/envs/planor/src/django/django/core/management/
__init__.py", line 438, in execute_manager
utility.execute()
File "/Users/kmike/envs/planor/src/django/django/core/management/
__init__.py", line 379, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/Users/kmike/envs/planor/src/django/django/core/management/
base.py", line 191, in run_from_argv
self.execute(*args, **options.__dict__)
File "/Users/kmike/envs/planor/src/django/django/core/management/
base.py", line 229, in execute
self.stdout.write(output)
UnicodeEncodeError: 'ascii' codec can't encode characters in position
184-189: ordinal not in range(128)
Management commands write to stdout and python's stdout doesn't
perform any meaningful unicode encoding. Argh.
So self.stdout should be changed to something that understands utf8,
e.g.:
import sys
import codecs
from django.core.management.commands.dumpdata import Command as
Dumpdata
class Command(Dumpdata):
def execute(self, *args, **options):
stdout = options.get('stdout', sys.stdout)
options['stdout'] = codecs.getwriter('utf8')(stdout)
return super(Command, self).execute(*args, **options)
After these changes initial problem is solved.
But I think my adventure reveals something that can be improved in
django itself.
1) It is even mentioned in django docs (
http://docs.djangoproject.com/en/1.2/topics/serialization/#notes-for-specific-serialization-formats
) that "If you're using UTF-8 (or any other non-ASCII encoding) data
with the JSON serializer, you must pass ensure_ascii=False as a
parameter to the serialize() call. Otherwise, the output won't be
encoded correctly."
If I'm understanding properly, with ensure_ascii=True serializer
doesn't work for non-ascii bytestrings and produces ugly output for
unicode strings; with ensure_ascii=False serializer works for all
bytestrings and produces nice output for unicode strings. So why is
ensure_ascii=True default? Setting it to False is technically
backwards-incompatible but I think it is backwards-incompatible in a
good way.
2) If stdout doesn't handle Unicode, wouldn't it be better to wrap
'output' with smart_str or to wrap stdout itself to be utf8-capable by
default? django.core.management.base.BaseCommand.execute wraps data
written to self.stderr with smart_string, but this is not the case for
self.stdout.
After 1) and 2) the initial problem with non-readable fixtures will be
solved automatically without defining custom serializers and hacking
with management commands.
I'm not opening separate issues in bug tracker because they all seems
to be related (dumpdata improvements, serializer improvements,
BaseCommand unicode handling), the changes are not trivial (encodings
can be hard and stdout is often mysterious) and I want to make sure
I'm not missing a point.
--
You received this message because you are subscribed to the Google Groups
"Django developers"
Re: State of X-Sendfile support?
On Sunday, March 20, 2011, Pascal Germroth wrote: > Hi, > > I want to use X-Sendfile to serve some medium-sized files. There > doesn't seem to be built-in support for this, although the soc2009/ > http-wsgi-improvements branch looks like somebody attempted to > implement HttpResponseSendFile (although it seems to use the slow > path). > > Building a proper response manually is not the problem (since the > apache extension does the content-type guessing and length > calculation) but I would like an automatic fall-back so `manage.py > runserver` doesn't put out an empty response leaking the header but > serves the file like a proper server should. > > So: is there a class that detects the server and uses the X-Sendfile > header if supported, or a branch where core.handlers.wsgi.WSGIHandler > supports X-Sendfile? At present, there isn't any support for X-Sendfile. It is a feature that has been discussed at many times in the past, including the GSOC2009; however, nobody has ever carried it the last mile and got it into trunk. So; if you're interested, this is an area where you could make a contribution. Yours, Russ Magee %-) -- 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: Improving Class based views names
On Sunday, March 20, 2011, daonb wrote: > Hi, > > I'm in the middle of re-factoring a pretty active open parliament > project into 1.3. I've been an early adaptor of class based views, > using it of Jacob's fork. > > Migration to the beta was quite smooth except for two names that broke > my code: `pk` & `get_context_data`. The first comes from `models` and > is now used instead of `object_id` in urls and views. It also broke > compatibility with django-backlinks and I was forced to support both > `pk` and `object_id` in the view wrapper, ugly. The second name can be > rinsed and lose it's last 5 chars. Hi Benny, Thanks for the feedback. However, I'm a little confused as to what you are proposing. The names used by the generic views are (as far as I am aware) internally consistent within the views, and with the old generic views. The choice to use pk instead of object_id was quite deliberate, because every object responds to pk, but not necessarily to id. Compatibility with third party libraries isn't really a consideration unless the general community has converged on a convention which a new Django feature has blindly ignored. In this case, I would argue that pk is the convention, and Django-backlinks is in need of an update. Yours, Russ Magee %-) -- 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: Default project layout / directory structure
> I think, it's a good idea to add new option to startapp command There is django-extensions which has a create_app command that takes a --template switch. -- 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: Improving Class based views names
Hi Benny, On 03/19/2011 05:41 PM, daonb wrote: > Migration to the beta was quite smooth except for two names that broke > my code: `pk` & `get_context_data`. The first comes from `models` and > is now used instead of `object_id` in urls and views. It also broke > compatibility with django-backlinks and I was forced to support both > `pk` and `object_id` in the view wrapper, ugly. The second name can be > rinsed and lose it's last 5 chars. Those last five characters in "get_context_data" actually serve quite a useful purpose, IMO. They clarify that the return value is just the data that will go into building a context (a dictionary), as opposed to being the Context or RequestContext object itself, which is what I'd expect from a method named "get_context". Carl -- 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.
