Has anyone in this discussion used either Yaml or Json? I've used both. And I much prefer Json. The libraries to encode and decode in most languages worth mentioning are *very* fast (comparable to cPickle). Yaml...not so much. Never mind that Yaml has some ugly bits that make it's use as a configuration language (which isn't uncommon) have some very unpleasant gotchas. Adding *yet another* Python-centric serialization language seems more than a little silly to me; it seems like a waste of time. Of course you are free to develop this method as you see fit, but don't be surprised if you bring it to python-dev and they say, "no." - Josiah On Wed, Nov 5, 2008 at 6:25 AM, Bruce Leban <bruce@leapyear.org> wrote:
I've been following this discussion and it seems like implementation is way ahead of design. I'm looking at the syntax below and seeing it has no advantage over text pickle format to me. Sure it's a bit more readable, but as it stands, this is really only going to be useful for python-python operations and the existing pickle formats do that fine. Why would we need another one-off markup language? All that you've said so far about Yaml was "I didn't yet made comparison with yaml. I should do that too. Now I can only say that yaml is much complicated notation (IMHO)." In fact, I think a subset of Yaml is all that is necessary for this, just as Json is (now) a subset of Yaml. My suggestion is that Json < Pyon < Yaml is a good goal. I agree Yaml is complicated and the docs don't help as much as they could with too much emphasis on syntax and not enough on semantics. However, Yaml has already addressed issues like typing and defining objects to be reused. I'm not a Yaml expert so I may have gotten some of the following wrong, but it should be enough to give a general idea:
[int, float, str] == [!type int, !type float, !type str] or maybe [!py!type int, !py!type float, !py!type str]
and
_p__0=(1,2) _p__1=[1,2] [_p__0,_p__1,_p__0,_p__1]
==
[&_p__0 !tuple [1,2], &_p__1 [1,2], *_p__0, *_p__1]
or
- &_p__0 (1,2) - &_p__1 [1,2] - *_p__0 - *_p__1
and
lst=['foo',lst] _p__1=C(lst=lst,d=d,parent=_p__1) d={'a':'bar','c':d,'b':lst,'d':_p__1} [lst,d,_p__1]
==?
[&lst ['foo', *lst]], &d{'a','bar','c':*d,'b':*lst,'d':&_p__1 !!C {lst: *lst, d: *d, parent: *_p__1}}]
or in a multi-line format:
- &lst ['foo, *lst] - &d 'a': 'bar' 'c': *d 'b': *lst 'd': &_p__1 !!C lst: *lst d: *d parent: *_p__1
The only thing I see missing from Yaml is forward references which might be nice for producing more readable output in some cases but I don't think is technically necessary.
--- Bruce
On Wed, Nov 5, 2008 at 2:57 AM, Arnaud Delobelle <arnodel@googlemail.com> wrote:
On 05/11/2008, Zaur Shibzoukhov <szport@gmail.com> wrote:
I have added support for naming objects in dumps, cross-references and declarative support in dumps/loads too.
This is great stuff!
I can't now commit changes. This night I will commit changes to sources and update project pages.
Here are examples of how it works now: [...]
pyon.dumps([lst,d,c], fast = False, lst=lst, d=d)
How about changing the syntax slightly so that the given names are all in a dictionary:
pyon.dumps([lst, d, c], fast=False, given={'lst':lst, 'd':d}) (or one could use given=dict(lst=lst, d=d))
This would have two advantages:
* eliminate the rist of keyword argument name collision * one could put all the 'given' objects in a dictionary and then 'pickle' expressions as needed using this method. Later pyon.loads could be passed this dictionary so that the objects can be unpickled correctly.
I think this idea is good as it would make it possible to pickle some objects that contain unpicklable objects just by declaring them as 'given'.
<snip> _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas