Introducing the MochiKit.Text module

[Per Cederberg]

Hi everyone,

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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Arnar Birgisson]

Hi Per,

Post by Per Cederberg
I've just finished committing one of my planned additions to MochiKit

Excellent work, thank you!

Post by Per Cederberg
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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Per Cederberg]

Post by Arnar Birgisson
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... :-)

Post by Arnar Birgisson
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.

Post by Arnar Birgisson
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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Arnar Birgisson]

Hi,

Post by Per Cederberg
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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Amit Mendapara]

It's very good addition :) especially the new formating functions.
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

Post by Per Cederberg
Hi everyone,
I've just finished committing one of my planned additions to MochiKit
   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.
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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Per Cederberg]

On Thu, Dec 18, 2008 at 6:15 AM, Amit Mendapara

Post by Amit Mendapara
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.

Post by Amit Mendapara
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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Christoph Zwerschke]

Post by Amit Mendapara
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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Arnar Birgisson]

Hi Christoph,

Post by Christoph Zwerschke
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.

Post by Christoph Zwerschke
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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---