Fredrik Lundh schrieb:
but given that the format *has* been stable for many years, surely it
would make more sense to just codify that fact, rather than developing
Yet Another Serialization Format instead?
There have been minor changes over time, e.g. r26146 (gvanrossum)
introduced TYPE_TRUE
I just got around to reading the messages.When I first saw this, I thought this is so that the processes that need to share and work on shared objects. That is where the locks are required. However, all shread objects are managed by the object manager and thus all such operations are in effect
M.-A. Lemburg [EMAIL PROTECTED] wrote:
This is hard to believe. I've been in that business for a few
years and so far have not found an OS/hardware/network combination
with the mentioned features.
Surely you must have - unless there is another M.-A. Lemburg in IT!
Some of the specialist
Josiah Carlson [EMAIL PROTECTED] wrote:
It would be convenient, yes, but the question isn't always 'threads or
processes?' In my experience (not to say that it is more or better than
anyone else's), when going multi-process, the expense on some platforms
is significant enough to want to
To: python-dev@python.org
Subject: [Python-Dev] Cloning threading.py using proccesses
I am not sure how sensible the idea is, but I have had a
first stab at writing a module processing.py which is a near
clone of threading.py but uses processes and sockets for
communication. (It is one way
On 10/10/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
Presumably with this library you have created, you have also written a
fast object encoder/decoder (like marshal or pickle). If it isn't any
faster than cPickle or marshal, then users may bypass the module and opt
On 10/10/06, Josiah Carlson [EMAIL PROTECTED] wrote:
the really interesting thing here is a ready-made threading-style API, I
think. reimplementing queues, locks, and semaphores can be a reasonable
amount of work; might as well use an existing implementation.
Really, it is a matter of
Fredrik Lundh wrote:
marshal hasn't changed in many years:
Maybe not, but I was given to understand that it's
regarded as a private format that's not guaranteed
to remain constant across versions. So even if
it happens not to change, it wouldn't be wise to
rely on that.
--
Greg
Greg Ewing wrote:
Fredrik Lundh wrote:
marshal hasn't changed in many years:
Maybe not, but I was given to understand that it's
regarded as a private format that's not guaranteed
to remain constant across versions. So even if
it happens not to change, it wouldn't be wise to
rely on
Josiah Carlson wrote:
Fredrik Lundh [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
Presumably with this library you have created, you have also written a
fast object encoder/decoder (like marshal or pickle). If it isn't any
faster than cPickle or marshal, then users may bypass the module
M.-A. Lemburg [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
Fredrik Lundh [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
Presumably with this library you have created, you have also written a
fast object encoder/decoder (like marshal or pickle). If it isn't any
faster than
Richard Oudkerk [EMAIL PROTECTED] wrote:
On 10/10/06, Josiah Carlson [EMAIL PROTECTED] wrote:
the really interesting thing here is a ready-made threading-style API, I
think. reimplementing queues, locks, and semaphores can be a reasonable
amount of work; might as well use an existing
Josiah It would basically be something along the lines of cPickle, but
Josiah would only support the basic types of: int, long, float, str,
Josiah unicode, tuple, list, dictionary.
Isn't that approximately marshal's territory? If you can write a faster
encoder/decoder, it might well
Fredrik Lundh [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
It would basically be something along the lines of cPickle, but would
only support the basic types of: int, long, float, str, unicode, tuple,
list, dictionary.
if you're aware of a way to do that faster than the current
On 10/12/06, Josiah Carlson [EMAIL PROTECTED] wrote:
It would basically be something along the lines of cPickle, but would
only support the basic types of: int, long, float, str, unicode, tuple,
list, dictionary.
Great idea! Check this thread for past efforts:
Fredrik Lundh wrote:
if you're aware of a way to do that faster than the current marshal
implementation, maybe you could work on speeding up marshal instead?
Even if it weren't faster than marshal, it could still
be useful to have something nearly as fast that used
a
Greg Ewing wrote:
if you're aware of a way to do that faster than the current marshal
implementation, maybe you could work on speeding up marshal instead?
Even if it weren't faster than marshal, it could still
be useful to have something nearly as fast that used
a
Richard Oudkerk [EMAIL PROTECTED] wrote:
I am not sure how sensible the idea is, but I have had a first stab at
writing a module processing.py which is a near clone of threading.py
but uses processes and sockets for communication. (It is one way of
avoiding the GIL.)
On non-windows
Josiah Carlson wrote:
Presumably with this library you have created, you have also written a
fast object encoder/decoder (like marshal or pickle). If it isn't any
faster than cPickle or marshal, then users may bypass the module and opt
for fork/etc. + XML-RPC
XML-RPC isn't close to marshal
Fredrik Lundh [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
Presumably with this library you have created, you have also written a
fast object encoder/decoder (like marshal or pickle). If it isn't any
faster than cPickle or marshal, then users may bypass the module and opt
for
20 matches
Mail list logo
