django.utils.html.urlize and mark_safe

hi, i think there is some use of unnecessary mark_safe in the above-mentioned function, but maybe i am overlooking something, so i thought before opening a ticket i will discuss it here. if you check the urlize-function https://github.com/django/django/blob/master/django/utils/html.py#L173, it

Re: jQuery.tmpl() and Django

On Fri, May 27, 2011 at 7:04 AM, Sean O'Connor wrote: > A better approach would for Django to provide some tools and documentation > to help people work around the conflict.  One easy solution would be to > provide a verbatim tag like what ericflo wrote > at 

Re: ticket 10032, joins and isnull=True

On Mon, May 11, 2009 at 6:22 PM, Malcolm Tredinnick wrote: > The choice to be made in an API implementation of this kind is whether > NULL checks on fields in related models implies a related instance > exists or not. Django follows SQL there and doesn't insist that a >

Re: ticket 10032, joins and isnull=True

On Mon, May 11, 2009 at 11:37 AM, Michael Radziej <m...@noris.de> wrote: > > On Mon, May 11, Gábor Farkas wrote: > >> Group.objects.filter(person__stamp__isnull=True) >> >> i get an OUTER JOIN, >> >> but if i do this: >> >> Group.object

ticket 10032, joins and isnull=True

hi, i'd like to discuss ticket 10032, because it was closed as WONTFIX, and i think the issue i raised was somehow misundersood, perhaps i explained it the wrong way. the problem is that i'm filtering a queryset by doing a join using a foreign-key in the "opposite way", and django sometimes

Re: Proposal: enable CSRF middleware by default

On Thu, Mar 19, 2009 at 9:53 AM, Thomas Guettler wrote: > > The CSRF middleware inserts a hidden input element in every form. > > Since GET Requests are mostly readonly, the bad guy needs a POST > request to do some evil. > > If the bad guy can make a POST request > with the

Re: How do you handle cascading deletes in your production apps?

On Fri, Dec 12, 2008 at 2:48 AM, James Bennett wrote: > > On Thu, Dec 11, 2008 at 7:06 PM, Simon Litchfield wrote: >> +1. Definitely need some kind of cascade=False option somewhere. I'd >> argue it should be the default. I have some production horror

Re: 1.1 feature: unify access to response.context in test client

On Sun, Nov 9, 2008 at 3:48 AM, James Bennett <[EMAIL PROTECTED]> wrote: > > On Sat, Nov 8, 2008 at 5:34 PM, Russell Keith-Magee > <[EMAIL PROTECTED]> wrote: >> However, to clarify - are you talking about a backwards incompatible >> change, or are you talking about putting a backwards compatible

Re: RFC: Django 1.0 roadmap and timeline

