Raymond Hettinger wrote:
* It will assist pypy style projects and other python implementations
when they have to build equivalents to CPython.
* Will eliminate confusion about what functions were exactly intended to
do.
* Will confer benefits similar to test driven development where the
On Thu, Oct 16, 2008 at 11:13 AM, Scott Dial
[EMAIL PROTECTED] wrote:
Raymond Hettinger wrote:
* It will assist pypy style projects and other python implementations
when they have to build equivalents to CPython.
* Will eliminate confusion about what functions were exactly intended to
do.
Raymond Hettinger wrote:
* It will assist pypy style projects and other python implementations
when they have to build equivalents to CPython.
* Will eliminate confusion about what functions were exactly intended to
do.
* Will confer benefits similar to test driven development where the
On Oct 16, 2008, at 5:11 PM, Raymond Hettinger wrote:
Raymond Hettinger wrote:
* It will assist pypy style projects and other python
implementations
when they have to build equivalents to CPython.
* Will eliminate confusion about what functions were exactly
intended to
do.
* Will
From: Doug Hellmann [EMAIL PROTECTED]
This seems like a large undertaking.
Not necessarily. It can be done incrementally, starting with things like str.split() that almost no one understands completely. It
should be put here and there where it adds some clarity.
I'm sure you're not
Raymond Hettinger wrote:
Bright idea
--
Let's go one step further and do this just about everywhere and instead of
putting it in the docs, attach an exec-able string as an
attribute to our C functions. Further, those pure python examples should
include doctests so that the user
On Fri, Oct 10, 2008 at 9:46 PM, Terry Reedy [EMAIL PROTECTED] wrote:
Brett Cannon wrote:
On Fri, Oct 10, 2008 at 1:45 PM, Terry Reedy [EMAIL PROTECTED] wrote:
The advantage of the decorator version is that the compiler or module
loader
could be special cased to recognize the 'C' decorator
On Thu, Oct 9, 2008 at 8:37 PM, [EMAIL PROTECTED] wrote:
On 9 Oct, 11:12 pm, [EMAIL PROTECTED] wrote:
Background
--
In the itertools module docs, I included pure python equivalents for each
of the C functions. Necessarily, some of those equivalents are only
approximate but they
[EMAIL PROTECTED] wrote:
On 9 Oct, 11:12 pm, [EMAIL PROTECTED] wrote:
Background
--
In the itertools module docs, I included pure python equivalents for
each of the C functions. Necessarily, some of those equivalents are
only approximate but they seem to have greatly enhanced the
On Fri, Oct 10, 2008 at 1:45 PM, Terry Reedy [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
On 9 Oct, 11:12 pm, [EMAIL PROTECTED] wrote:
Background
--
In the itertools module docs, I included pure python equivalents for each
of the C functions. Necessarily, some of those
Brett Cannon wrote:
On Fri, Oct 10, 2008 at 1:45 PM, Terry Reedy [EMAIL PROTECTED] wrote:
The advantage of the decorator version is that the compiler or module loader
could be special cased to recognize the 'C' decorator and try it first
*before* using the Python version, which would serve as
Background
--
In the itertools module docs, I included pure python equivalents for each of the C functions. Necessarily, some of those
equivalents are only approximate but they seem to have greatly enhanced the docs. Something similar is in the builtin docs for
any() and all(). The
Raymond Hettinger wrote: lots of cool stuff!
The idea sounds great!
Are you planing to embed the pure python code in C code? That's going to
increase the data segment of the executable. It should be possible to
disable and remove the pure python example with a simple ./configure
option and
[Christian Heimes]
The idea sounds great!
Are you planing to embed the pure python code in C code?
Am experimenting with a descriptor that fetches the attribute string from a separate text file. This keeps the C build from getting
fat. More importantly, it let's us write the execable
On Thu, Oct 9, 2008 at 4:12 PM, Raymond Hettinger [EMAIL PROTECTED] wrote:
[SNIP]
Bright idea
--
Let's go one step further and do this just about everywhere and instead of
putting it in the docs, attach an exec-able string as an attribute to our C
functions. Further, those pure
On Thu, Oct 9, 2008 at 8:50 PM, Raymond Hettinger [EMAIL PROTECTED] wrote:
[Christian Heimes]
The idea sounds great!
Are you planing to embed the pure python code in C code?
Am experimenting with a descriptor that fetches the attribute string from a
separate text file.
Have you ever
Yes, I'm looking a couple of different approaches to loading the strings.
For now though, I want to focus on the idea itself, not the implementation.
The important thing is to gather widespread support before getting into
the details of how the strings get loaded.
Raymond
- Original
On 9 Oct, 11:12 pm, [EMAIL PROTECTED] wrote:
Background
--
In the itertools module docs, I included pure python equivalents for
each of the C functions. Necessarily, some of those equivalents are
only approximate but they seem to have greatly enhanced the docs.
Why not go the other
This is a really interesting idea. If extra memory/lookup overhead is
a concern, you could enable this new feature by default when the
interactive interpreter is started (where it's more likely to be
invoked), and turn it off by default when running scripts/modules.
Jared
On 9 Oct 2008,
19 matches
Mail list logo
