this question belongs to django-user.
You need to use u'å' not 'å' in your python code.
> Is there a good reason
> why |force_unicode| and |lazy| do not use |smart_str|?
smart_str() creates a bytestring, but in Django everything is unicode until the
end. Only one of the last
steps is to encode
Hi!
I'm Piotr Grabowski, student from University of Wroclaw, Poland
In this Google Summer of Code I will deal with problem of customizable
serialization in Django.
You can find my proposal here https://gist.github.com/2319638
It's obviously not a finished idea, it's need to be simplified for
Hi Thomas,
You seem read my email too quickly. I do use u'å'. In force_unicode() and
lazy() Django runs str(u'å') which results in the exception(s). If it would
use smart_str instead, the exception would not happen. Am I missing
something?
Andrei
On Friday, April 27, 2012 9:11:19 AM UTC+2, g
On Apr 27, 11:14 am, Piotr Grabowski wrote:
> Hi!
>
> I'm Piotr Grabowski, student from University of Wroclaw, Poland
> In this Google Summer of Code I will deal with problem of customizable
> serialization in Django.
>
> You can find my proposal here https://gist.github.com/2319638
I quickly sk
W dniu 27.04.2012 10:36, Anssi Kääriäinen pisze:
On Apr 27, 11:14 am, Piotr Grabowski wrote:
Hi!
I'm Piotr Grabowski, student from University of Wroclaw, Poland
In this Google Summer of Code I will deal with problem of customizable
serialization in Django.
You can find my proposal here https
On Apr 27, 12:11 pm, Piotr Grabowski wrote:
> I didn't think about performance a lot. There will be regressions.
> Now serialization is very simple: Iterate over fields, transform it into
> string (or somethink serializable), serialize it with json|yaml|xml.
> In my approach it is: transform (Mode
Hey Piotr,
Thanks for the quick response.
> However sharing ideas and discuss how the API should look and work it
will be very desirable.
That'd be great, yup. I've got a couple of comments and questions about
bits of the API, but I'll wait until you've had a chance to post your
proposal t
W dniu 27.04.2012 12:39, Tom Christie pisze:
Hey Piotr,
> I quickly skimmed the proposal and I noticed speed/performance wasn't
mentioned. I believe performance is important in serialization and
especially in deserialization.
Right. Also worth considering is making sure the API can deal with
Hi!
I wrote a ticket about time zone warnings in date-based generic views:
https://code.djangoproject.com/ticket/18217
After some research, I understand that there are more problems with this views,
than I thought at first. django.views.generic.dates module uses aware and naive
datetime object
Hi,
I am Rohan Jain, a student from Indian Institute of Technology,
Kharagpur. I'll be doing a Google Summer of Code project with django
this year under the title "Security Enhancements". As the title
suggests, it has something to do with Security Enhancements: like
improvements in CSRF protection
Fantastic job on the performance benchmarks, the number 4-5 seconds per check
is scary. I’ve posted a comment on django-guradian in hopes the author can
chime in onto this conversation by posting
https://groups.google.com/forum/#!topic/django-developers/6UNjPu1mcgc/discussion.
Are there any
Hey guys, here's an important heads-up!
We're going to do the migration to GitHub today. This means we'll no
longer be committing code to our Subversion repository. Committers,
please hold off on making commits until the migration is done.
I expect it'll be done by late afternoon Chicago time. I'
woohoo! this is great, good luck Adrian
Brendan Smith, IT Specialist
National Priorities Project
http://www.nationalpriorities.org
http://www.facebook.com/nationalpriorities
413 584 9556
On Apr 27, 2012, at 12:50 PM, Adrian Holovaty wrote:
> Hey guys, here's an important heads-up!
>
> W
Hi Mike,
On 27 avr. 2012, at 14:51, Mike Yumatov wrote:
> I wrote a ticket about time zone warnings in date-based generic views:
> https://code.djangoproject.com/ticket/18217
It isn't necessary to notify django-developers when you create a ticket; that's
the job of django-updates.
> After some
I don't know the status of this project, but my guess is that you
shouldn't hold your breath for it.
Fortunately, there is Grappelli: https://github.com/sehmaschine/django-grappelli
We are currently working on making it compatible with django 1.4 (see
the "grappelli_2_4" branch)
Alternatively th
Hey all,
Yeah, you aren't missing anything — originally I wanted to wait for the
formrendering stuff, but that never panned out, and then I got busy.
Grappelli is lovely. Without knocking it at all, I think that the next version
of the admin should be as forward-looking as the last version, whi
On that note, why can't the fruits of Grappelli be used as a starting point?
-Original Message-
From: h3
Sent: Friday, April 27, 2012 4:01 PM
To: Django developers
Subject: Re: Django Admin Revamp - Any updates?
I don't know the status of this project, but my guess is that you
shouldn'
Although the Django tests all pass when run for the Python 3 port
under Python 3.2, I hit some problems when testing against recent
changes in the Python trunk (default branch, which will become 3.3).
Looking into these problems, I found that Django subclasses HTMLParser
and overrides parse_startta
Hello provides great protection from XSS by escaping output to
webpages, but it only does it in HTML context. XSS can be executed
when user input is inserted into javascript or CSS, which have
different context and rules than HTML, so HTML context escaping
doesn't help/protect.
Are there any remot
On Fri, Apr 27, 2012 at 11:50 AM, Adrian Holovaty wrote:
> We're going to do the migration to GitHub today. This means we'll no
> longer be committing code to our Subversion repository. Committers,
> please hold off on making commits until the migration is done.
>
> I expect it'll be done by late
>
> Are there any hopes of speeding up or caching GenericForgeinKey queries ?
> I found -
> http://zerokspot.com/weblog/2008/08/13/genericforeignkeys-with-less-queries/
>
>
Adding 'db_index=True' to the GenericForeignKey's object_id field should be
a significant performance enhancement. It w
Wow this is awesome! Congrats on the change! Very excited to be able to
contribute a Pull Request or two!
On Friday, April 27, 2012 9:50:01 AM UTC-7, Adrian Holovaty wrote:
>
> Hey guys, here's an important heads-up!
>
> We're going to do the migration to GitHub today. This means we'll no
> lon
Hi Tom,
On Friday, 27 April 2012 at 12:44 PM, Tom Christie wrote:
> Seeing another proposal for Customizable Serialization for the GSoC this year
> prompted me to dust off the bits of work I've done along similar lines.
> I'd really like to see this get properly addressed in core and I thought it
On Fri, Apr 27, 2012 at 11:50 AM, Adrian Holovaty wrote:
> We're going to do the migration to GitHub today. This means we'll no
> longer be committing code to our Subversion repository. Committers,
> please hold off on making commits until the migration is done.
OK, it's live!
https://github.com
Hi Aymeric,
On Friday, April 27, 2012 at 9:21 PM, Aymeric Augustin wrote:
> > After some research, I understand that there are more problems with this
> > views, than I thought at first. django.views.generic.dates module uses
> > aware and naive datetime objects together, which breaks all date-
On 28 avr. 2012, at 07:56, Mike Yumatov wrote:
>> They are in local time in the default time zone.
> Are you sure? Because if so, YearArchiveView is broken: it uses year lookup
> (https://docs.djangoproject.com/en/1.4/ref/models/querysets/#year), which is
> performed in UTC.
Indeed, you're rig
Adrian,
Thank you. Well done. Awesome. :-)
On Fri, Apr 27, 2012 at 11:08 PM, Adrian Holovaty wrote:
> On Fri, Apr 27, 2012 at 11:50 AM, Adrian Holovaty wrote:
>> We're going to do the migration to GitHub today. This means we'll no
>> longer be committing code to our Subversion repository. Co
On 28 avr. 2012, at 00:49, Vinay Sajip wrote:
> From the discussion on python-dev, it seems possible that an optimal
> fix might require changes both in Python and in Django. Before
> creating a ticket about this for Django, I would like to get an
> opinion about this from the Django committers - s
28 matches
Mail list logo
