other language binding for gob

[notedit]

is there other people have done this?

i want to do the python binding for gob

--

Best Wishes..

[Krzysztof Kowalik]

Why would you need that? If you need to exchange data between py and go apps use protobuf, msgpack or dunno, json... imho gob is to much specific for go structures.

Cheers,

nu7

2012/1/29 notedit <not...@gmail.com>

[Krzysztof Kowalik]

Why would you need that? If you need to exchange data between py and go apps use protobuf, msgpack or dunno, json... imho gob is to much specific for go structures.

Cheers,

nu7

2012/1/29 notedit <not...@gmail.com>

is there other people have done this?

[notedit]

yes  i know that.

i want to implement  a python rpc client for  "net/rpc", and i do not like the json.

2012/1/30 Krzysztof Kowalik <ch...@nu7hat.ch>

--

Best Wishes..

[Krzysztof Kowalik]

KISS, json - comparing to gob - is much simpler and relatively efficient and has impl in all languages. "I don't like json" is bad excuse to port Go-specific to other lang.  

2012/1/29 notedit <not...@gmail.com>

[notedit]

yeah   i will think about it.

2012/1/30 Krzysztof Kowalik <ch...@nu7hat.ch>

--

Best Wishes..

[fango]

Please if you can. Gob is much better than JSON in several aspects:

1. Compact for binaries
2. Direct map to Go data structures.
3. Self-describing
4. Richness in data types.
5. Well defined internal representations.

Gob format is Language Neutral and the parser is not much harder than
the one for JSON. To me, JSON is just an evil hack of Javascript's
'eval'. It may serve JS because browser only natively supports this
encoding, but for RPC between other systems? No, thanks. We have Gob
in Go's land.

cheers,
fango

On Jan 29, 11:47 pm, notedit <note...@gmail.com> wrote:
> is there other people have done this?
>
> i want to do the python binding for gob
>
> --

> *
>
> Best Wishes..
>
> *

[Paul Borman]

I had this need.  I wanted to be able to send a message from a C++ program to a Go program that was already using Gob. 

You need to deal with the fact that Gob sends over type information symbolically.  You are going to end up having to tell your library the form of the data you are passing in or out. I think you would need to create a 1-1 mapping from Go native types to Python types.  C/C++ would be more challenging.  You would need some sort of descriptor language.

My final solution was a hack and I concluded if you want more than one language to be able to talk a protocol, don't use something language specific like Gob or Pickle, use something portable, like json or yaml.

    -Paul

[David Forsythe]

I came across this project a while ago: http://code.google.com/p/libgob/

I've never used it for anything, but it might be a way to get what you want.

--
David

[Krzysztof Kowalczyk]

JSON isn't any more "portable" than gob or pickle.

JSON = JavaScript Object Notation. JSON is only native to JavaScript -
every other language needs encoder/decoder with some amount of hackage
to account for inevitable impedance mismatch between what the language
can represent and what JSON can represent.

If anything, for languages like C/C++/Java/C#, Gob has a smaller
impedance mismatch than JSON. On the other hand, JSON probably better
fits languages like Python or Ruby. Which one is better depends on the
specifics of your problem.

Any serialization format in C or C++ will be awkward and hackish
because they lack the right reflection support but as far as choosing
a format for C/C++, Gob would probably work better than json (easier
to implement, faster), assuming you don't need human readability.

-- kjk

On Sun, Jan 29, 2012 at 10:29 PM, Paul Borman <bor...@google.com> wrote:

[Peter Bourgon]

On Mon, Jan 30, 2012 at 8:44 AM, Krzysztof Kowalczyk
<kkowa...@gmail.com> wrote:
> JSON isn't any more "portable" than gob or pickle.

Whaa?

> JSON = JavaScript Object Notation. JSON is only native to JavaScript -

"Nativity" is kind of a meaningless concept, as I can literally type JSON --

{
"guess_what": "valid JSON!",
"d": {
"really": true,
"difficulty": -1
}
}

-- which means implementing a JSON serialization mechanism for my
problem-domain in pretty much any language is as simple/trivial as it
gets. Try doing the same with .gob.

JSON is quickly becoming, or already is, the standard for all
non-performance-critical serialization jobs. That's awesome and a good
thing; don't fight it. :)

[David Leimbach]

On Jan 30, 12:14 am, Peter Bourgon <pe...@bourgon.org> wrote:
> On Mon, Jan 30, 2012 at 8:44 AM, Krzysztof Kowalczyk
>

> <kkowalc...@gmail.com> wrote:
> > JSON isn't any more "portable" than gob or pickle.
>
> Whaa?
>
> > JSON = JavaScript Object Notation. JSON is only native to JavaScript -

And almost Python. You can eval JSON in python if you just define
"true", "false" and "null" as symbols (with null maybe becoming
None). But yeah.

Dave

[André Moraes]

>
> i want to implement  a python rpc client for  "net/rpc", and i do not like
> the json.

An important question...

Why you don't like JSON?

I don't mean that JSON is a silver bullet, just need to understand why
JSON don't fit your problem? Or why gob is the right (and only)
solution to your problem.

Without that, is a little hard to provide some help.

The rpc package don't impose a format, you can write one that use
messagepack, protobuff, avro, asn1 etc..

--
André Moraes
http://andredevchannel.blogspot.com/

--
André Moraes
http://andredevchannel.blogspot.com/

[notedit]

json is not fast enough and it has limited types.

though, the netchan will use the gob too, so maybe i can implement the netchan protocol with python. 

make the communication between go and python more easily.

2012/1/31 André Moraes <and...@gmail.com>

--

Best Wishes..

[Paul Borman]

What about protobufs or messagepacks?  These are both designed for speed and not designed for a specific language.  I like the ease of gobs, and I am not opposed to having a good gob implementation in other languages, but they really are go-centric and all other languages will have some sort of funniness in the implementation.

    -Paul

[Rémy Oudompheng]

On 2012/1/30 Peter Bourgon <pe...@bourgon.org> wrote:
> On Mon, Jan 30, 2012 at 8:44 AM, Krzysztof Kowalczyk
> <kkowa...@gmail.com> wrote:
>> JSON isn't any more "portable" than gob or pickle.
>
> Whaa?
>
>> JSON = JavaScript Object Notation. JSON is only native to JavaScript -
>
> "Nativity" is kind of a meaningless concept, as I can literally type JSON --
>
>  {
>      "guess_what": "valid JSON!",
>      "d": {
>          "really": true,
>          "difficulty": -1
>      }
>  }
>
> -- which means implementing a JSON serialization mechanism for my
> problem-domain in pretty much any language is as simple/trivial as it
> gets. Try doing the same with .gob.
>
> JSON is quickly becoming, or already is, the standard for all
> non-performance-critical serialization jobs. That's awesome and a good
> thing; don't fight it. :)

Programs that care about performance can use BSON or MessagePack that
are binary and have implementations in many languages. BSON is
implemented in Python and Go as part of MongoDB bindings, and
MessagePack boasts many implementations as well.

Rémy.

[André Moraes]

2012/1/30 notedit <not...@gmail.com>:

> json is not fast enough and it has limited types.

Protocol Buffers, MessagePack, BSON

> though, the netchan will use the gob too, so maybe i can implement the
> netchan protocol with python.
>
> make the communication between go and python more easily.

This would take some effort, parsing gob code would probably be the easy part :)

In any case,

On the go side you can wrap your rpc-calls (using PB, MP, Bson,
etc...) with channels and hide that from the users of your library.
On the python side you don't have channels, so you still need to
implement a library on top of something since it don't have channels,
probably using twisted library.