On 12/18/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I think a reasonable solution here is to make the C version an
> optional implementation detail of the Python version, such as was done
> for the heapq module already (the C version is _heapq and
> automatically imported by heapq.py if it e
On 12/19/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > I think a reasonable solution here is to make the C version an
> > optional implementation detail of the Python version, such as was done
> > for the heapq module already (the C version is _heapq and
> > automaticall
Guido van Rossum wrote:
> I think a reasonable solution here is to make the C version an
> optional implementation detail of the Python version, such as was done
> for the heapq module already (the C version is _heapq and
> automatically imported by heapq.py if it exists). If this requires
> that s
I think a reasonable solution here is to make the C version an
optional implementation detail of the Python version, such as was done
for the heapq module already (the C version is _heapq and
automatically imported by heapq.py if it exists). If this requires
that some of the C modules need to be up
Thomas Wouters wrote:
> Except, of course, when the Python versions has features the C version
> does not (thinking specifically of StringIO and unicode here.)
Yes, I'm assuming the case where the Python and C
versions are functionally equivalent. If not, then
either the extra features of the Py
On Dec 11, 2006, at 9:10 PM, Brett Cannon wrote:
On 12/10/06, Calvin Spealman <[EMAIL PROTECTED]> wrote:
Has anyone considered consolidating the module pairs that have both a
C and Python implementation? For example, pickle and cPickle and
StingIO and cStringIO. It seems like keeping both aro
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 11, 2006, at 6:50 PM, Greg Ewing wrote:
> I say stop worrying and ditch the Python version. An
> alternative Python implementation is going to have to
> provide implementations of all the existing C-only
> modules. A few more isn't going to kil
On 12/11/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
Brett Cannon wrote:
> It has been suggested we actually
> ditch the C version since we only want to maintain one version and the
> Python version can be used by alternative Python implementations.
Then we would lose all the speed advantages tha
Brett Cannon wrote:
> It has been suggested we actually
> ditch the C version since we only want to maintain one version and the
> Python version can be used by alternative Python implementations.
Then we would lose all the speed advantages that were
presumably thought important when the C versi
Brett Cannon wrote:
> This has been argued about before. It has been suggested we actually
> ditch the C version since we only want to maintain one version and the
> Python version can be used by alternative Python implementations.
>
> This probably needs to be covered in a PEP that covers a st
On 12/10/06, Calvin Spealman <[EMAIL PROTECTED]> wrote:
Has anyone considered consolidating the module pairs that have both a
C and Python implementation? For example, pickle and cPickle and
StingIO and cStringIO. It seems like keeping both around might be
counter productive. It leads to more co
11 matches
Mail list logo
