Introducing the MochiKit.Text module
Per Cederberg
I've just finished committing one of my planned additions to MochiKit
1.5 -- a new MochiKit.Text module:
http://www.mochikit.com/doc/html/MochiKit/Text.html
It basically provides some of the text formatting stuff discussed here
on the list previously. With some random string utility functions
added on top. I chose the name "Text" instead of "String" or "Format"
for various reasons, but in the end I guess it is just a matter of
taste. Also, it avoids collisions with the "MochiKit.String" name
already in use by Amit.
My plans for MochiKit.Text are as follows:
1. Collect more ideas and feedback (hence this email).
2. Migrate camelize, strip, lstrip, rstrip, truncToFixed, roundToFixed
and locale handling over to MochiKit.Text. Perhaps the remaining parts
of MochiKit.Format should be deprecated?
3. Implement some additional stuff like toTitleCase, isDigit,
isAlphaNumeric, etc.
Please let me know what you think.
Cheers,
/Per
Arnar Birgisson
On Wed, Dec 17, 2008 at 12:23, Per Cederberg <cede...@gmail.com> wrote:
> I've just finished committing one of my planned additions to MochiKit
> 1.5 -- a new MochiKit.Text module:
Excellent work, thank you!
> 1. Collect more ideas and feedback (hence this email).
One comment about startsWith, endsWith, contains etc.. currently they
take first the haystack and then the needle (I'm talking about
parameter order). Perhaps switching this could benefit the usecase
where this is used with partial?
my_namesakes = filter(partial(contains, 'Arnar'), list_of_names);
If the generalized partial I posted a few days ago this doesn't
matter, as it would be
my_namesakes = filter(partial(contains, __, 'Arnar'), list_of_names);
This reminds me of another idea, since it's unrelated to the text
module I'll post it in a different thread.
The module should define constants like ascii_chars, digits etc. as
per http://www.python.org/doc/2.3/lib/module-string.html -- also
split, join (although they are included in js as native methods -
having functions can be convenient for map & friends).
For padRight and padLeft - I prefer the Python names ljust, rjust (and center).
cheers,
Arnar
Per Cederberg
> One comment about startsWith, endsWith, contains etc.. currently they
> take first the haystack and then the needle (I'm talking about
> parameter order). Perhaps switching this could benefit the usecase
> where this is used with partial?
>
> my_namesakes = filter(partial(contains, 'Arnar'), list_of_names);
This is a good point. I think I'll change my ways. Watch out for the
next commit... :-)
> The module should define constants like ascii_chars, digits etc. as
> per http://www.python.org/doc/2.3/lib/module-string.html -- also
> split, join (although they are included in js as native methods -
> having functions can be convenient for map & friends).
That might be an idea. With the same "reversed" parameter order as the
ones above of course.
> For padRight and padLeft - I prefer the Python names ljust, rjust (and center).
Ah, well... I didn't look too hard into Python here. Just googled
various name ideas and picked the most popular one (think it was from
some MS API actually)... ;-)
Cheers,
/Per
Arnar Birgisson
On Wed, Dec 17, 2008 at 17:32, Per Cederberg <cede...@gmail.com> wrote:
> Ah, well... I didn't look too hard into Python here. Just googled
> various name ideas and picked the most popular one (think it was from
> some MS API actually)... ;-)
That's not such a bad method :) However, I feel MochiKit draws heavily
on Python (or Python libraries) for a lot of things, so to me it makes
sense to keep this convention.
cheers,
Arnar
Amit Mendapara
I'll improve my MochiKit.String module so that one can create String
instance with the new formating patterns.
Again, I'm too, agree with Arner. Try to follow Python conventions as
much as possible.
startsWith => startswith
endsWith => endswith
and so on...
See `MochiKit.String.splitlines`, you can remove `splitJoin` as you
one can easily do the same with `splitlines` (if it's all about
triming newline chars).
Regards
--
Amit
Per Cederberg
<mendapa...@gmail.com> wrote:
> Again, I'm too, agree with Arner. Try to follow Python conventions as
> much as possible.
>
> startsWith => startswith
> endsWith => endswith
Perhaps not so surprising, but I don't agree on this.
Since we are working with JavaScript here, I think we should first and
foremost follow existing JavaScript conventions. Using camelCase
naming is very much one of those (see the minimal built-in library and
objects).
Python names are not automatically the best choice for people without
a strong background in Python. Some of us have other biases, being
more accustomed to Java or whatever.
> See `MochiKit.String.splitlines`, you can remove `splitJoin` as you
> one can easily do the same with `splitlines` (if it's all about
> triming newline chars).
I actually removed my own stripLines to replace it with splitJoin... :-)
The thing I realized, was that a stripLines() function also implied
the rstripLines() and lstripLines() functions. So instead I tried to
generalize it to a more generic form of map for strings. It is an
experimental API for sure, but I was curious if it could be useful for
more things. It is, after all, a version of map()...
But this is no darling API of mine. I've registered your vote in
disfavor. Any other opinions?
Cheers,
/Per
Christoph Zwerschke
> Again, I'm too, agree with Arner. Try to follow Python conventions as
> much as possible.
>
> startsWith => startswith
> endsWith => endswith
By the way, one (new) useful feature of Python's startswith is that you
can also pass a tuple of substrings (prefixes) instead of only one. So
maybe you can accept arrays as well. And I would also make the actual
string the first argument (kind of "self"). Then you can also easily add
more parameters (like optional start and end index for the search etc.).
-- Christoph
Arnar Birgisson
On Thu, Dec 18, 2008 at 13:00, Christoph Zwerschke <ci...@online.de> wrote:
> By the way, one (new) useful feature of Python's startswith is that you
> can also pass a tuple of substrings (prefixes) instead of only one. So
> maybe you can accept arrays as well.
Ah, nice - I didn't know about this feature of startswith.
> And I would also make the actual
> string the first argument (kind of "self"). Then you can also easily add
> more parameters (like optional start and end index for the search etc.).
For this part, see me previous message in this thread about the
partial(...) use case. Partially applying the needle looks much more
common than partially applying the haystack (or at least that is my
gut feeling).
Again, if we get a more generic partial(..) this becomes a non-issue.
cheers,
Arnar