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 python-version-in
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 python-version-independe
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:
http://mail.python.org/p
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 c
On 10/11/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
Martin v. Löwis wrote:> Of course, if everybody would always recompile all extension modules> for a new Python feature release, those flags weren't necessary.a dynamic registration approach would be even better, with a single entry point
used to
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 we
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 marshal
implementation, maybe you could work on
"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 us
"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 a
I wrote:
>PyType_Register(NoddyType, PY_TP_METHODS, Noddy_methods);
methods and members could of course be registered to, so the implementation can
chose
how to store them (e.g. short lists for smaller method lists, dictionaries for
others).
___
Martin v. Löwis wrote:
> Of course, if everybody would always recompile all extension modules
> for a new Python feature release, those flags weren't necessary.
a dynamic registration approach would be even better, with a single entry point
used to register all methods and hooks your C extension
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 bypas
12 matches
Mail list logo
