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 un
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 confer
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
documen
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
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
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 us
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
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 a
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,
[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 doc
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
>> approxi
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, at
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
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 Messa
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 y
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
[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 string
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 so
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 ne
19 matches
Mail list logo
