From: Kirill S. <xi...@ga...> - 2006-02-25 19:06:33
|
I'd like to present PyYAML3000: http://trac.xitology.org/pysyck/wiki/PyYAML3000 -- xi |
From: Clark C. E. <cc...@cl...> - 2006-02-25 19:54:35
|
This is beyond fantastic. I've updated the website to reflect the announcement! Best, Clark On Sat, Feb 25, 2006 at 09:06:21PM +0200, Kirill Simonov wrote: | I'd like to present PyYAML3000: | http://trac.xitology.org/pysyck/wiki/PyYAML3000 |
From: <ti...@po...> - 2006-02-25 22:35:34
|
> This is beyond fantastic. I've updated the website to > reflect the announcement! > > Best, > > Clark > That is also beyond genius!! You are the man!! If you were here now I'd kiss you - so it's probably a good job we're in different countries ;-) I'll be giving this a good testing over the next few days and might try t= o roll it into the new python site build system. Just off the top of your head, does the loader have the same construct an= d register_construct as the syck.loader? The code I'm using at the bottom o= f the file below.. don't spend too much time looking at it, I'm just asking in case the answer isn't obvious once I start looking at the code. http://pyramid.pollenation.net/cgi-bin/trac.cgi/browser/tags/0.3.2/pyrami= d/yamlRegistry.py If so then I can get rid of the c library dependency for the whole pyrami= d builder, which will make installing it for the pycon sprints a damn site easier (obviously it may be too soon for such use, let me know if you think so). This is such good news for python yaml exponents though!! Well done!! Let me know if you're still interested using the pyyaml assets/hosting. Tim Parkin |
From: Kirill S. <xi...@ga...> - 2006-02-25 23:07:24
|
On Sat, Feb 25, 2006 at 10:33:31PM -0000, ti...@po... wrote: > > This is beyond fantastic. I've updated the website to > > reflect the announcement! > > > > Best, > > > > Clark > > > That is also beyond genius!! You are the man!! If you were here now I'd > kiss you - so it's probably a good job we're in different countries ;-) > > I'll be giving this a good testing over the next few days and might try to > roll it into the new python site build system. > > Just off the top of your head, does the loader have the same construct and > register_construct as the syck.loader? The code I'm using at the bottom of > the file below.. don't spend too much time looking at it, I'm just asking > in case the answer isn't obvious once I start looking at the code. > > http://pyramid.pollenation.net/cgi-bin/trac.cgi/browser/tags/0.3.2/pyramid/yamlRegistry.py The constructor API is different. You may check the 'constructor.py' code http://trac.xitology.org/pysyck/file/branches/pyyaml3000/lib/yaml/constructor.py It should be clear enough. Of course, it should not be considered as a stable API, any suggestions are welcome. In this case, you may replace it with something like this: class html(str): pass yaml.Constructor.add_constructor('!html', lambda c, n: html(c.construct_scalar(n))) The constructor function is called with a Constructor instance 'c' and a node 'n'. 'construct_scalar' checks if the node is a scalar node and returns its value 'n.value'. yaml.load_document('''--- !html <head>test</head>\n''') will give you an html instance. Note that pyyaml3000 uses unicode internally, so a scalar node value is a unicode object. You will get UnicodeEncodeError while converting it to a str object if it contains non-ascii characters. So you'd better use yaml.Constructor.add_constructor('!html', lambda c, n: html(c.construct_scalar(n).encode('utf-8'))) > If so then I can get rid of the c library dependency for the whole pyramid > builder, which will make installing it for the pycon sprints a damn site > easier (obviously it may be too soon for such use, let me know if you > think so). I think it's pretty solid and stable, and error descriptions are much nicer. But you may have issues with unicode or new constructors. > > This is such good news for python yaml exponents though!! Well done!! > > Let me know if you're still interested using the pyyaml assets/hosting. > > Tim Parkin > -- xi |
From: <ti...@po...> - 2006-02-26 09:59:59
|
> On Sat, Feb 25, 2006 at 10:33:31PM -0000, ti...@po... wrote: >> > This is beyond fantastic. I've updated the website to >> > reflect the announcement! >> > >> > Best, >> > >> > Clark >> > >> That is also beyond genius!! You are the man!! If you were here now I'= d >> kiss you - so it's probably a good job we're in different countries ;-= ) >> >> I'll be giving this a good testing over the next few days and might tr= y >> to >> roll it into the new python site build system. >> >> Just off the top of your head, does the loader have the same construct >> and >> register_construct as the syck.loader? The code I'm using at the botto= m >> of >> the file below.. don't spend too much time looking at it, I'm just >> asking >> in case the answer isn't obvious once I start looking at the code. >> >> http://pyramid.pollenation.net/cgi-bin/trac.cgi/browser/tags/0.3.2/pyr= amid/yamlRegistry.py > > The constructor API is different. You may check the 'constructor.py' > code > http://trac.xitology.org/pysyck/file/branches/pyyaml3000/lib/yaml/const= ructor.py > It should be clear enough. Of course, it should not be considered as a > stable API, any suggestions are welcome. > > In this case, you may replace it with something like this: > > class html(str): > pass > > yaml.Constructor.add_constructor('!html', > lambda c, n: html(c.construct_scalar(n))) > > The constructor function is called with a Constructor instance 'c' and = a > node 'n'. 'construct_scalar' checks if the node is a scalar node and > returns its value 'n.value'. > > yaml.load_document('''--- !html <head>test</head>\n''') will give you a= n > html instance. > > Note that pyyaml3000 uses unicode internally, so a scalar node > value is a unicode object. You will get UnicodeEncodeError while > converting it to a str object if it contains non-ascii characters. > > So you'd better use > > yaml.Constructor.add_constructor('!html', > lambda c, n: html(c.construct_scalar(n).encode('utf-8'))) > > >> If so then I can get rid of the c library dependency for the whole >> pyramid >> builder, which will make installing it for the pycon sprints a damn si= te >> easier (obviously it may be too soon for such use, let me know if you >> think so). > > I think it's pretty solid and stable, and error descriptions are much > nicer. But you may have issues with unicode or new constructors. > > >> >> This is such good news for python yaml exponents though!! Well done!! >> >> Let me know if you're still interested using the pyyaml assets/hosting= . >> >> Tim Parkin >> > > -- > xi > Brilliant answer and just what I wanted .. I shall be playing after breakfast :-D |
From: why t. l. s. <yam...@wh...> - 2006-02-26 02:30:39
|
Kirill Simonov wrote: > I'd like to present PyYAML3000: > http://trac.xitology.org/pysyck/wiki/PyYAML3000 > Horrayy3000! Okay, so, spell this out. What am I applauding exactly? This looks like a wrapper for Syck and you're doing Unicode stuff on your own, is that so? Or do you have your own parser you've written? I've been rewriting the Syck lexer using Ragel (infinitely superior to re2c) and I've added Unicode support. I'm wondering if this is a striking move forward, or if you'd rather I stay out of it. Anyway, you can turn off Unicode support on the new branch, if need be. So, got any feedback? _why |
From: why t. l. s. <yam...@wh...> - 2006-02-26 02:36:05
|
why the lucky stiff wrote: > Kirill Simonov wrote: >> I'd like to present PyYAML3000: >> http://trac.xitology.org/pysyck/wiki/PyYAML3000 >> > Horrayy3000! Okay, so, spell this out. What am I applauding > exactly? This looks like a wrapper for Syck and you're doing Unicode > stuff on your own, is that so? Or do you have your own parser you've > written? Oh, wait, I see! This is a pure Python parser. Outrageous, Kirill, you're making me want to drop down to just a scanner in C. _why |
From: Kirill S. <xi...@ga...> - 2006-02-26 10:15:35
|
On Sat, Feb 25, 2006 at 07:30:23PM -0700, why the lucky stiff wrote: > Kirill Simonov wrote: > >I'd like to present PyYAML3000: > >http://trac.xitology.org/pysyck/wiki/PyYAML3000 > > > Horrayy3000! Okay, so, spell this out. What am I applauding exactly? > This looks like a wrapper for Syck and you're doing Unicode stuff on > your own, is that so? Or do you have your own parser you've written? It's a pure Python parser (yet). It has a similar structure (Scanner + Parser) to syck, but the major difference is that my parser is LL(1). It's modelled after Python's scanner and parser. Its support of YAML grammar is more complete, although the gap is not large as syck does a good job here. And last, but not least, I understand how it works. :) > I've been rewriting the Syck lexer using Ragel (infinitely superior to > re2c) and I've added Unicode support. I'm wondering if this is a > striking move forward, or if you'd rather I stay out of it. Anyway, you > can turn off Unicode support on the new branch, if need be. So, got any > feedback? -- xi |
From: Kirill S. <xi...@ga...> - 2006-03-11 19:36:32
|
First I'd like to thank everybody for the support I got here and on #yaml. There are some issues with the YAML grammar that I want to discuss here. 1. Should indentation be forced for flow collections? The current spec requires flow collections to be indented more then the parent block. This makes even legitimate-looking documents like --- simple key: [ flow, sequence ] # <-- to be ill-formed. The same question can be asked for this example: --- block: another block: [ flow, collection] I see the following advantages of allowing such syntax: - syck compatibility: syck allows it. - Python (a language that has a similar block/flow syntax) allows it. - for the scanner, this restriction looks artificial since indentation is not needed for parsing flow collections. Thus removing this restriction will make the scanner more natural. On the other hand: - it's ugly. - noone will really use such syntax. Most likely this indicates a syntax error somewhere (unclosed '[' or '{'). Allowing it will make error messages more confusing. So I'm not sure what the best solution is. 2. The same question and the same reasons are applicable for quoted scalars: --- block: block: 'quoted scalar' Again indentation is not needed for the scanner so such syntax can be permitted. 3. The spec requires scalars to be indended with at least one space. It seems this rule was introduced to make the check for '---' and '...' indicators easier for the cases like --- "quoted scalar ... <-- invalid indicator" But it means that a user is forced to write --- "quoted scalar" which may not look nice. I don't mind to add the check for '---' and '...' at the beginning of a line, so I think this restriction can be removed. Note that syck does not require it either, although it does not check for the indicators. 4. Tab rules are confusing. Well, it's natural since tabs themselves are confusing, but I believe the rules are more confusing than necessary. I would like to forbid tabs completely, but it seems it's not an option. So where is the confusion? It's explained by this example (tab is denoted by '^'): --- # ill-formed document (understandable) - ^multi line scalar --- # again ill-formed document (why?) - multi^line scalar --- # well-formed document - multi line^ scalar --- # again well-formed document (hmm...) - multi line ^scalar --- # ill-formed document (?!) - multi line scalar^ I may be wrong in my interpretation of the production rules though, so the above attributions could be wrong. Anyway I'd like to use the following rule: tabs cannot be used before block indicators ('-', '?', ':', and simple keys) and cannot denote the end of block and plain scalars. Well, something like this; I'm not sure that this rule is complete or correct. But I'd like to have a rule that can be explained by a single sentence. 5. In the flow context, ':' and ',' should not be allowed for plain scalars and should always be separators. This means that the document --- [1:2,3:4] is the same as --- [ 1 : 2 , 3 : 4 ] It was already discussed here, I added it for completeness. The following two issues assume that this rule is implemented. 6. 'ns-anchor-name' is too greedy: ns-anchor-name ::= ns-char+ It may cause confusion for the documents like --- { &A 1,*A,1 } I want it to be restricted to 'ns-word-char+'. By the way, why '_' isn't included to 'ns-word-char'? It can be useful for identificators. 7. I'd like to forbid empty plain scalars if the anchor or tag is specified. For instance, I want to make the following example ill-formed: --- block key: !tag --- { !perl/A::Package } For the latter example, it's not clear if it is { !perl/A::Package '' } or { !perl/A: '' : 'Package' } This is the reason why I want this rule. That's all so far. -- xi |