Josiah Carlson wrote:
> Fernando Perez <[EMAIL PROTECTED]> wrote:
>> Would you care to elaborate on the reasons behind the 'ick'? I'm a big fan
>> of weave.inline and have used it very successfully for my own needs, so I'm
>> genuinely curious (as I tend to teach its use, I like to know of poten
Fernando Perez <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > Here's a perspective "from the trenches" as it were.
> >
> > I've been writing quite a bit of code, initially all in Python (27k
> > lines in the last year or so). It worked reasonably well and fast. It
> > wasn't fast enough.
Josiah Carlson wrote:
> Here's a perspective "from the trenches" as it were.
>
> I've been writing quite a bit of code, initially all in Python (27k
> lines in the last year or so). It worked reasonably well and fast. It
> wasn't fast enough. I needed a 25x increase in performance, which would
>
Phillip J. Eby wrote:
> Just an FYI; Pyrex certainly makes it relatively painless to write code
> that interfaces with C, but it doesn't do much for performance, and
> naively-written Pyrex code can actually be slower than
> carefully-optimized Python code. So, for existing modules that were
Guido van Rossum wrote:
> How stable is Pyrex? Would you be willing to integrate it thoroughly
> with the Python source tree, to the point of contributing the code to
> the PSF? (Without giving up ownership or responsibility for its
> maintenance.)
It's reasonably stable now, I think, although so
Christopher Armstrong <[EMAIL PROTECTED]> wrote:
> On 9/7/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > On 9/6/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > > > A better plan would be to build something akin to
> > > > Pyrex into the scheme of
On 9/7/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 9/6/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > > A better plan would be to build something akin to
> > > Pyrex into the scheme of things, so that all the
> > > refcount/GC issues are take
On Wed, Sep 07, 2005 at 02:01:01AM -0400, Phillip J. Eby wrote:
[...]
> Just an FYI; Pyrex certainly makes it relatively painless to write code
> that interfaces with C, but it doesn't do much for performance, and
> naively-written Pyrex code can actually be slower than carefully-optimized
> Pyt
Fredrik Lundh wrote:
> Josiah Carlson wrote:
>
>>Perhaps a bit into the future, extending import semantics to notice .pyx
>>files, compare their checksum against a stored md5 in the compiled
>>.pyd/.so, and automatically recompiling them if they (or their includes)
>>have changed: +10 (I end up do
Josiah Carlson wrote:
> Perhaps a bit into the future, extending import semantics to notice .pyx
> files, compare their checksum against a stored md5 in the compiled
> .pyd/.so, and automatically recompiling them if they (or their includes)
> have changed: +10 (I end up doing this kind of thing by
Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 9/6/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > A better plan would be to build something akin to
> > Pyrex into the scheme of things, so that all the
> > refcount/GC issues are taken care of automatically.
>
> That sounds exciting. I have to adm
Greg Ewing <[EMAIL PROTECTED]> writes:
> Guido van Rossum wrote:
>
>>>While we're on the subject of Python 3000, what's the
>>>chance that reference counting when calling C
>>>functions from Python will go away?
>>
>> We'd have to completely change the implementation. We're not
>> planning on tha
At 09:58 PM 9/6/2005 -0700, Guido van Rossum wrote:
>On 9/6/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > A better plan would be to build something akin to
> > Pyrex into the scheme of things, so that all the
> > refcount/GC issues are taken care of automatically.
>
>That sounds exciting. I have to
Guido van Rossum wrote:
> How stable is Pyrex? Would you be willing to integrate it thoroughly
> with the Python source tree, to the point of contributing the code to
> the PSF? (Without giving up ownership or responsibility for its
> maintenance.)
+100
I would be *strongly* in favour of this. A
On 9/6/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
> A better plan would be to build something akin to
> Pyrex into the scheme of things, so that all the
> refcount/GC issues are taken care of automatically.
That sounds exciting. I have to admit that despite hearing many
enthusiastic reviews, I've n
Guido van Rossum wrote:
>>While we're on the subject of Python 3000, what's the
>>chance that reference counting when calling C
>>functions from Python will go away?
>
> We'd have to completely change the implementation. We're not planning on that.
Also, the refcounting would have to be replaced
On Sep 6, 2005, at 12:13 PM, Steve Holden wrote:
> Nick Jacobson wrote:
>
>> While we're on the subject of Python 3000, what's the
>> chance that reference counting when calling C
>> functions from Python will go away?
>>
>> To me this is one of the few annoyances I have with
>> Python. I know t
Nick Jacobson wrote:
> While we're on the subject of Python 3000, what's the
> chance that reference counting when calling C
> functions from Python will go away?
>
> To me this is one of the few annoyances I have with
> Python. I know that Ruby somehow gets around the need
> for ref. counting.
>
On 9/6/05, Nick Jacobson <[EMAIL PROTECTED]> wrote:
> While we're on the subject of Python 3000, what's the
> chance that reference counting when calling C
> functions from Python will go away?
We'd have to completely change the implementation. We're not planning on that.
> To me this is one of t
While we're on the subject of Python 3000, what's the
chance that reference counting when calling C
functions from Python will go away?
To me this is one of the few annoyances I have with
Python. I know that Ruby somehow gets around the need
for ref. counting.
__
20 matches
Mail list logo
