<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: YAML ain’t Markup Language &#124; Completely Different</title>
	<atom:link href="http://jessenoller.com/2009/04/13/yaml-aint-markup-language-completely-different/feed/" rel="self" type="application/rss+xml" />
	<link>http://jessenoller.com/2009/04/13/yaml-aint-markup-language-completely-different/</link>
	<description>python, programming and other things</description>
	<lastBuildDate>Mon, 02 Jan 2012 09:21:00 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: vsapre</title>
		<link>http://jessenoller.com/2009/04/13/yaml-aint-markup-language-completely-different/comment-page-1/#comment-139161</link>
		<dc:creator>vsapre</dc:creator>
		<pubDate>Wed, 22 Jul 2009 01:55:17 +0000</pubDate>
		<guid isPermaLink="false">http://jessenoller.com/?p=581#comment-139161</guid>
		<description>Hi Jesse,&lt;br&gt;&lt;br&gt;I have been using YAML for a few projects for my users as configuration files and YAML certainly rocks. Interestingly I came to YAML much the same way you&#039;ve described your journey.&lt;br&gt;&lt;br&gt;Just as a side remark, I&#039;ve found that we read yaml more than we dump it. And so since its a one shot load (there is no SAX approach to reading a YAML file, as yet), &#039;syck&#039; seems to be better suited for it...as long as you stay with YAML 1.0. Since &#039;syck&#039; is C, its fast and loading it using &#039;syck&#039; certainly shows up as compared to using PyYAML to do the same.&lt;br&gt;&lt;br&gt;On the other hand, &#039;dump&#039; is best done using PyYAML, especially because of its dump flags that can help you restore the exact file as it is.&lt;br&gt;&lt;br&gt;Thought of sharing this with you.&lt;br&gt;&lt;br&gt;BTW: Thanks for the multiprocessing module and your talks at PyCon 2009 were great !!&lt;br&gt;&lt;br&gt;Thanks and best regards,&lt;br&gt;Vishal Sapre</description>
		<content:encoded><![CDATA[<p>Hi Jesse,</p>
<p>I have been using YAML for a few projects for my users as configuration files and YAML certainly rocks. Interestingly I came to YAML much the same way you’ve described your journey.</p>
<p>Just as a side remark, I’ve found that we read yaml more than we dump it. And so since its a one shot load (there is no SAX approach to reading a YAML file, as yet), ‘syck’ seems to be better suited for it…as long as you stay with YAML 1.0. Since ‘syck’ is C, its fast and loading it using ‘syck’ certainly shows up as compared to using PyYAML to do the same.</p>
<p>On the other hand, ‘dump’ is best done using PyYAML, especially because of its dump flags that can help you restore the exact file as it is.</p>
<p>Thought of sharing this with you.</p>
<p>BTW: Thanks for the multiprocessing module and your talks at PyCon 2009 were great !!</p>
<p>Thanks and best regards,<br />Vishal Sapre</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: vsapre</title>
		<link>http://jessenoller.com/2009/04/13/yaml-aint-markup-language-completely-different/comment-page-1/#comment-139160</link>
		<dc:creator>vsapre</dc:creator>
		<pubDate>Wed, 22 Jul 2009 01:53:29 +0000</pubDate>
		<guid isPermaLink="false">http://jessenoller.com/?p=581#comment-139160</guid>
		<description>Hi Jesse,&lt;br&gt;&lt;br&gt;I have been using YAML for a few projects for my users as configuration files and YAML certainly rocks. Interestingly I came to YAML much the same way you&#039;ve described your journey.&lt;br&gt;&lt;br&gt;Just as a side remark, I&#039;ve found that we read yaml more than we dump it. And so since its a one shot load (there is no SAX approach to reading a YAML file, as yet), &#039;syck&#039; seems to be better suited for it...as long as you stay with YAML 1.0. Since &#039;syck&#039; is C, its fast and loading it using &#039;syck&#039; certainly shows up as compared to using PyYAML to do the same.&lt;br&gt;&lt;br&gt;On the other hand, &#039;dump&#039; is best done using PyYAML, especially because of its dump flags that can help you restore the exact file as it is.&lt;br&gt;&lt;br&gt;Thought of sharing this with you.&lt;br&gt;&lt;br&gt;BTW: Thanks for the multiprocessing module and your talks at PyCon 2009 were great !!&lt;br&gt;&lt;br&gt;Thanks and best regards,&lt;br&gt;Vishal Sapre</description>
		<content:encoded><![CDATA[<p>Hi Jesse,</p>
<p>I have been using YAML for a few projects for my users as configuration files and YAML certainly rocks. Interestingly I came to YAML much the same way you’ve described your journey.</p>
<p>Just as a side remark, I’ve found that we read yaml more than we dump it. And so since its a one shot load (there is no SAX approach to reading a YAML file, as yet), ‘syck’ seems to be better suited for it…as long as you stay with YAML 1.0. Since ‘syck’ is C, its fast and loading it using ‘syck’ certainly shows up as compared to using PyYAML to do the same.</p>
<p>On the other hand, ‘dump’ is best done using PyYAML, especially because of its dump flags that can help you restore the exact file as it is.</p>
<p>Thought of sharing this with you.</p>
<p>BTW: Thanks for the multiprocessing module and your talks at PyCon 2009 were great !!</p>
<p>Thanks and best regards,<br />Vishal Sapre</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: vsapre</title>
		<link>http://jessenoller.com/2009/04/13/yaml-aint-markup-language-completely-different/comment-page-1/#comment-97104</link>
		<dc:creator>vsapre</dc:creator>
		<pubDate>Tue, 21 Jul 2009 20:55:17 +0000</pubDate>
		<guid isPermaLink="false">http://jessenoller.com/?p=581#comment-97104</guid>
		<description>Hi Jesse,&lt;br&gt;&lt;br&gt;I have been using YAML for a few projects for my users as configuration files and YAML certainly rocks. Interestingly I came to YAML much the same way you&#039;ve described your journey.&lt;br&gt;&lt;br&gt;Just as a side remark, I&#039;ve found that we read yaml more than we dump it. And so since its a one shot load (there is no SAX approach to reading a YAML file, as yet), &#039;syck&#039; seems to be better suited for it...as long as you stay with YAML 1.0. Since &#039;syck&#039; is C, its fast and loading it using &#039;syck&#039; certainly shows up as compared to using PyYAML to do the same.&lt;br&gt;&lt;br&gt;On the other hand, &#039;dump&#039; is best done using PyYAML, especially because of its dump flags that can help you restore the exact file as it is.&lt;br&gt;&lt;br&gt;Thought of sharing this with you.&lt;br&gt;&lt;br&gt;BTW: Thanks for the multiprocessing module and your talks at PyCon 2009 were great !!&lt;br&gt;&lt;br&gt;Thanks and best regards,&lt;br&gt;Vishal Sapre</description>
		<content:encoded><![CDATA[<p>Hi Jesse,</p>
<p>I have been using YAML for a few projects for my users as configuration files and YAML certainly rocks. Interestingly I came to YAML much the same way you’ve described your journey.</p>
<p>Just as a side remark, I’ve found that we read yaml more than we dump it. And so since its a one shot load (there is no SAX approach to reading a YAML file, as yet), ‘syck’ seems to be better suited for it…as long as you stay with YAML 1.0. Since ‘syck’ is C, its fast and loading it using ‘syck’ certainly shows up as compared to using PyYAML to do the same.</p>
<p>On the other hand, ‘dump’ is best done using PyYAML, especially because of its dump flags that can help you restore the exact file as it is.</p>
<p>Thought of sharing this with you.</p>
<p>BTW: Thanks for the multiprocessing module and your talks at PyCon 2009 were great !!</p>
<p>Thanks and best regards,<br />Vishal Sapre</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Doug Farrell</title>
		<link>http://jessenoller.com/2009/04/13/yaml-aint-markup-language-completely-different/comment-page-1/#comment-76268</link>
		<dc:creator>Doug Farrell</dc:creator>
		<pubDate>Mon, 08 Jun 2009 21:10:56 +0000</pubDate>
		<guid isPermaLink="false">http://jessenoller.com/?p=581#comment-76268</guid>
		<description>Hi Jessie,&lt;br&gt;Very nice write-up about Yaml, which I&#039;m using. Based on your article in Python Magazine, I started using the syntax you also show above, creating Python objects from the configuration file. I&#039;m even passing them arguments from the Yaml file as you&#039;ve also shown above. &lt;br&gt;&lt;br&gt;I do have one question for you, I&#039;d like to put all my configuration files together into one big file. Is there a way to get Yaml to only read one section (or one document)? What I&#039;m trying to avoid is having all the objects constructed by programs that don&#039;t care about or use those objects when reading their own configuration section.&lt;br&gt;&lt;br&gt;Thanks in advance!&lt;br&gt;Doug</description>
		<content:encoded><![CDATA[<p>Hi Jessie,<br />Very nice write-up about Yaml, which I’m using. Based on your article in Python Magazine, I started using the syntax you also show above, creating Python objects from the configuration file. I’m even passing them arguments from the Yaml file as you’ve also shown above. </p>
<p>I do have one question for you, I’d like to put all my configuration files together into one big file. Is there a way to get Yaml to only read one section (or one document)? What I’m trying to avoid is having all the objects constructed by programs that don’t care about or use those objects when reading their own configuration section.</p>
<p>Thanks in advance!<br />Doug</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ryan</title>
		<link>http://jessenoller.com/2009/04/13/yaml-aint-markup-language-completely-different/comment-page-1/#comment-70328</link>
		<dc:creator>Ryan</dc:creator>
		<pubDate>Wed, 15 Apr 2009 22:16:28 +0000</pubDate>
		<guid isPermaLink="false">http://jessenoller.com/?p=581#comment-70328</guid>
		<description>Here&#039;s a mostly non-material comment for everyone.  With an historical understanding that &quot;YA&quot; at the start of an acronym means &quot;Yet Another&quot; I was a bit taken aback when that wasn&#039;t the case here.  Then when I saw it was just a recursive acronym, I wondered why &quot;Y&quot; was chosen as the first character, as you could choose from any of the wonderful characters available and still have it work.  Then I despised it for choosing one (&quot;Y&quot;) that when combined with the next character (&quot;A&quot;) already had a recognized meaning.  But, like I said, mostly non-material.</description>
		<content:encoded><![CDATA[<p>Here’s a mostly non-material comment for everyone.  With an historical understanding that “YA” at the start of an acronym means “Yet Another” I was a bit taken aback when that wasn’t the case here.  Then when I saw it was just a recursive acronym, I wondered why “Y” was chosen as the first character, as you could choose from any of the wonderful characters available and still have it work.  Then I despised it for choosing one (“Y”) that when combined with the next character (“A”) already had a recognized meaning.  But, like I said, mostly non-material.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Doug Napoleone</title>
		<link>http://jessenoller.com/2009/04/13/yaml-aint-markup-language-completely-different/comment-page-1/#comment-70176</link>
		<dc:creator>Doug Napoleone</dc:creator>
		<pubDate>Tue, 14 Apr 2009 04:38:26 +0000</pubDate>
		<guid isPermaLink="false">http://jessenoller.com/?p=581#comment-70176</guid>
		<description>oops.. Meant to also say:&lt;br&gt;&lt;br&gt;Thank you for such a fantastic writeup on using YAML in python. You would be amazed by the number of research projects and research institutions which use YAML as their lingual franca. There was a point in time when our research department was considering going over to XML based interchange formats (custom internal ones). There was quite some steam behind it, until people started developing the actual specs, and implementations. The last straw was when we wanted to make a small change to one of the formats. When properly implemented you need many, many XML files. YAML is makes even the pains of upgrading older formats easier.</description>
		<content:encoded><![CDATA[<p>oops.. Meant to also say:</p>
<p>Thank you for such a fantastic writeup on using YAML in python. You would be amazed by the number of research projects and research institutions which use YAML as their lingual franca. There was a point in time when our research department was considering going over to XML based interchange formats (custom internal ones). There was quite some steam behind it, until people started developing the actual specs, and implementations. The last straw was when we wanted to make a small change to one of the formats. When properly implemented you need many, many XML files. YAML is makes even the pains of upgrading older formats easier.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Doug Napoleone</title>
		<link>http://jessenoller.com/2009/04/13/yaml-aint-markup-language-completely-different/comment-page-1/#comment-70156</link>
		<dc:creator>Doug Napoleone</dc:creator>
		<pubDate>Tue, 14 Apr 2009 02:28:52 +0000</pubDate>
		<guid isPermaLink="false">http://jessenoller.com/?p=581#comment-70156</guid>
		<description>While reading this I had the song &#039;Momma said knock you out&#039;, but with the words &quot;don&#039;t call it a markup, it&#039;s been here for years...&quot; and so on.. And the image of LL Cool J with a set of gold knuckles spelling out YAML.... I won&#039;t bore you with the rest....</description>
		<content:encoded><![CDATA[<p>While reading this I had the song ‘Momma said knock you out’, but with the words “don’t call it a markup, it’s been here for years…” and so on.. And the image of LL Cool J with a set of gold knuckles spelling out YAML.… I won’t bore you with the rest.…</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Performance optimized by W3 Total Cache. Learn more: http://www.w3-edge.com/wordpress-plugins/

Minified using disk: basic
Page Caching using disk: enhanced
Object Caching 682/684 objects using disk: basic

Served from: jessenoller.com @ 2012-02-08 02:28:18 -->
