Le mercredi 19 juin 2013, Scott Dial a écrit :
> On 6/18/2013 4:40 PM, Victor Stinner wrote:
> > No context argument
>
> I think there is a lack of justification for the extra argument, and the
> extra argument is not free. The typical use-case for doing this
> continuation-passing style is when t
On 6/18/2013 11:32 PM, Nick Coghlan wrote:
> Agreed more of that rationale needs to be moved from the issue tracker
> into the PEP, though.
Thanks for the clarification. I hadn't read the issue tracker at all. On
it's face value, I didn't see what purpose it served, but having read
Kristján's comm
On 16 June 2013 05:46, Ethan Furman wrote:
> So I have the stdlb 3.4 Enum backported for both earlier 3.x and back to 2.4
> in the 2.x series.
We should resolve http://bugs.python.org/issue17961 (switching the
functional creation API to use strings instead of 1-based integers)
before we get too g
On 19 June 2013 09:23, Scott Dial wrote:
> On 6/18/2013 4:40 PM, Victor Stinner wrote:
>> No context argument
>> ---
>>
>> Simplify the signature of allocator functions, remove the context
>> argument:
>>
>> * ``void* malloc(size_t size)``
>> * ``void* realloc(void *ptr, size_t new
On Jun 16, 2013, at 01:13 PM, Eli Bendersky wrote:
>If you write down the process of porting mailmain from flufl to stdlib.enum
>in some place, it can make the process much easier for others, and even
>encourage them to follow the same path.
Let's write it down here! It was mostly mechanical, an
On 6/18/2013 4:40 PM, Victor Stinner wrote:
> No context argument
> ---
>
> Simplify the signature of allocator functions, remove the context
> argument:
>
> * ``void* malloc(size_t size)``
> * ``void* realloc(void *ptr, size_t new_size)``
> * ``void free(void *ptr)``
>
> It is l
typedef struct {
/* user context passed as the first argument
to the 2 functions */
void *ctx;
/* allocate a memory mapping */
void* (*alloc) (void *ctx, size_t size);
/* release a memory mapping */
void (*free) (void *ctx, void *ptr,
If you prefer the HTML version:
http://www.python.org/dev/peps/pep-0445/
PEP: 445
Title: Add new APIs to customize Python memory allocators
Version: $Revision$
Last-Modified: $Date$
Author: Victor Stinner
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 15-june-2013
Python-Ve
Am 18.06.2013 13:32, schrieb Victor Stinner:
> 2013/6/18 Christian Heimes :
>> Am 18.06.2013 12:56, schrieb Jeremy Kloth:
>>> On Mon, Jun 17, 2013 at 2:02 PM, victor.stinner
+#include
>>>
>>> This header is not present on Windows, thus breaking all the Windows
>>> buildbots. Perhaps it shoul
2013/6/18 Christian Heimes :
> Am 18.06.2013 12:56, schrieb Jeremy Kloth:
>> On Mon, Jun 17, 2013 at 2:02 PM, victor.stinner
>>> +#include
>>
>> This header is not present on Windows, thus breaking all the Windows
>> buildbots. Perhaps it should be wrapped in an AIX-specific #ifdef?
Oh really? P
Am 18.06.2013 12:56, schrieb Jeremy Kloth:
> On Mon, Jun 17, 2013 at 2:02 PM, victor.stinner
> wrote:
>> diff --git a/Modules/_ctypes/callproc.c b/Modules/_ctypes/callproc.c
>> --- a/Modules/_ctypes/callproc.c
>> +++ b/Modules/_ctypes/callproc.c
>> @@ -70,6 +70,7 @@
>>
>> #include
>> #include "
On Mon, Jun 17, 2013 at 2:02 PM, victor.stinner
wrote:
> diff --git a/Modules/_ctypes/callproc.c b/Modules/_ctypes/callproc.c
> --- a/Modules/_ctypes/callproc.c
> +++ b/Modules/_ctypes/callproc.c
> @@ -70,6 +70,7 @@
>
> #include
> #include "ctypes.h"
> +#include
This header is not present on
Raymond -
Why did you do this in the 2.7 branch?
It hasn't been done in 3.3 or default and it isn't not the sort of change
we make in a stable release branch without justification. What issue was
this for? What problem were you solving?
-gps
On Mon, Jun 17, 2013 at 11:08 PM, Ethan Furman w
13 matches
Mail list logo
