[mochikit] Re: MochiKit Extensions
Hello Everyone, I have just published the initial source of MochiKit Extensions at Launchpad.net (https://launchpad.net/mochikit-ext). At the moment it only contains the MochiKit.Query module. To obtain the source, you require Bazaar vcs tools from (http://bazaar-vcs.org). bzr branch lp:mochikit-ext Regards -- Amit Mendapara --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Formatting strings, numbers and stuff
I guess this is a question for Bob, but others might have some clues here also. Thus sending it to the list. I've recently done some Python coding and found the % string formating there very convenient. Now, as MochiKit is so inspired by Python, I find it a bit odd that there is no generic string formatting similar to the Python version. Is this just due to lack of time or is it a deliberate omission? The MochiKit.Format.numberFormatter function is of course very powerful, but it doesn't provide everything that the Python equivalent does: 1. No type selection mechanism. Cannot format strings, random objects or hexadecimal, octal, binary or floating point exponential numbers. 2. No generic string formatting. Cannot output Value: %d or similar. 3. Inconvenient API for throw-away formatting. You have to create a formatting function and then call it (very Java-ish). Has anybody created a generic formatting function in JavaScript? Other libraries? Or am I the only one seeing the need? Cheers, /Per --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Formatting strings, numbers and stuff
On Wed, Sep 10, 2008 at 5:55 AM, Per Cederberg [EMAIL PROTECTED] wrote: I guess this is a question for Bob, but others might have some clues here also. Thus sending it to the list. I've recently done some Python coding and found the % string formating there very convenient. Now, as MochiKit is so inspired by Python, I find it a bit odd that there is no generic string formatting similar to the Python version. Is this just due to lack of time or is it a deliberate omission? The MochiKit.Format.numberFormatter function is of course very powerful, but it doesn't provide everything that the Python equivalent does: 1. No type selection mechanism. Cannot format strings, random objects or hexadecimal, octal, binary or floating point exponential numbers. 2. No generic string formatting. Cannot output Value: %d or similar. 3. Inconvenient API for throw-away formatting. You have to create a formatting function and then call it (very Java-ish). Has anybody created a generic formatting function in JavaScript? Other libraries? Or am I the only one seeing the need? I've wanted to have it once or twice, but the number formatting has worked out well for what I wanted to do. Conversely, Python's formatting functions don't allow you to put thousands separators in numbers, which is something we do very often. The number formatter uses the same spec as Java does so the way it acts should be of little surprise. The API isn't terribly inconvenient other than the length of the name I guess, since functions are first class. numberFormatter(###,###%)(2134) isn't that much longer than say formatNumber(###,###%, 2134) or something like that. If we do implement a string formatting library my personal preference would be the advanced string formatting from PEP 3101 that is going into Python 2.6/3.0: http://www.python.org/dev/peps/pep-3101/ We've also got a similar Erlang implementation here: http://code.google.com/p/mochiweb/source/browse/trunk/src/mochifmt.erl -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Formatting strings, numbers and stuff
Thank you everyone for the interesting comments. I had a look at PEP
3101 (Python 3), the (new) Java 1.5 Formatter API and a popular
sprintf implementation for JavaScript. And in the end, it seems hard
to strike a good balance between readable syntax, power features and
localization. Actually, I think they all fail at one or the other.
In PEP 3101 I couldn't find any mention of the thousand separator (at
first, but now I just realized that :n should be used). The Java
Formatter API took the already ugly sprintf-syntax to new heights of
unreadability. And the standard sprintf variants are problematic for
localized format strings where the order of the parameters might
change.
So, I'm thinking about using a simplified version of PEP 3101 with a
few add-ons to enable most of what is possible with the current
numberFormatter function.
I'm thinking that the API should look something like:
// Create a formatter function for specified pattern locale
MochiKit.Format.formatter(pattern/*, locale=default */)
== function object
// Short-cut that immediately applies the formatter on the specified args
MochiKit.Format.format(pattern/*, ... */)
== formatted string
Perhaps a few examples would best explain the formatting patterns:
// Simple positional replacements
format(A {1} string with {0} arguments., numeric, format)
== A format string with numeric arguments.
// Or we use object properties
format({name} == {value}, { value: 2, name: a })
== a == 2
// As usual, escaping is performed by double chars
format({{}})
== {}
// Differing from Python, the default is a toString()
format({0}, 1/3)
== 0.
// Naturally, null is supported as null
format({0}, null)
== null
// We can force a decimal format
format({0:d}, 1.5)
== 1
// And a fixed number of characters
format({0:4d}, -4)
== -4
// We can force the field to be left-aligned
format({0:4d}, 4)
== 4
// Or add zero padding
format({0:04d}, 4)
== 0004
// Using the repr() output
format({0:r}, foo)
== \foo\
// I suggest we skip nested replacements due to complexity
format({0:{1}}, 4, 3)
== error, but in Python it would be 4
// I'd also reject deep object names as it is just not useful enough
format({sub.name}, { sub: { name: Alice } })
== error, but in Python it would be Alice
So the format for the replacement string is:
{ key : fmt }
The format string has the following (Python) format:
[flags][width][.precision][type]
Flags:
'' - Forces the field to be right-aligned (default).
'' - Forces the field to be left-aligned.
'+' - Sign should be used for both positive and negative numbers.
'-' - Sign should be used only for negative numbers (default).
' ' - Leading space should be used on positive numbers.
'0' - Numbers will be zero-padded to the specified width.
',' - The result will include locale-specific grouping (thousand separators).
Width specifies the minimum field width. The precision indicates how
many digits should be displayed after the decimal point in a floating
point conversion. For non-numeric types the field indicates the
maximum field size.
Suggested formatting types:
s - Output from toString(), this is the default
r - Output from MochiKit.Base.repr()
b - Binary. Outputs the number in base 2.
c - Character.
d - Decimal Integer. Outputs the number in base 10.
o - Octal format. Outputs the number in base 8.
x - Hex format. Outputs the number in base 16, using lower-case letters.
X - Hex format. Outputs the number in base 16, using upper-case letters.
f - Fixed point number.
% - Percent conversion for a fixed point number (and adds a '%' char
at the end).
... perhaps some format for exponents (but it would be hard to implement)
... and some nice time formatting stuff
I think the above would support most of the common use cases for
formatting, while leaving it fairly simple to implement in plain
JavaScript. If more advanced formatting is required, one can always
write specialized functions that re-use these components accordingly.
Opinions? Think I'll start on this next week otherwise.
Cheers,
/Per
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
MochiKit group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: Formatting strings, numbers and stuff
I think we should keep deep object names, JSON data structures are
often nested a little bit and it's nice to be able to work with them
as-is without creating a new object just to flatten it out.
As far as nested replacements go, I think we can ditch that safely.
I've never really wanted to use that.
Otherwise the proposal looks good! :)
On Wed, Sep 10, 2008 at 12:53 PM, Per Cederberg [EMAIL PROTECTED] wrote:
Thank you everyone for the interesting comments. I had a look at PEP
3101 (Python 3), the (new) Java 1.5 Formatter API and a popular
sprintf implementation for JavaScript. And in the end, it seems hard
to strike a good balance between readable syntax, power features and
localization. Actually, I think they all fail at one or the other.
In PEP 3101 I couldn't find any mention of the thousand separator (at
first, but now I just realized that :n should be used). The Java
Formatter API took the already ugly sprintf-syntax to new heights of
unreadability. And the standard sprintf variants are problematic for
localized format strings where the order of the parameters might
change.
So, I'm thinking about using a simplified version of PEP 3101 with a
few add-ons to enable most of what is possible with the current
numberFormatter function.
I'm thinking that the API should look something like:
// Create a formatter function for specified pattern locale
MochiKit.Format.formatter(pattern/*, locale=default */)
== function object
// Short-cut that immediately applies the formatter on the specified args
MochiKit.Format.format(pattern/*, ... */)
== formatted string
Perhaps a few examples would best explain the formatting patterns:
// Simple positional replacements
format(A {1} string with {0} arguments., numeric, format)
== A format string with numeric arguments.
// Or we use object properties
format({name} == {value}, { value: 2, name: a })
== a == 2
// As usual, escaping is performed by double chars
format({{}})
== {}
// Differing from Python, the default is a toString()
format({0}, 1/3)
== 0.
// Naturally, null is supported as null
format({0}, null)
== null
// We can force a decimal format
format({0:d}, 1.5)
== 1
// And a fixed number of characters
format({0:4d}, -4)
== -4
// We can force the field to be left-aligned
format({0:4d}, 4)
== 4
// Or add zero padding
format({0:04d}, 4)
== 0004
// Using the repr() output
format({0:r}, foo)
== \foo\
// I suggest we skip nested replacements due to complexity
format({0:{1}}, 4, 3)
== error, but in Python it would be 4
// I'd also reject deep object names as it is just not useful enough
format({sub.name}, { sub: { name: Alice } })
== error, but in Python it would be Alice
So the format for the replacement string is:
{ key : fmt }
The format string has the following (Python) format:
[flags][width][.precision][type]
Flags:
'' - Forces the field to be right-aligned (default).
'' - Forces the field to be left-aligned.
'+' - Sign should be used for both positive and negative numbers.
'-' - Sign should be used only for negative numbers (default).
' ' - Leading space should be used on positive numbers.
'0' - Numbers will be zero-padded to the specified width.
',' - The result will include locale-specific grouping (thousand separators).
Width specifies the minimum field width. The precision indicates how
many digits should be displayed after the decimal point in a floating
point conversion. For non-numeric types the field indicates the
maximum field size.
Suggested formatting types:
s - Output from toString(), this is the default
r - Output from MochiKit.Base.repr()
b - Binary. Outputs the number in base 2.
c - Character.
d - Decimal Integer. Outputs the number in base 10.
o - Octal format. Outputs the number in base 8.
x - Hex format. Outputs the number in base 16, using lower-case letters.
X - Hex format. Outputs the number in base 16, using upper-case letters.
f - Fixed point number.
% - Percent conversion for a fixed point number (and adds a '%' char
at the end).
... perhaps some format for exponents (but it would be hard to implement)
... and some nice time formatting stuff
I think the above would support most of the common use cases for
formatting, while leaving it fairly simple to implement in plain
JavaScript. If more advanced formatting is required, one can always
write specialized functions that re-use these components accordingly.
Opinions? Think I'll start on this next week otherwise.
Cheers,
/Per
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
MochiKit group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
