Re: value "on"=True in pyyaml?

It goes back to "how breaking we want 2.0 to be". E.g., we could say >
behaves like ", (with a warning?), so as not to break existing files "too
much". Or something.

On Thu, Mar 3, 2016 at 6:05 PM, Ingy dot Net <[email protected]> wrote:

> 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