On 4 Jul 2005 19:45:07 -0700, rumours say that [EMAIL PROTECTED]
might have written:
>Time and space efficiency, and security do not have to be mutually
>exclusive features of a serializer. Python does not provide, in the
>standard library, a serializer which can work safely with untru
Ok, I've attached the proto PEP below.
Comments on the proto PEP and the implementation are appreciated.
Sw.
Title: Secure, standard serialization of simple python types.
Abstract
This PEP suggests the addition of a module to the standard library,
which provides a serialization class
[EMAIL PROTECTED] writes:
> If anyone is interested, I've implemented a faster and more space
> efficient gherkin with a few bug fixes.
It would be nice if you just posted the PEP.
--
http://mail.python.org/mailman/listinfo/python-list
[EMAIL PROTECTED] writes:
> > See also bug# 471893 where jhylton suggests a PEP. Something really
> > ought to be done about this.
>
> I know this, you know this... I don't understand why the suggestion is
> meeting so much resistance. This is something I needed for a real world
> system which mo
If anyone is interested, I've implemented a faster and more space
efficient gherkin with a few bug fixes.
http://developer.berlios.de/project/showfiles.php?group_id=2847
--
http://mail.python.org/mailman/listinfo/python-list
> See also bug# 471893 where jhylton suggests a PEP. Something really
> ought to be done about this.
I know this, you know this... I don't understand why the suggestion is
meeting so much resistance. This is something I needed for a real world
system which moves lots of data around to untrusted
[EMAIL PROTECTED] writes:
> > I think you should implement it as a C extension and/or write a PEP.
> > This has been an unfilled need in Python for a while (SF RFE 467384).
>
> I've submitted a proto PEP to python-dev. It coming up against many of
> the same objections to the RFE.
See also bug# 4
> I think you should implement it as a C extension and/or write a PEP.
> This has been an unfilled need in Python for a while (SF RFE 467384).
I've submitted a proto PEP to python-dev. It coming up against many of
the same objections to the RFE.
Sw.
--
http://mail.python.org/mailman/listinfo/py
[EMAIL PROTECTED] writes:
> It appears to work faster than pickle, however, the decode process is
> much slower (5x) than the encode process. Has anyone got any tips on
> ways I might speed this up?
I think you should implement it as a C extension and/or write a PEP.
This has been an unfilled need
Running stest.py produced these results for me:
marshal enc T: 12.5195908977
marshal dec T: 0.134508715493
sencode enc T: 3.75118904777
sencode dec T: 5.86602012267
11.9369997978
0.109000205994
True
Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)]
on win32
Notice the slow "m
[EMAIL PROTECTED] wrote:
> Andrew Dalke wrote:
>> This is with Python 2.3; the stock one provided by Apple
>> for my Mac.
>
> Ahh that is the difference. I'm running Python 2.4. I've checked my
> benchmarks on a friends machine, also in Python 2.4, and received the
> same results as my machine.
>
simonwittber wrote:
> It would appear that the new version 1 format introduced in Python 2.4
> is much slower than version 0, when using the dumps function.
Interesting. Hadn't noticed that change. Is dump(StringIO()) as
slow?
Andrew
Andrew Dalke wrote:
> This is with Python 2.3; the stock one provided by Apple
> for my Mac.
Ahh that is the difference. I'm running Python 2.4. I've checked my
benchmarks on a friends machine, also in Python 2.4, and received the
same results as my machine.
> I expected the numbers to be like t
simonwittber posted his test code.
I tooks the code from the cookbook, called it "sencode" and
added these two lines
dumps = encode
loads = decode
I then ran your test code (unchanged except that my newsreader
folded the "value = ..." line) and got
marshal enc T: 0.21
marshal dec T: 0.4
sencod
> I can't reproduce your large times for marshal.dumps. Could you
> post your test code?
Certainly:
import sencode
import marshal
import time
value = [r for r in xrange(100)] +
[{1:2,3:4,5:6},{"simon":"wittber"}]
t = time.clock()
x = marshal.dumps(value)
print "marshal enc T:", time.clock
simonwittber wrote:
> marshal can serialize small structures very qucikly, however, using the
> below test value:
>
> value = [r for r in xrange(100)] +
> [{1:2,3:4,5:6},{"simon":"wittber"}]
>
> marshal took 7.90 seconds to serialize it into a 561 length string.
> decode took 0.08 seconds
> Ahh, I had forgotten that. Though I can't recall what an attack
> might be, I think it's because the C code hasn't been fully vetted
> for unexpected error conditions.
I tried out the marshal module anyway.
marshal can serialize small structures very qucikly, however, using the
below test va
simonwittber wrote:
>>From the marhal documentation:
> Warning: The marshal module is not intended to be secure against
> erroneous or maliciously constructed data. Never unmarshal data
> received from an untrusted or unauthenticated source.
Ahh, I had forgotten that. Though I can't recall what
> For simple data types consider "marshal" as an alternative to "pickle".
>From the marhal documentation:
Warning: The marshal module is not intended to be secure against
erroneous or maliciously constructed data. Never unmarshal data
received from an untrusted or unauthenticated source.
> BTW, y
simonwittber wrote:
> I've written a simple module which serializes these python types:
>
> IntType, TupleType, StringType, FloatType, LongType, ListType, DictType
For simple data types consider "marshal" as an alternative to "pickle".
> It appears to work faster than pickle, however, the decode
I've written a simple module which serializes these python types:
IntType, TupleType, StringType, FloatType, LongType, ListType, DictType
It available for perusal here:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/415503
It appears to work faster than pickle, however, the decode proc
21 matches
Mail list logo
