This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author christoph
Recipients christoph, ezio.melotti, gvanrossum, lemburg, markon, nickd, nnorwitz, pitrou, r.david.murray, rhettinger, twb
Date 2009-09-29.11:01:31
SpamBayes Score 2.5590159e-09
Marked as misclassified No
Message-id <1254222093.11.0.58452995351.issue7008@psf.upfronthosting.co.za>
In-reply-to
Content
Antoine Pitrou wrote:
> capwords() itself could be deprecated, since it's an obvious one-
> Replacing in with another method, however, will just confuse and
annoy
> existing users.

Yes, sorry, I meant the semantics, where as you are right for the
specific function.

Marc-Andre Lemburg wrote:
> Note however, that word boundaries are just as complicated as casing:
> there are lots of special cases in different languages or locales
> (see the notes after the word boundary rules in the TR29).

ICU already has the full implementation, so Python could get away with
just supporting the default implementation (as seen with other case
mappings).

>>> from PyICU import UnicodeString, Locale, BreakIterator            
>>> en_US_locale = Locale('en_US')                                    
>>> breakIter = BreakIterator.createWordInstance(en_US_locale)        
>>> s = UnicodeString("There's a hole in the bucket.")                
>>> print s.toTitle(breakIter, en_US_locale)
There's A Hole In The Bucket.
>>> breakIter.setText("There's a hole in the bucket.")
>>> last = 0
>>> for i in breakIter:
...     print s[last:i]
...     last = i
...
There's

A

Hole

In

The

Bucket
.
History
Date User Action Args
2009-09-29 11:01:33christophsetrecipients: + christoph, lemburg, gvanrossum, nnorwitz, rhettinger, pitrou, ezio.melotti, r.david.murray, markon, twb, nickd
2009-09-29 11:01:33christophsetmessageid: <1254222093.11.0.58452995351.issue7008@psf.upfronthosting.co.za>
2009-09-29 11:01:31christophlinkissue7008 messages
2009-09-29 11:01:31christophcreate