Re: Possible contrib.humanize addition

On Tuesday 05 January 2010 21:24:13 harrym wrote: > I'm working a templatetag that determines whether to use 'a' or > 'an' in front of English words. My particular use case for this is > in a tumblelog app I'm developing - many different types of entry > may be added (link, html, quote, etc),

Re: WSGI support in Django

Hi, I only drop in here every now and then. It may be worthwhile to mention that I never got the WSGi support fully working under Jython. I played with it under Geronimo and Tomcat. The mechanism used here is WSGI. The issue is not with Jython but with the way servlets handle POST data. The

Re: Possible contrib.humanize addition

> Hmm, can it handle the following? > >  an honest man >  a history book >  an historical book (debatable) It can't, the rules for the indefinite article around 'h' are complex and depend on the etymology of the word used. To add complexity the lexicographic rules are often different to the rules

Re: Possible contrib.humanize addition

On Wed, Jan 6, 2010 at 8:17 AM, sago wrote: > What is it about Django and NT scholars - have you come across James > Tauber (of Pinax fame?) There are at least three Django committers who can list one or another ancient Greek dialect among their studies. Not sure why

Re: Possible contrib.humanize addition

The code I've got so far works pretty well - I've tested it on some medium-sized corpora and the only times the expected result was different from the actual result was when the corpus was wrong. The code works by first checking a few specific rules for numbers and acromyns, then checking against

Re: Possible contrib.humanize addition

2010/1/6 sago : >> If you present some research to >> demonstrate how this tag could/would work for non-English languages, >> it would be a lot more compelling. > > That's not going to work, in any meaningful sense. That peculiarity of > the article is highly

Re: Possible contrib.humanize addition

More of an academic question, as it likely isn't a feasible solution for Django, but might a soundex solve this problem? Best I can tell, rules for articles, without exception, are based on the pronunciation of the following word.. Of course, phonology can be regional, subjective, and

Re: Design and code review requested for Django string signing / signed cookies

On Wednesday 06 January 2010 04:24:15 Elias Torres wrote: > Thanks Luke for your explanation. I think I have learned something > here in terms of my own application security independent of > Django's multi-app environment. Basically, you're reminding me > that as an application, I must be

cached template loader is new in trunk/1.2, docs does not mention that

http://docs.djangoproject.com/en/dev/ref/templates/api/#loader-types, I looked and could not find "cached.py" in Django-1.1.1/django/template/loaders. -- Amit Upadhyay www.amitu.com +91-9820-295-512 -- You received this message because you are subscribed to the Google Groups "Django

Re: cached template loader is new in trunk/1.2, docs does not mention that

Further, cached template loader does not reload template when template is modified. I am not complaining, just feel that it should me mentioned in the doc, as normal expectation when developing/deploying django is that one need not restart apache when template changes, not with cached template

Re: Design and code review requested for Django string signing / signed cookies

On Jan 6, 10:37 am, Luke Plant wrote: > On Wednesday 06 January 2010 04:24:15 Elias Torres wrote: > > Thanks Luke for your explanation. I think I have learned something > > here in terms of my own application security independent of > >  Django's multi-app environment.

Re: cached template loader is new in trunk/1.2, docs does not mention that

On Wed, Jan 6, 2010 at 10:24 AM, Amit Upadhyay wrote: > http://docs.djangoproject.com/en/dev/ref/templates/api/#loader-types, I > looked and could not find "cached.py" > in Django-1.1.1/django/template/loaders. There is a section for "django.template.loaders.cached.Loader".

Re: Design and code review requested for Django string signing / signed cookies

On Wednesday 06 January 2010 17:12:29 Elias Torres wrote: > > So that would be my defence of why it's better to put the > > "purpose" namespace into the key, rather than the value, in the > > context of HMAC. I'm not an expert though. > > Can a separator solve that issue? In that instance, yes.

Model validation incompatibility with existing Django idioms

A couple of related tickets filed today about model validation: http://code.djangoproject.com/ticket/12513 http://code.djangoproject.com/ticket/12521 The first one describes the issue best - the new model validation code breaks the following common Django convention: form = SecretQuestionForm(

Re: Model validation incompatibility with existing Django idioms

