Re: value "on"=True in pyyaml?

On Tue, Mar 1, 2016 at 9:26 PM, Oren Ben-Kiki <[email protected]> wrote:

> I'm uncomfortable saying that `foo: true` has different meaning if it is
> in block mapping vs. a flow mapping, even in 2.0.
>

I was uncomfortable having simple plain words type differently in block
context, which was not needed to achieve JSON compatibility. We've done
some weird things. :)


>
> Wrt. the wiki:
>

First off the wiki needs grooming. I'll go through it this week and get
back to you. Most of my content was added in 2011 and I'm fairly sure my
opinions have evolved a bit. (Mostly because of the exponential uptake of
YAML since then).


>
> - Lots of potential in the flow scalars proposal, details need to be
> polished. Definitely 2.0 here. Agree > isn't used in the wild but |
> definitely is. How breaking do we want 2.0 to be? Hmmm.
>

Now it is used in the wild. A lot. I see it in Ansible playbooks a lot. It
fits fairly well for very long bash commands that should have no escaping
semantics.


> - Not sure about the embedded YAML, most languages allow their own
> variable interpolation in "here documents" (e.g., Ruby allows `<<EOF ...
> #{foo} ... EOF`).
>
> - Allowing explicit invalid UTF values using the \... escape sequences: I
> guess so - if people _explicitly_ request invalid UTF bytes, "on their head
> be it". This would allow for using "strings" to use as "binary blobs"
> without needing esoteric data types such as base64.
>
> - Defining a standard way to convert to/from JSON: Sure.
>
> - YAML profiles: This is exactly what we started doing in the spec
> (failsafe vs. JSON vs. Core). We need to clean up the type repository
> accordingly. Probably in the context of some semi-standard schema mechanism.
>



>
> On Wed, Mar 2, 2016 at 12:57 AM, Ingy dot Net <[email protected]> wrote:
>
>> Oren,
>>
>> JSON compatibility only applies to flow form. I'm suggesting only string
>> and numeric (and possibly null) implicits in the block form.
>>
>> Andrey,
>>
>> Certainly too late for 1.2.
>>
>> re 2.0, I assume you've seen: https://github.com/yaml/YAML2/wiki
>>
>> I'd like to see your list. :-)
>>
>> On Tue, Mar 1, 2016 at 11:18 AM, Oren Ben-Kiki <[email protected]> wrote:
>>
>>>
>>> The 1.2 spec defines the JSON-compatible schema which I think satisfies
>>> all the points you made.
>>>
>>> We should definitely retire http://yaml.org/type/ or at least replace
>>> it with something better. People doing YAML 1.2 should not start copying
>>> from the current content there - you are right, this is something that
>>> hurts us.
>>>
>>> Working on a schema language - it is a decade late, but sure, why not?
>>> Would be fun :-)
>>>
>>> I'm not certain I follow wrt. booleans though. Do you suggest we break
>>> JSON compatibility?
>>>
>>> Oren.
>>>
>>>
>>> On Tue, Mar 1, 2016 at 9:07 PM, Ingy dot Net <[email protected]> wrote:
>>>
>>>> This is an example of one of the biggest issues with the state of
>>>> modern day YAML. I'd bet no 2 implementations do the same thing wrt
>>>> implicit typing of plain scalars.
>>>>
>>>> I think we need to retire http://yaml.org/type/
>>>>
>>>> It's an idea from over 10 years ago that was well meaning but turned
>>>> out poorly. People making new YAML frameworks still use this info.
>>>>
>>>> I am currently of the opinion that:
>>>>
>>>>    - Plain scalars in block context should only implicitly type to
>>>>    numbers, strings or null
>>>>       - Only JSON numerics are typed to !!int or !!float
>>>>       - Plain (unquoted) empty value is typed to !!null
>>>>       - Everything else is typed to !!str
>>>>    - Booleans should migrate to only supporting !!true and !!false
>>>>       - Loaders using a default schema should support !true !false
>>>>       (and !null)
>>>>       - The plain values of true and false should become strings
>>>>       - This might take a while to get everyone on board
>>>>    - Plain scalars in flow context should behave same as JSON.
>>>>       - Empty values are !!null
>>>>    - We should ditch octal, binary etc as possible implicit typing of
>>>>    numbers
>>>>    - We should ditch the (22 of them!!) special plain values that
>>>>    become boolean
>>>>       - Only true and false. In flow context. Lowercase.
>>>>
>>>> We can still keep the tag:yaml.org,2002 types, but we need to get out
>>>> of the implicit grab bag business. It will be the death of YAML!
>>>>
>>>> ---
>>>>
>>>> Related to that, is the concept that every YAML loader loads YAML to
>>>> native objects under the direction of a "schema"; but currently that
>>>> "schema" is baked into the code implementing loader.
>>>>
>>>> If we had a schema language, then all loaders could load YAML according
>>>> to a textual (thus easily reasonable) guide. Schemas could even be written
>>>> for loaders that didn't yet support them (as part of their doc) so that
>>>> people would know what to expect from their baked in behavior.
>>>>
>>>> More importantly, schemas could be written for popular YAML uses like,
>>>> say, Ansible or TravisCI that need values loaded a particular way. These
>>>> schemas could even be made to implicitly type true/false/null scalars, for
>>>> backwards compat.
>>>>
>>>>
>>>> On Mon, Feb 29, 2016 at 7:41 AM, Oren Ben-Kiki <[email protected]>
>>>> wrote:
>>>>
>>>>> This is old YAML 1.0/1.1 proposed schema behavior. It was deprecated
>>>>> (to maximize JSON compatibility among other reasons).
>>>>>
>>>>> On Mon, Feb 29, 2016 at 5:20 PM, <[email protected]> wrote:
>>>>>
>>>>>> Is this as expected?
>>>>>>
>>>>>>
>>>>>> kbriggs> cat yaml_on.py
>>>>>>
>>>>>>
>>>>>> import yaml
>>>>>> x="""
>>>>>>  0: on
>>>>>>  1: ON
>>>>>>  2: 'ON'
>>>>>> """
>>>>>> print yaml.load(x)
>>>>>>
>>>>>>
>>>>>> kbriggs> python yaml_on.py
>>>>>> {0: True, 1: True, 2: 'ON'}
>>>>>>
>>>>>>
>>>>>>
>>>>>> Keith
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>>>>>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>>>>>> Monitor end-to-end web transactions and take corrective actions now
>>>>>> Troubleshoot faster and improve end-user experience. Signup Now!
>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>>>>>> _______________________________________________
>>>>>> Yaml-core mailing list
>>>>>> [email protected]
>>>>>> https://lists.sourceforge.net/lists/listinfo/yaml-core
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>>>>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>>>>> Monitor end-to-end web transactions and take corrective actions now
>>>>> Troubleshoot faster and improve end-user experience. Signup Now!
>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>>>>> _______________________________________________
>>>>> Yaml-core mailing list
>>>>> [email protected]
>>>>> https://lists.sourceforge.net/lists/listinfo/yaml-core
>>>>>
>>>>>
>>>>
>>>
>>
>

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140

_______________________________________________
Yaml-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/yaml-core