capfirst and title template filters
Gary Wilson
simply use the capitalize() and title() str methods?
The difference with capfirst is that it capitalizes the first character
without touching the others
>>> Template("{{ name|capfirst }}").render(Context({"name": "DOLORES"}))
'DOLORES'
whereas str.capitalize() will capitalize the first character and also
lower case the others
>>> "DOLORES".capitalize()
'Dolores'
The difference with title is that it lower case the character after a
single quote after a lower case character
>>> Template("{{ name|title }}").render(Context({"name": "de'errico"}))
"De'errico"
whereas str.title() will capitalize both
>>> "de'errico".title()
"De'Errico"
So why the special cases? Should we keep the filters consistent with
their str methods?
lower -> str.lower()
upper -> str.upper()
title -> str.title()
Should we rename capfirst? Or introduce a capitalize filter?
capitalize -> str.capitalize()
Gary Wilson
> So why the special cases? Should we keep the filters consistent with
> their str methods?
I did realize an example where the title filter's implementation would
be desired. When you've got a possessive noun:
>>> Template("{{ text|title }}").render(Context({"text": "the boy's blob"}))
"The Boy's Blob"
as opposed to:
>>> "the boy's blob".title()
"The Boy'S Blob"
Waylan Limberg
I think you just answered your own question here. It seems more likely
that "boy's" would need proper treatment than "de'errico" because the
name is more likely to already be properly capitalized when entered.
And with the current filters, as you point out, that proper
capitalization won't be altered. Hey, if someone types in their name
wrong, we shouldn't be expected to fix it, or even know how. 'Garbage
in, garbage out' (tm).
>
> >
>
--
----
Waylan Limberg
way...@gmail.com
Gary Wilson
Well, I'm trying to find out what the author is trying to correct here.
There is no comment explaining the special handling. For example, if
the intent is only to correct str.title()'s handling of possessive
nouns, then the regular expression should maybe be r"[a-z]'S\b"
instead.
My main issue with the title filter, though, was that if we are naming
filters the same as str methods, then they should probably be
consistent with the function of the str method they are mimicking. For
example, I believe capfirst filter is rightly not named capitalize
since it isn't consistent with str.capitalize's behavior.
My main issue with the capfirst filter is not really an issue with
capfirst, but rather the lack of a capitalize filter that behaves like
str.capitalize. I have some text that is stored in all caps and would
like to capitalize the first character AND lowercase the remaning. The
capfirst filter does not give me that.
So, I am proposing:
1) Adding a capitalize filter that mimicks str.capitalize.
2) Adding comments as to why the title filter doesn't simply return
the output from str.title.
3) Renaming the current title filter and adding a title filter that
mimicks str.title.
4) Removing the capfirst filter if 1) is implemented.
I'm +1 on 1 and 2.
I'm -0 on 3 since I can live with the special handling, as long as it's
commented. The special handling is probably desired the majority of
the time. Has anyone ever had issues with the special handling?
I'm +0 on 4.
tamara6
> 1) Adding a capitalize filter that mimicks str.capitalize.
> 2) Adding comments as to why the title filter doesn't simply return
> the output from str.title.
> 3) Renaming the current title filter and adding a title filter that
> mimicks str.title.
> 4) Removing the capfirst filter if 1) is implemented.
>
The current filters work for me as they are, and I can see how changing
them may cause problems for me (capfirst will not convert an acronym
like NASA to lower case, whereas capitalize will).
But why don't you just create your own capitalize filter (or titlecase
filter) for yourself? Then you'll know that you'll get exactly the
functionality that you need and want.
http://www.djangoproject.com/documentation/templates_python/#writing-custom-template-filters
has the instructions....
Fredrik Lundh
> I did realize an example where the title filter's implementation would
> be desired. When you've got a possessive noun:
>
>>>> Template("{{ text|title }}").render(Context({"text": "the boy's blob"}))
> "The Boy's Blob"
>
> as opposed to:
>>>> "the boy's blob".title()
> "The Boy'S Blob"
someone recently complained that str.title() wasn't quite as clever as text|title
over at comp.lang.python, so I assume that whatever you do, someone will
think it's doing the wrong thing.
</F>
Gary Wilson
> them may cause problems for me (capfirst will not convert an acronym
> like NASA to lower case, whereas capitalize will).
Yes, I think will all of these that it depends on the data you have to
start with. If you have acronyms and lower case text then you would
probably want to use capfirst. If you have all upper case text that
you want to look nice, then you probably would want capitalize.
> But why don't you just create your own capitalize filter (or titlecase
> filter) for yourself? Then you'll know that you'll get exactly the
> functionality that you need and want.
I have no problem creating my own filters, just trying to see how
people feel about the str filters.
Gary Wilson
> someone recently complained that str.title() wasn't quite as clever as text|title
> over at comp.lang.python, so I assume that whatever you do, someone will
> think it's doing the wrong thing.
And that is sort of my point. Is it confusing that text|title doesn't
behave the same as text.title()? Having the same names, I would
expect them to behave the same. The behavior of str.title can be
taken up with the python devs, but as for django, we could at least be
consistent.
Jacob Kaplan-Moss
consists of people who don't know Python. Trying to explain to them that
Joe'S Diner is "correct" because Python says it's correct is, well, ...
Yes, consistency is good, but this is an exception.
Jacob
Fredrik Lundh
> And that is sort of my point. Is it confusing that text|title doesn't
> behave the same as text.title()?
no, I was unclear: the c.l.python poster found it confusing that
text.title() has such a brain-dead notion of that a word is. he
wasn't a Django user, as far as I can tell; he only expected
text.title() to do something reasonable.
</F>