Clarifying charm format 2

[Jim Baker]

On 08/28/2012 05:15 PM, Gustavo Niemeyer wrote:
> On Tue, Aug 28, 2012 at 6:27 PM, Jim Baker <jim.baker at canonical.com> wrote:
>> value, there is coercion. For example, true, True, and TRUE all work
>> with config-set; e.g., config-set foo=TRUE; config-get then
> (...)
>> Question: do we want to keep the trunk support for config usage of
>> booleans in the final format: 2?
> Thanks for raising these additional issues, Jim.
>
> Just to make sure we're on the same page, I'll list them all again:
>
> config-get/set:
> - type int: Reads "1"; Writes "1" (no quotes)
> - type float: Reads "1" or "1.0"; Writes "1.0" (no quotes)
> - type boolean: Reads lower(v) in "true" or "false"; Writes "true" or "false"
> - type string: Reads raw data; Writes raw data
>
> relation-get/set
> - String: Reads raw data; Writes raw data
>
> relation-get -
> - YAML output with string keys and raw data values (no nesting!)

Correct, these are the cases that will result by supporting raw strings
as Kapil suggest, but otherwise keeping the work as is in trunk. This is
therefore also the easiest path. And to reiterate, there will be no
nesting! :)

>
>> 2. Dictionary output of relation-get - using smart format (implied if
>> not set with --format)
> (...)
>> {u'private-address': u'mysql-0.example.com', u'foo': u'ascii'}
>>
>> Clearly the u'XYZ' representation is going away. Based on the current
> Yeah, this is clearly unhelpful.
>
>> For format: 2 in trunk, relation-get - returns a YAML output. So using a
>> raw string in our example, this would result in the following output,
>> which can be parsed by any YAML parser:
>>
>> bar: !!binary |
>>     yv4=
>> foo: ascii
>> private-address: mysql-0.example.com
> This looks great for reading in the terminal, and is already in place.
> I suggest preserving that idea.
>
>> If we were to use a modified format: 1 and keep the Python str repr,
>> this would result in output like the following. It should be possible to
>> eval any version of this in Python, given the use of raw strings. It may
>> be readily parseable by other tools.
> YAML looks better for a default. There are several special cases for
> string formatting in Python that will make it cumbersome to use in
> anything but Python itself (e.g. ' vs ").

Agreed. See for example this raw string and its str representation in
Python:

>>> x = ''.join(chr(i) for i in xrange(256))
>>> x
'\x00\x01\x02\x03\x04\x05\x06\x07\x08\t\n\x0b\x0c\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f
!"#$%&\'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~\x7f\x80\x81\x82\x83\x84\x85\x86\x87\x88\x89\x8a\x8b\x8c\x8d\x8e\x8f\x90\x91\x92\x93\x94\x95\x96\x97\x98\x99\x9a\x9b\x9c\x9d\x9e\x9f\xa0\xa1\xa2\xa3\xa4\xa5\xa6\xa7\xa8\xa9\xaa\xab\xac\xad\xae\xaf\xb0\xb1\xb2\xb3\xb4\xb5\xb6\xb7\xb8\xb9\xba\xbb\xbc\xbd\xbe\xbf\xc0\xc1\xc2\xc3\xc4\xc5\xc6\xc7\xc8\xc9\xca\xcb\xcc\xcd\xce\xcf\xd0\xd1\xd2\xd3\xd4\xd5\xd6\xd7\xd8\xd9\xda\xdb\xdc\xdd\xde\xdf\xe0\xe1\xe2\xe3\xe4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf7\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff'

Also we really don't want to be using eval as the parser even with
Python, and I think telling people that instead they need to use
ast.literal_eval is just digging the hole even deeper.

- Jim

-- 
Jim Baker
Ubuntu Server team
jim.baker at canonical.com
jimbaker on freenode


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 551 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/juju/attachments/20120828/59def2c3/attachment.pgp>