Into the parseString you can pass the serialized omitting the last char,
like ParseFromString(serialized[0:-1]).
That seemed to work for me.
-S
On Thursday, March 28, 2013 2:27:43 AM UTC-7, Oliver wrote:
On Thu, Mar 28, 2013 at 12:54 AM, W. David Jarvis vena...@gmail.com
javascript: wrote:
If I compare the len() of the two strings (pre-writing/reading v.
post-writing/reading) I tend to get two add'l chars on the reading, so I
guess I'm confused by how this is getting truncated? Is python running into
a newline char and interpreting it literally somehow?
Don't use 'print', use file.write(). Using print adds a newline (or
probably CRLF in your case). The encoded form is not self-delimiting so if
you include an extra CRLF in the bytes given to the decoder, it'll happily
try to interpret them, and then run out of data because the decoder's
interpretation of the extra bytes implies there should be more data
following them.
I wouldn't rely on sys.stdout being binary-safe either. The encoded forms
are binary, not text - you should treat them as such - if any conversion of
linefeeds happens, it will corrupt the message.
Oliver
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To unsubscribe from this group and stop receiving emails from it, send an email
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.