On Sun, Apr 22, 2012 at 6:34 PM, Nick Coghlan wrote:
> On Mon, Apr 23, 2012 at 9:27 AM, Alexandre Vassalotti
> wrote:
>> On Sun, Apr 22, 2012 at 6:12 PM, wrote:
>>> Of course, this being free software, anybody can spend time on whatever
>>> they
>>> please, and this should not make anybody feel
On Mon, Apr 23, 2012 at 9:27 AM, Alexandre Vassalotti
wrote:
> On Sun, Apr 22, 2012 at 6:12 PM, wrote:
>> Of course, this being free software, anybody can spend time on whatever
>> they
>> please, and this should not make anybody feel sad. You just don't get
>> merits
>> if you work on stuff that
On Sun, Apr 22, 2012 at 6:12 PM, wrote:
> So I disagree that we could easily reach the point where it's "close to
>> the
>> speed of what we have." And if we were to attempt this, it would be a
>> multiple months undertaking. I would rather see that time spent on
>> improving pickle than on yet
Alexandre Vassalotti wrote:
We have custom stack and
dictionary implementations just for the sake of speed. We also have fast
paths for I/O operations and function calls.
All of that could very likely be carried over almost
unchanged into a Cython version. I don't see why it
should take mult
So I disagree that we could easily reach the point where it's "close to the
speed of what we have." And if we were to attempt this, it would be a
multiple months undertaking. I would rather see that time spent on
improving pickle than on yet another reimplementation.
Of course, this being free s
On Thu, Apr 19, 2012 at 4:55 AM, Stefan Behnel wrote:
>
> That sounds like less than two weeks of work, maybe even if we add the
> marshal module to it.
> In less than a month of GSoC time, this could easily reach a point where
> it's "close to the speed of what we have" and "fast enough", but a l
On Thu, Apr 19, 2012 at 17:21, Stefan Behnel wrote:
> Brian Curtin, 19.04.2012 23:19:
>> On Thu, Apr 19, 2012 at 16:08, Stefan Behnel
While code generation alleviates the burden of tedious languages, it's also
infinitely more complex, makes debugging very difficult and adds to
prere
Brian Curtin, 19.04.2012 23:19:
> On Thu, Apr 19, 2012 at 16:08, Stefan Behnel
>>> While code generation alleviates the burden of tedious languages, it's also
>>> infinitely more complex, makes debugging very difficult and adds to
>>> prerequisite knowledge, among other drawbacks.
>>
>> You can use
On Thu, Apr 19, 2012 at 16:08, Stefan Behnel
>> While code generation alleviates the burden of tedious languages, it's also
>> infinitely more complex, makes debugging very difficult and adds to
>> prerequisite knowledge, among other drawbacks.
>
> You can use gdb for source level debugging of Cyth
Matt Joiner, 19.04.2012 16:13:
> Personally I find the unholy product of C and Python that is Cython to be
> more complex than the sum of the complexities of its parts. Is it really
> wise to be learning Cython without already knowing C, Python, and the
> CPython object model?
The main obstacle th
Personally I find the unholy product of C and Python that is Cython to be
more complex than the sum of the complexities of its parts. Is it really
wise to be learning Cython without already knowing C, Python, and the
CPython object model?
While code generation alleviates the burden of tedious lang
On Thu, 19 Apr 2012 14:44:06 +0200, Antoine Pitrou wrote:
> Also, while C is a low-level language, Cython is a different language
> than Python when you start using its optimization features. This means
> core developers have to learn that language.
Hmm. On the other hand, perhaps some core deve
On Thu, Apr 19, 2012 at 05:38, Nick Coghlan wrote:
> On Thu, Apr 19, 2012 at 6:55 PM, Stefan Behnel wrote:
>> What do you think?
>
> I think the possible use of Cython for standard library extension
> modules is potentially worth looking into for the 3.4 timeframe (c.f.
> the recent multiple chec
On Thu, 19 Apr 2012 10:55:24 +0200
Stefan Behnel wrote:
>
> I noticed that there is a PEP (3154) and a GSoC proposal about improving
> Pickle. Given the recent discussion on this list about using Cython for the
> import module, I wonder if it wouldn't make even more sense to switch from
> a C (ac
On Thu, Apr 19, 2012 at 6:55 PM, Stefan Behnel wrote:
> What do you think?
I think the possible use of Cython for standard library extension
modules is potentially worth looking into for the 3.4 timeframe (c.f.
the recent multiple checkins sorting out the refcounts for the new
ImportError helper
> What do you think?
I think I know what Jim Fulton thinks (as we talked about something
like this a PyCon): don't. He is already sad that cPickle grew so much
pickle features when it was designed as a real fast implementation.
pickle speed is really important to some users, and any loss of
perfor
Hi,
I noticed that there is a PEP (3154) and a GSoC proposal about improving
Pickle. Given the recent discussion on this list about using Cython for the
import module, I wonder if it wouldn't make even more sense to switch from
a C (accelerator) implementation to Cython for _pickle.
The rationale
17 matches
Mail list logo