On Wed, Jan 6, 2010 at 12:49 PM, Simon Willison wrote: > A couple of related tickets filed today about model validation: > > http://code.djangoproject.com/ticket/12513 > http://code.djangoproject.com/ticket/12521 > > The first one describes the issue best - the new model

Re: cached template loader is new in trunk/1.2, docs does not mention that

On Wed, Jan 6, 2010 at 12:16 PM, Jeremy Dunck wrote: > On Wed, Jan 6, 2010 at 10:24 AM, Amit Upadhyay wrote: > > http://docs.djangoproject.com/en/dev/ref/templates/api/#loader-types, I > > looked and could not find "cached.py" > > in

Re: Possible contrib.humanize addition

On Jan 5, 9:24 pm, harrym wrote: > I'm working a templatetag that determines whether to use 'a' or 'an' > in front of English words. My particular use case for this is in a > tumblelog app I'm developing - many different types of entry may be > added (link, html, quote,

Re: Model validation incompatibility with existing Django idioms

I've only scanned the docs the other day and haven't actually used the new model validation stuff, so my impressions may be a little off, but... On Wed, Jan 6, 2010 at 2:54 PM, Joseph Kocherhans wrote: > On Wed, Jan 6, 2010 at 12:49 PM, Simon Willison

Using Django with Jinja2 and TEMPLATE_DEBUG=True

Hi, Maybe this question has already been asked, but I am wondering why Jinja2 compatibility can't be fixed in a clean way. Currently the code assumes that if an exception has a "source" attribute that it's a Django exception and can be processed as such. (the code:

Re: Model validation incompatibility with existing Django idioms

First time posting here, so please excuse me if my opinions aren't very useful and my bad English. 2010/1/6 Waylan Limberg > I've only scanned the docs the other day and haven't actually used the > new model validation stuff, so my impressions may be a little off, > but... > >

Re: Model validation incompatibility with existing Django idioms

On Wed, Jan 6, 2010 at 3:26 PM, Waylan Limberg wrote: > I've only scanned the docs the other day and haven't actually used the > new model validation stuff, so my impressions may be a little off, > but... > > On Wed, Jan 6, 2010 at 2:54 PM, Joseph Kocherhans

Re: Model validation incompatibility with existing Django idioms

On Jan 6, 2010, at 2:56 PM, Joseph Kocherhans wrote: > I had another idea that I think might work out. What if > ModelForm.validate() only validated fields on the form, like it worked > before the merge, and ModelForm.save() would automatically validate > the excluded fields, raising

Re: Model validation incompatibility with existing Django idioms

On Wed, Jan 6, 2010 at 4:06 PM, Brian Rosner wrote: > > On Jan 6, 2010, at 2:56 PM, Joseph Kocherhans wrote: >> I had another idea that I think might work out. What if >> ModelForm.validate() only validated fields on the form, like it worked >> before the merge, and

Re: Model validation incompatibility with existing Django idioms

On Jan 6, 2010, at 2:48 PM, Łukasz Rekucki wrote: > Maybe you could do something like this: > > with form.valid_model() as model: # i'm not good at inventing names > model.user = request.user > model.primary_contact = somecontact > > The valid_model() would be a context manager that

Re: Model validation incompatibility with existing Django idioms

On Wed, Jan 6, 2010 at 3:56 PM, Joseph Kocherhans wrote: ... >>> On Wed, Jan 6, 2010 at 12:49 PM, Simon Willison >>> wrote: ... form = SecretQuestionForm( {"secret_question":"foo", "answer":"bar"} ) if form.is_valid():    p =

Re: Model validation incompatibility with existing Django idioms

On Jan 6, 2010, at 3:46 PM, Jeremy Dunck wrote: > On Wed, Jan 6, 2010 at 3:56 PM, Joseph Kocherhans > wrote: > ... On Wed, Jan 6, 2010 at 12:49 PM, Simon Willison wrote: > ... > form = SecretQuestionForm( {"secret_question":"foo",

Re: Model validation incompatibility with existing Django idioms

On Wed, Jan 6, 2010 at 4:46 PM, Jeremy Dunck wrote: > On Wed, Jan 6, 2010 at 3:56 PM, Joseph Kocherhans > wrote: > ... On Wed, Jan 6, 2010 at 12:49 PM, Simon Willison wrote: > ... > form = SecretQuestionForm(

Re: Model validation incompatibility with existing Django idioms

On Jan 6, 3:57 pm, Brian Rosner wrote: > Yeah, I think that must have been a typo in Joseph's mail. The way I read it > that the model knows what fields it has already validated and the call to a > Model.save would validate the rest. Actually, I just realized that

Re: Model validation incompatibility with existing Django idioms

On Jan 6, 2010, at 3:59 PM, Joseph Kocherhans wrote: > On Wed, Jan 6, 2010 at 4:46 PM, Jeremy Dunck wrote: >> On Wed, Jan 6, 2010 at 3:56 PM, Joseph Kocherhans >> wrote: >> ... > On Wed, Jan 6, 2010 at 12:49 PM, Simon Willison

Message level API awkwardness

I realize I'm very late giving feedback on the API, sorry and feel free to ignore if I'm too late. That said, from the docs, the API to set the effective messaging level is awkward: == # Change the messages level to ensure the debug message is added. messages.get_messages(request).level =

user_passes_test decorator changes in 1.2

Hi there, I've just downloaded the 1.2 alpha and started testing it with one of my projects. For the most part it works well, however I've hit a bit of a snag due to the changes to the user_passes_test decorator in django.contrib.auth.decorators. I have a some code which follows the paradigm of:

Re: Using Django with Jinja2 and TEMPLATE_DEBUG=True

On Thu, Jan 7, 2010 at 2:54 AM, Rick van Hattem wrote: > Hi, > > Maybe this question has already been asked, but I am wondering why Jinja2 > compatibility can't be fixed in a clean way. Currently the code assumes that > if an exception has a "source" attribute that it's a

Re: Design and code review requested for Django string signing / signed cookies

On Jan 4, 4:47 am, Simon Willison wrote: > As you can see, the separator between the signature and the value > defaults to being a ':'. I plan to move it from being an argument on > the sign and unsign methods to being an argument to the Signer class > constructor.

Re: Message level API awkwardness

That sounds like a pretty simple addition that won't affect (m)any folks, so I'm fine with adding such a wrapper. I'd prefer the methods be called 'get_level' and 'set_level', however, so they're shorter and match the naming of 'get_messages'. Others? On Wed, Jan 6, 2010 at 6:09 PM, Jeremy

Re: user_passes_test decorator changes in 1.2

On Thursday 07 January 2010 00:12:08 gaz wrote: > However I thought I'd drop a line here since this isn't in the > backwards incompatible changes listed for 1.2 (I guess I'm possibly > already playing with voodoo, view_func isn't really documented so > it's my own fault I guess). Yes, that

.filter() results in non-serialized data

Hi As per my understanding the .all() query set method results in serialized data and .filter() does not is there a specific reason for this (helps me in understanding the query set methods more ) I had a problem and posted in

Re: Model validation incompatibility with existing Django idioms

It makes sense to me that the developer should first check that their form is valid and second check that their model object is valid when calling ModelForm.save(commit=False). This could be done by having the developer check the result of model.full_validate() before calling model.save(), or by

Re: Problem with history view in admin page

Russ, The indexing that Oracle is supporting is 'index-on-expression'. DB2 also supports that, but it isnt enabled for character long columns, since they hadnt had a request for that. I talked to the DB2 server folks about these use-cases and they have agreed to support this via

Re: Problem with history view in admin page

On Thu, Jan 7, 2010 at 2:02 PM, Mario Briggs wrote: > Russ, > > The indexing that Oracle is supporting is 'index-on-expression'. DB2 > also supports that, but it isnt enabled for character long columns, > since they hadnt had a request for that. I talked to the DB2 server

Re: Bug #11017: Oracle LIKEC query doesn't use index

On Tue, 2009-12-22 at 13:00 -0700, Ian Kelly wrote: > On Tue, Dec 22, 2009 at 12:58 AM, Jani Tiainen wrote: > > Escaping bug exists in Oracle 9.2.0.5 and earlier. It was fixed in > > patchset 9.2.0.6 and any later version. > > > > What comes to Oracle official support options