On Thu, Jun 12, 2008 at 4:03 AM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > "Maybe" features > > . . . > > 5. Model-level validation (#6845). hi, it always seems quite ugly, that you can create a model with invalid data, and save it. so when you want to validate it's

Re: Django releases

On Mon, Jun 9, 2008 at 11:02 PM, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > On Sat, Jun 7, 2008 at 2:06 PM, Jacob Kaplan-Moss > <[EMAIL PROTECTED]> wrote: >> * Start a "train release" schedule: schedule a couple of 1.0 betas, a >> rc or two, and then a final release. Features that are done by

Re: add support for unicode-normalizing get/post-data?

J. Cliff Dyer wrote: > On Thu, 2008-04-10 at 20:26 +0200, Gábor Farkas wrote: >> the point is,that in my opinion, 99% of all developers want to have >> their unicode-data normalized, before they process it. (maybe they >> don't know yet that they want it, but they want it :-)

Re: add support for unicode-normalizing get/post-data?

ould require that i copy the convert-get-post-data-to-unicode code from django. which seems to be quite ugly and can cause errors/incompatibilities in the future. gabor > > On Apr 10, 11:26 am, Gábor Farkas <[EMAIL PROTECTED]> wrote: >> On Thu, Apr 10, 2008 at 06:44:35AM -0700,

Re: add support for unicode-normalizing get/post-data?

On Thu, Apr 10, 2008 at 06:44:35AM -0700, simonb wrote: > > On Apr 10, 2:48 pm, Gábor Farkas <[EMAIL PROTECTED]> wrote: > > hi, > > > > would it be a good idea to add support to django to unicode-normalize > > incoming get/post-data? > > class NormC

Re: add support for unicode-normalizing get/post-data?

Amit Upadhyay wrote: > On Thu, Apr 10, 2008 at 12:18 PM, Gábor Farkas <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > p.s: if there is a way to achieve this without touching > django-internals, please tell me :) > > > I would have

add support for unicode-normalizing get/post-data?

hi, would it be a good idea to add support to django to unicode-normalize incoming get/post-data? the normalization problem is basically this: for example my name, 'gábor' can be written in 2 different ways in unicode: u'g\xe1bor' and u'ga\u0301bor'. the first one uses the 'LATIN SMALL

Re: Django 1.0 features -- the definitive list

Simon Willison wrote: > I'd love to have a simpler alternative to the regexp method that is > more friendly for developers who haven't fully grokked regular > expression syntax yet. while i agree that simplifying things is always a good idea, i think that "developers who haven't fully grokked

Re: using "select_related" .Does it works?

Greg_IAP wrote: > Hello, > > i'm trying to understand how the method "select_related" works and it > doesn't seems to... > > Does someone could explain to me how to make it work? > several examples on the net show that it doesn't... just a small note: if you use select_related, make sure that

Re: psycopg (both 1 and 2) may drop support for multiple interpreters (used by mod_python and mod_wsgi)

thanks, gabor > > Graham > > On Oct 22, 5:20 pm, Gábor Farkas <[EMAIL PROTECTED]> wrote: >> Graham Dumpleton wrote: >>> They have now committed changes in relation to this: >>> http://www.initd.org/tracker/psycopg/changeset/902 >>> On visua

Re: psycopg (both 1 and 2) may drop support for multiple interpreters (used by mod_python and mod_wsgi)

Graham Dumpleton wrote: > They have now committed changes in relation to this: > > http://www.initd.org/tracker/psycopg/changeset/902 > > On visual inspection the changes look to do what I was suggesting. > hmm.. could you please summarize the situation? in other words, what problems am i

QueryDict.update : should it support MultiValueDict?

Hi, before the unicode-change, QueryDict.update handled also updating from a MultiValueDict (where on a key there might be several values) correctly. but now it does not support it correctly, so if you are updating a QueryDict with a MultivalueDict (for example a request.GET which contains a

Re: delete-object, cascading

Russell Keith-Magee wrote: > On 8/23/07, Gábor Farkas <[EMAIL PROTECTED]> wrote: >> hi, >> >> i posted this one week ago, could someone with commit access please >> respond to it? > > If we're haven't addressed these tickets, it's not because we d

Re: delete-object, cascading

hi, i posted this one week ago, could someone with commit access please respond to it? thanks, gabor Gábor Farkas wrote: > hi, > > when django deletes an object (using the object's delete() method), > then all related objects are also deleted. > > this is not a

delete-object, cascading

hi, when django deletes an object (using the object's delete() method), then all related objects are also deleted. this is not always a good thing. there are various approaches to solve this, like: http://code.djangoproject.com/ticket/1007 and http://code.djangoproject.com/ticket/2288 , but

Re: Request data encoding

Jacob Kaplan-Moss wrote: > On 8/2/07, Daniel Brandt <[EMAIL PROTECTED]> wrote: >> I am recieving POST-data that is submitted to my application not via a >> form or a browser, but from other web applications, according to a >> known protocol. This data may or may not have the charset of the data

Re: How submit a patch with files not in subversion?

David Danier wrote: >> The point is that I don't have write permissions on the subversion >> tree... > > If you want to keep a log of your changes try using some decentralized > version control system. I use svk, but git/mercurial/darcs/... might > work similarly. I prefer svk, because it

Re: DecimalField and 'decimal' module.

oggie rob wrote: >>> does this also affect psycopg1? >> Looking at psycopg1 code, the answer would appear to be that it is not >> affected. Changes to support Decimal appear to be psycopg2 specific. >> >> Graham > > The problems I was seeing the other day were repeatable both using > strictly

Re: DecimalField and 'decimal' module.

Graham Dumpleton wrote: > > The reason I am asking is that there were recently problems found with > pyscopg2 module and its support for use of decimal.Decimal type. In > practice this only affects people who use mod_python or mod_wsgi and > run two different Django application instances in two

Re: Unicode and pickles

Michael Radziej wrote: > Hi, > > I think I've hit a show stopper. > > I'm still porting my application to Unicode ... well, before the > unicode > changes it was possible to use a TextField for pickles, like > contrib.Session > does (Session.session_data). > > But pickling gives a bytestring,

Re: Unicode Keys

David Cramer wrote: > Is there any reason why its storing the keys in QueryDict (possibly > others) as unicode? > i think it's for consistency. i mean, when i see mentioned that django is fully unicode, i assume every string i get from django is in unicode, unless there's a very good reason for

Re: urlconf, strings vs. callables

Malcolm Tredinnick wrote: > On Tue, 2007-07-10 at 09:20 +0200, Gábor Farkas wrote: >> hi, > >> i'm always using the "pythonic" way (import the view function, and give >> it to the urlconf), and assumed that this is the recommended way. >> >> but

Re: Tests 'datatypes' fail

Michael Radziej wrote: > On Thu, Jun 28, Gábor Farkas wrote: > >> Michael Radziej wrote: >>> I use git-svnimport to sync the svn with my git repository, and it seems to >>> fail around every 6 months under unknown circumstances (probably something >>> wi

Re: Tests 'datatypes' fail

Michael Radziej wrote: > > I use git-svnimport to sync the svn with my git repository, and it seems to > fail around every 6 months under unknown circumstances (probably something > with merges) maybe try to use 'git-svn'... it seems that the development for 'git-svnimport' has stopped. p.s:

Re: Unicode field names

Noam wrote: > telephone = CharField(u'טלפון', maxlength=30) > > However, it causes the admin app to fail with a nasty > UnicodeDecodeError. > as Malcolm wrote already, the unicode-branch will solve this, but for now, try to use a bytestring in your application's encoding there. so, for

Re: unicode-branch: string handling

Malcolm Tredinnick wrote: > > What I'd really like from you guys (Michael, Ivan, Gábor -- and anybody > else who wants to play along) is to see how the code fits in with your > existing workflow. What are the bits that are still hard for you? What > are the problems that aren't solved? I'm

unicode-branch: string handling

hi, i've been reading http://code.djangoproject.com/wiki/StringEncoding, and the idea seems to be, that for "Passing Strings Between Django and the Developer's Code", django will/should accept both utf-8 encoded byte-strings, and unicode-strings. wouldn't it be simpler to only accept

Re: Stack trace in DB comments

Ned Batchelder wrote: > I think it would be a great idea. I have used similar tracing > facilities in other (non-Django) projects, and they were invaluable for > quickly zeroing in on the pathological code that swamped the performance. > > I don't know what the feeling of the devs is on

Re: Can't handle newforms

xgdlm wrote: > Thanks for your reply Malcolm > >> Hmm... this precise example works for me. Are you using a reasonably >> recent release (like 0.96)? I remember there was a unicode fix that went >> in not too long ago to add smart_unicode() calls in various places for >> things just like this. >

Re: Django not thread-safe?

Michael Radziej wrote: > Hi, > > Jacob states in Ticket #3357 [1] that Django were far from being > thread-safe. But on the other side, Django > is able to run as threaded > fastcgi-server i think this part is the one where we have to be more exact. does that mean that : "it is guaranteed

Re: triage: Problem for the up-loading of non-ASCII character file name.

Michael Radziej wrote: > Gábor Farkas: >> >> 1. we do not mandate yet that GET/POST data is in settings.DEFAULT_CHARSET > > We don't mandate any particular encoding in > settings.DEFAULT_CHARSET? Take a look at ticket #951 and the recent > discussion about it her

Re: triage: Problem for the up-loading of non-ASCII character file name.

Michael Radziej wrote: > Gábor Farkas: >> Michael Radziej wrote: >>>* What encoding does python use if you pass unicode to open()? >> for os.listdir it uses sys.getfilesystemencoding(), so i assume it does >> the same for open(). >> >> so usually

Re: triage: Problem for the up-loading of non-ASCII character file name.

Michael Radziej wrote: > Hi Tsuyuki! > > tsuyuki makoto: >> Proposed solution: punicode conversion before call >> django.util.text.get_valid_filename. > > Why punycode? I'd think that most filesystems these days support UTF-8 > (though, with different normalization, which *is* a problem). > >

Re: Unicode or strings in models

Ivan Sagalaev wrote: > Splitting this into new thread since it's already not about db client > encodings... > > ak wrote: >> So if everyone agreed, the way is simple: >> 1. when django loads data from db and fills in a model object, all >> strings have to be encoded according to

raw_id_admin, move from "admin" to "forms"?

hi, (first i apologize if this was already discussed or solved. i could not find anything about it in the newsgroup-archives) i've seen that one of the latest commits did some changes to the "raw_id_admin" attribute. for the admin this is fine, but there is also an another aspect of

Re: unicode issues in multiple tickets (#952, #1356, #3370) and thread about Euro sign in django-users

Julian 'Julik' Tarkhanov wrote: > > > Python's unicode is actually UTF-16 sorry, but no. it's not utf-16. it's decided at compile-time, and i'ts either utf-32 or utf-16. on linux it's usually utf-32, and on windows it's usually (always?) utf-16. but you should not care about it. you see,

Re: UNICODE and newforms

Honza Král wrote: > Hi there, > > I have been playing around with newforms for some time. since I don't > come from an English speaking country, I did also put the unicode > stuff to the test. > > It has bitten me on several occasions. I agree that I am not used to > python unicode strings, but

regarding commit 4170

hi, after i've read this blog post: http://superjared.com/entry/urgent-upgrade-django-if-deployed-fastcgi/ i also became a little nervous because i also have a fastcgi-backed website. but the problem is, i am unable to reproduce this problem. actually i use a custom fastcgi script ( the

Re: Default representation of a Form

Adrian Holovaty wrote: > On 12/10/06, Gary Wilson <[EMAIL PROTECTED]> wrote: >> What if instead of adding various as_* methods that we have a >> FormFormatter class that determines how the form displays. The >> _html_output and as_* methods would become FormFormatters. Formatter >> could be a

Re: Have a look at django.newforms

Adrian Holovaty wrote: > On 11/30/06, gabor <[EMAIL PROTECTED]> wrote: >> but if i want to render it in a template and it contains non-ascii text, >> it fails in /home/gabor/src/django/django/template/__init__.py, >> line 745, UnicodeEncodeError. >> >> the code there calls str() on the form, and

Re: Branch Merges?

Jay Parlar wrote: > On 11/6/06, David Blewett <[EMAIL PROTECTED]> wrote: >> I would like to suggest that the branches that are felt to be complete >> sans testing be merged into a single branch. I am anxiously awaiting >> several different branch merges to core but do not have time to check >>

Re: content types

Malcolm Tredinnick wrote: > On Fri, 2006-11-03 at 22:19 +, Rob Hudson wrote: >> Jacob Kaplan-Moss wrote: >>> Try this:: >>> >>> from innovate.innovation.models import Innovation >>> from django.contrib.contenttypes.models import ContentType >>> >>> i = Innovation.objects.get(id=1)

Re: Call for comment: Forms/manipulator replacement, take 1

Adrian Holovaty wrote: > Hello all, > > I've attached the first draft implementation of the manipulator > replacement framework -- it's just a single Python module. > > * All output is Unicode. I did this because eventually Django's > internal strings will all be Unicode, and we might as well

Re: Why doesn't models.Manager implement __iter__?

Russell Keith-Magee wrote: > On 10/11/06, Gábor Farkas <[EMAIL PROTECTED]> wrote: >> Russell Keith-Magee wrote: > >> sorry, but is this the description of the __iter__ case, or the >> iterator() case? > > Now that you mention it (looks furiously at code

Re: Why doesn't models.Manager implement __iter__?

Russell Keith-Magee wrote: > >> somehow i assumed that the QuerySets never load in the whole result-set, >> except when they are forced (cast to list for example). but now i see >> that of course, if you cache the results, then you will have all the >> results in memory anyway... > > This is

Re: Automatic-manipulator, very slow..... design-decision/bug/misunderstanding?

Ivan Sagalaev wrote: > Gábor Farkas wrote: >> now, when you call Owner.AddManipulator(), he's going to fetch the WHOLE >> Thing-table. just to construct the AddManipulator. > > I've seen that in one of my projects and fixed it by filtering out > unneeded selected wit

Re: Automatic-manipulator, very slow..... design-decision/bug/misunderstanding?

Michael Radziej wrote: > Gábor Farkas wrote: >> = >> class Owner(Model): >> name = CharField(maxlength=500) >> thing = ForeignKey(Thing) >> = >> >> now let's say you have a LOT of T

Automatic-manipulator, very slow..... design-decision/bug/misunderstanding?

hi, yesterday i was bitten by something in the manipulator-behaviour, which i did not really expect to work that way...and i'm now not sure if i should submit a bugreport, or it should behave like that. also, it's quite possible that i understood this wrong, if that's the case please correct

Re: [Fw]The Python Web Framework

James Bennett wrote: > > 2. Admittedly I don't have a whole lot of experience in the area, but > creating and managing a pool of connections to be passed from thread > to thread just feels like much more hassle and overhead than we really > need, especially since there are external pooling

Re: django unicode-conversion, beginning

Bill de hÓra wrote: > gabor wrote: > >> so what do you think about the following approach: >> >> try ascii-decoding >> if fails, try utf8-decoding >> if fails do iso-8859-1-decoding (this cannot fail). >> >> ? > > Dumb question maybe. How do you know this encoding ladder will work? it depends

Re: Model inheritance API

Bill de hÓra wrote: > Malcolm Tredinnick wrote: > >> table design with >> lots of sparse columns won't get me invited to the cool parties. > > Qotd! > (added to my quotes-collection :-) gabor --~--~-~--~~~---~--~~ You received this message because you are

Re: urlify.js blocks out non-English chars - 2nd try?

Jeroen Ruigrok van der Werven wrote: > On 7/16/06, gabor <[EMAIL PROTECTED]> wrote: >> i think we do not need to discuss japanese at all. after all, there's no >> transliteration for kanji. so it's imho pointless to argue about >> kana-transliteration, when you cannot transliterate kanji. > > If

Re: django-unicode conversion, first experiments, questions

Simon Willison wrote: > > On 19 Jul 2006, at 13:19, Ivan Sagalaev wrote: > >> Talking about QUERY_STRING... While the string itself is in ASCII >> it has >> urlencoded data and there the encoding matters. As fas as I can see in >> practice browsers tend to encode those data in the same

Re: django-unicode conversion, first experiments, questions

Bill de hÓra wrote: > gabor wrote: > >> questions: >> 1. django publishes the whole environ dictionary as request.META. the >> environ dictionary is a normal byte-string dictionary. so, should we >> convert it to unicode so that the request.META dictionary only contains >> unicode strings? >>

Re: urlify.js blocks out non-English chars - 2nd try?

Antonio Cavedoni wrote: > On 17 Jul 2006, at 8:25, tsuyuki makoto wrote: >> We Japanese know that we can't transarate Japanese to ASCII. >> So I want to do it as follows at least. >> A letter does not disappear and is restored. >> #FileField and ImageField have same letters disappear problem. >>

"allow tags" attribute. stays/vanishes? :)

hi, i've found (by browsing the source-code), that if i want to put raw html code into a column in django.contrib.admin's list views, i can do it by setting the allow_tags attribute to true for the given "something" :) but this feature is not documented, so before i use it in an application,

Re: Test framework for end-user applications

Michael Radziej wrote: > Gábor Farkas wrote: >> regarding running a "fake" webserver.. did you look at twill? > > But it does not allow to test against the context! > yes, that's why i said 'regarding running a "fake" webserver' :-) but it offers t

Re: Test framework for end-user applications

Simon Willison wrote: > > On 12 Jul 2006, at 02:28, Malcolm Tredinnick wrote: > >> I approached things from a different direction, though, more >> concentrating on how to unit test templates and views (as in not >> requiring a full end-to-end application setup in order to test >> them). So >>

Re: Unicodification of Django

Gábor Farkas wrote: > Jacob Kaplan-Moss wrote: >> >> So I think -- for now -- there are more important places to spend our >> energy. > > > 2. 'to spend our energy'. i think it's a little more complicated. if > someone is willing to help-with/work-on

Re: Unicodification of Django

Jacob Kaplan-Moss wrote: > On Jun 28, 2006, at 6:07 AM, Gábor Farkas wrote: >> what i think we are missing the most is to hear about the "main" >> developers (project owners?) (adrian, malcolm, jacob etc.) opinion >> about >> unicode-ification. if they thi

Re: Unicodification of Django

hugo wrote: > Hi, > >> So, what's stopping Django from switching to unicode? Is someone working on >> it? And finally, what should I do to see my sweet Django fully >> unicode-aware? :) > > Well, as a start, take a look at the impact analysis page at >

Re: RFC: Django history tracking

Uros Trebec wrote: > class Post(models.Model): > author = models.CharField(maxlength=100) > title = models.CharField(maxlength=100) > content = models.TextField() > date = models.dateField() hi, sorry to jump in so late into the

Re: using URLs that do not contain the primary key

[EMAIL PROTECTED] wrote: > Fist up, apologies if I'm posting this in the wrong place and apologies > if this issues is covered somewhere else -- I searched for it but > couldn't find the answer I was looking for. > > OK, I'm new to Django but have a quick, hopefully easy-to-answer > question, >

Re: Proposal: default escaping

Simon Willison wrote: > > > The ideal situation would be for auto_escape to be on by default, and > let templates turn it off if they need to. This has serious backwards > compatibility issues however. the official opinion is that there's no backward-compatibility guarantees before 1.0

Re: unicode.. reject?

Ivan Sagalaev wrote: > gabor wrote: > >> for example, i was building a very simple web-file-manager. you can ask >> python to get you the os.listdir, etc, data in unicode, which i think >> the only sensible way, because otherwise you have to watch out for the >> filesystem-encoding. but

Re: slicing ignores Meta_ordering?

Gábor Farkas wrote: > hi, > > is it intentional that slicing a queryset ignores the Meta_ordering? > > for example: > > > class Thing(Model): > name = SlugField() > pub_date = DateTimeField() > > class Met

slicing ignores Meta_ordering?

hi, is it intentional that slicing a queryset ignores the Meta_ordering? for example: class Thing(Model): name = SlugField() pub_date = DateTimeField() class Meta: ordering = ['-pub_date'] >>>

Re: reverse-lookups, strange behaviour

Jorge Gajon wrote: >> from proj1.app1.models import User >> User.objects.get(poll__question__exact='x') > >> from app1.models import User >> User.objects.get(poll__question__exact='x') > > > I don't see any difference except for the 'from' statement. well, that's it :) > What 'reverse

Re: Suggestion: Better slugifying of scandinavic characters

Malcolm Tredinnick wrote: > On Tue, 2006-05-16 at 09:00 +0200, Gábor Farkas wrote: >> Jeroen Ruigrok van der Werven wrote: >>> On 5/16/06, Ville Säävuori <[EMAIL PROTECTED]> wrote: >>>> I think that this problem applies in most european languages, too. >&g

Re: Suggestion: Better slugifying of scandinavic characters

Jeroen Ruigrok van der Werven wrote: > On 5/16/06, Ville Säävuori <[EMAIL PROTECTED]> wrote: >> I think that this problem applies in most european languages, too. >> Like, say, Swedish, German and French. > > The same appliesa for Dutch where we use trema's (sort of umlauts) to > denote any

Re: Ideas for /examples/ directory

Jacob Kaplan-Moss wrote: > On Apr 18, 2006, at 3:30 AM, Amit Upadhyay wrote: >> How about shipping a prepopulated sqlite db? To avoid dependency I >> recommend splitting the distribution in django, and django-dev? >> django, bare minimum for deployment, django-dev with examples and >>

Re: magic-removal: plans/estimates for the trunk-merge?

Adrian Holovaty wrote: > On 3/27/06, binaryfeed <[EMAIL PROTECTED]> wrote: >> What's most frustrating about this thread is that no one has responded, >> really. I mean, it'd be great to know if it was going to be a matter >> of days, weeks, or months. Much as I search for it, this information

Re: magic-removal: plans/estimates for the trunk-merge?

ChaosKCW wrote: > This is a common thread :-) and one I am interested in, but you can > search the forumn for the results. Bascially it will be done when its > done it seems :-) > i'm following the forums, and i knew that probably the answer would be when-its-done :-( just wanted to make sure,

Re: templates and html escaping

Gábor Farkas wrote: > Jacob Kaplan-Moss wrote: >> On Mar 2, 2006, at 3:16 PM, Michael Radziej wrote: >>> Now, did I miss something and is this already fixed? Should this be >>> treated differently? How do other people handle this? >> >> The problem

Re: templates and html escaping

Jacob Kaplan-Moss wrote: > On Mar 2, 2006, at 3:16 PM, Michael Radziej wrote: >> Now, did I miss something and is this already fixed? Should this be >> treated differently? How do other people handle this? > > The problem in the admin was fixed in [1982]: http:// >

Re: Congrats on great framework

Adrian Holovaty wrote: > On 2/23/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> I still thing Java has it place in heavyweight Enterprise applications >> and dealing with integration concerns BUT for everything else there is >> perhaps Python and cool frameworks like Django... >> >> Django

Re: Proposal: Validation-aware models

kmh wrote: >> This breaks semantics of a property of an object: you should be able to >> read exactly what you just set. Imagine explaining this magic to a newbie: >> >> c.crime_date = request.POST['crime_date'] ## user submits '2006-1-2' >> if c.crime_date == '2006-1-2': ## false! >>

Re: sending mail in utf-8

Maniac wrote: Jeroen Ruigrok van der Werven wrote: Makes sense given the recent push for making the Django core UTF8. No, recent push is to make Django core Unicode (arrays of 2-byte normalized characters). well, it's not always 2bytes (usually it's 4bytes). (sorry, couldn't resist :)

Re: Proposal: Django should support unicode strings

hugo wrote: i understand that django's architecture should use unicode because it's the better way, but from the "outside"... what functionality is not working fine with non-english characters? currently you are up to your own to turn the unicode strings returned from those into utf-8

Re: Proposal: Django should support unicode strings

hugo wrote: I think that Django should support(use only) python unicode strings. Since the work needed would be a bit involved (not the actual work, I think, but finding and fixing all relevant places), I set up a wiki page to collect places and procedures regarding unicodefication. I think