Re: [Python-Dev] cpython (2.7): Fix comment blocks. Adjust blocksize to a power-of-two for better divmod

[Gregory P. Smith]

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  wrote:

> On 06/17/2013 09:05 PM, Eli Bendersky wrote:
>
>>
>>
>>
>> On Fri, Jun 14, 2013 at 6:47 AM, Serhiy Storchaka 
>> > storch...@gmail.com>> wrote:
>>
>> 14.06.13 11:46, Antoine Pitrou написав(ла):
>>
>> On Fri, 14 Jun 2013 07:06:49 +0200 (CEST)
>> raymond.hettinger > python-checkins@**python.org >> wrote:
>>
>> 
>> http://hg.python.org/cpython/_**_rev/5accb0ac8bfb<
>> http://hg.python.org/cpython/**rev/5accb0ac8bfb
>> >
>>
>> changeset:   84116:5accb0ac8bfb
>> Fix comment blocks.  Adjust blocksize to a power-of-two
>> for better divmod computations.
>>
>>
>> Is there any rationale for changing the heuristic from "fits in a
>> whole
>> number of cachelines" to "allows fast division by the blocksize"?
>>
>> I personally would prefer if such changes were justified a bit
>> more
>> than by a one-liner changeset message without any corresponding
>> open
>> issue.
>>
>>
>> I share the doubts of Antoine and I was going to write the same
>> comment. I thought there were good reasons for
>> previous code. What has changed?
>>
>>
>> I agree it would be interesting to hear about the reasons for the change.
>> Raymond?
>>
>
> Asking as a learner:  are such non-bugfix changes appropriate for the 2.7
> line?
>
> --
> ~Ethan~
>
> __**_
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/**mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/**mailman/options/python-dev/**
> greg%40krypto.org
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython (3.3): ctypes: AIX needs an explicit #include to get alloca()

[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 "ctypes.h"
> +#include 

This header is not present on Windows, thus breaking all the Windows
buildbots.  Perhaps it should be wrapped in an AIX-specific #ifdef?

-- 
Jeremy Kloth
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython (3.3): ctypes: AIX needs an explicit #include to get alloca()

[Christian Heimes]

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 "ctypes.h"
>> +#include 
> 
> This header is not present on Windows, thus breaking all the Windows
> buildbots.  Perhaps it should be wrapped in an AIX-specific #ifdef?

I have added HAVE_ALLOCA_H to configure:

http://hg.python.org/cpython/rev/7b6ae19dd116

Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython (3.3): ctypes: AIX needs an explicit #include to get alloca()

[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 should be wrapped in an AIX-specific #ifdef?

Oh really? Portability is complex :-) I only tested on Linux, but I
expected this header to be part of the C standard...

> I have added HAVE_ALLOCA_H to configure:
>
> http://hg.python.org/cpython/rev/7b6ae19dd116

Cool, thanks.

Victor
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython (3.3): ctypes: AIX needs an explicit #include to get alloca()

[Christian Heimes]

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 should be wrapped in an AIX-specific #ifdef?
> 
> Oh really? Portability is complex :-) I only tested on Linux, but I
> expected this header to be part of the C standard...

It's neither C99 nor POSIX.1-2001. I guess it's just too fragile and not
portable enough. http://c-faq.com/malloc/alloca.html

> 
>> I have added HAVE_ALLOCA_H to configure:
>>
>> http://hg.python.org/cpython/rev/7b6ae19dd116
> 
> Cool, thanks.

You are welcome. alloca() is documented to require . It merely
works with GCC because the compiler translates the function call to
inline code.

Christian

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] RFC: PEP 445: Add new APIs to customize Python memory allocators

[Victor Stinner]

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-Version: 3.4

Abstract


Add new APIs to customize Python memory allocators.


Rationale
=

Use cases:

* Application embedding Python may want to isolate Python memory from
  the memory of the application, or may want to use a different memory
  allocator optimized for its Python usage
* Python running on embedded devices with low memory and slow CPU.
  A custom memory allocator may be required to use efficiently the
  memory and/or to be able to use all the memory of the device.
* Debug tool to:

  - track the memory usage (memory leaks)
  - get the Python filename and line number where an object was
allocated
  - detect buffer underflow, buffer overflow and detect misuse of Python
allocator APIs (builtin Python debug hooks)
  - force allocation to fail to test handling of ``MemoryError``
exception


Proposal


API changes
---

* Add new GIL-free (no need to hold the GIL) memory allocator functions:

  - ``void* PyMem_RawMalloc(size_t size)``
  - ``void* PyMem_RawRealloc(void *ptr, size_t new_size)``
  - ``void PyMem_RawFree(void *ptr)``
  - the behaviour of requesting zero bytes is not defined: return *NULL*
or a distinct non-*NULL* pointer depending on the platform.

* Add a new ``PyMemBlockAllocator`` structure::

typedef struct {
/* user context passed as the first argument
   to the 3 functions */
void *ctx;

/* allocate a memory block */
void* (*malloc) (void *ctx, size_t size);

/* allocate or resize a memory block */
void* (*realloc) (void *ctx, void *ptr, size_t new_size);

/* release a memory block */
void (*free) (void *ctx, void *ptr);
} PyMemBlockAllocator;

* Add new functions to get and set internal functions of
  ``PyMem_RawMalloc()``, ``PyMem_RawRealloc()`` and ``PyMem_RawFree()``:

  - ``void PyMem_GetRawAllocator(PyMemBlockAllocator *allocator)``
  - ``void PyMem_SetRawAllocator(PyMemBlockAllocator *allocator)``
  - default allocator: ``malloc()``, ``realloc()``, ``free()``

* Add new functions to get and set internal functions of
  ``PyMem_Malloc()``, ``PyMem_Realloc()`` and ``PyMem_Free()``:

  - ``void PyMem_GetAllocator(PyMemBlockAllocator *allocator)``
  - ``void PyMem_SetAllocator(PyMemBlockAllocator *allocator)``
  - ``malloc(ctx, 0)`` and ``realloc(ctx, ptr, 0)`` must not return
*NULL*: it would be treated as an error.
  - default allocator: ``malloc()``, ``realloc()``, ``free()``;
``PyMem_Malloc(0)`` calls ``malloc(1)``
and ``PyMem_Realloc(NULL, 0)`` calls ``realloc(NULL, 1)``

* Add new functions to get and set internal functions of
  ``PyObject_Malloc()``, ``PyObject_Realloc()`` and
  ``PyObject_Free()``:

  - ``void PyObject_GetAllocator(PyMemBlockAllocator *allocator)``
  - ``void PyObject_SetAllocator(PyMemBlockAllocator *allocator)``
  - ``malloc(ctx, 0)`` and ``realloc(ctx, ptr, 0)`` must not return
*NULL*: it would be treated as an error.
  - default allocator: the *pymalloc* allocator

* Add a new ``PyMemMappingAllocator`` structure::

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, size_t size);
} PyMemMappingAllocator;

* Add a new function to get and set the memory mapping allocator:

  - ``void PyMem_GetMappingAllocator(PyMemMappingAllocator *allocator)``
  - ``void PyMem_SetMappingAllocator(PyMemMappingAllocator *allocator)``
  - Currently, this allocator is only used internally by *pymalloc* to
allocate arenas.

* Add a new function to setup the builtin Python debug hooks when memory
  allocators are replaced:

  - ``void PyMem_SetupDebugHooks(void)``
  - the function does nothing is Python is compiled not compiled in
debug mode

* The following memory allocators always returns *NULL* if size is
  greater than ``PY_SSIZE_T_MAX`` (check before calling the internal
  function): ``PyMem_RawMalloc()``, ``PyMem_RawRealloc()``,
  ``PyMem_Malloc()``, ``PyMem_Realloc()``, ``PyObject_Malloc()``,
  ``PyObject_Realloc()``.

The builtin Python debug hooks were introduced in Python 2.3 and
implement the following checks:

* Newly allocated memory is filled with the byte ``0xCB``, freed memory
  is filled with the byte ``0xDB``.
* Detect API violations, ex: ``PyObject_Free()`` called on a memory
  block allocated by ``PyMem_Malloc()``
* Detect write before the start of the buffer (buffer underflow)
* Detect write after the end of the buffer (buffer overflow)


Other changes
--

Re: [Python-Dev] RFC: PEP 445: Add new APIs to customize Python memory allocators

[Victor Stinner]

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, size_t size);
} PyMemMappingAllocator;

The PyMemMappingAllocator structure is very specific to the pymalloc
allocator. There is no "resize", "lock" nor "protect" method. There is
no way to configure protection or flags of the mapping. The
PyMem_SetMappingAllocator() function was initially called
_PyObject_SetArenaAllocator(). I'm not sure that the structure and the
2 related functions should be public. Can an extension module call
private (_Py*) functions or use a private structure?

Or the structure might be renamed to indicate that it is specific to arenas?

What do you think?

Victor
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] RFC: PEP 445: Add new APIs to customize Python memory allocators

[Scott Dial]

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 likely for an allocator hook to be reused for
> ``PyMem_SetAllocator()`` and ``PyObject_SetAllocator()``, or even
> ``PyMem_SetRawAllocator()``, but the hook must call a different function
> depending on the allocator. The context is a convenient way to reuse the
> same custom allocator or hook for different Python allocators.

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 the set of contexts is either
unknown, arbitrarily large, or infinite. In other words, when it would
be either impossible or impractical to enumerate all of the contexts.
However, in this case, we have only 3.

Your proposal already puts forward having 3 pairs of Get/Set functions,
so there is no distinct advantage in having a single typedef instance
that you pass in to all 3 of them. And, having all 3 pairs use the same
typedef is a bit of an attractive nuisance, in that one could pass the
wrong allocators to the wrong setter. With that, I could argue that
there should be 3 typedefs to prevent coding errors.

Nevertheless, the ctx argument buys the implementer nothing if they have
to begin their alloc function with "if(ctx == X)". In other words, there
is nothing simpler about:

"""
void *_alloc(void *ctx, size_t size) {
  if(ctx == PYALLOC_PYMEM)
return _alloc_pymem(size);
  else if(ctx == PYALLOC_PYMEM_RAW)
return _alloc_pymem_raw(size);
  else if(ctx == PYALLOC_PYOBJECT)
return _alloc_pyobject(size);
  else
abort();
}

PyMemBlockAllocator pymem_allocator =
  {.ctx=PYALLOC_PYMEM, .alloc=&_alloc, .free=&_free};
PyMemBlockAllocator pymem_raw_allocator =
  {.ctx=PYALLOC_PYMEM_RAW, .alloc=&_alloc, .free=&_free};
PyMemBlockAllocator pyobject_allocator =
  {.ctx=PYALLOC_PYOBJECT, .alloc=&_alloc, .free=&_free};
"""

In comparison to:

"""
PyMemBlockAllocator pymem_allocator =
  {.alloc=&_alloc_pymem, .free=&_free_pymem};
PyMemBlockAllocator pymem_raw_allocator =
  {.alloc=&_alloc_pymem_raw, .free=&_free_pymem};
PyMemBlockAllocator pyobject_allocator =
  {.alloc=&_alloc_pyobject, .free=&_free_pyobject};
"""

And in the latter case, there is no extra indirect branching in the
hot-path of the allocators.

Also, none of the external libraries cited introduce this CPS/ctx stuff.

-- 
Scott Dial
sc...@scottdial.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] backported Enum

[Barry Warsaw]

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, and some probably would
have been done to fix deprecations in flufl.enum.  Here's the list.

Switching from call syntax to getitem syntax for looking up an enum member by
name, e.g.

-delivery_mode = DeliveryMode(data['delivery_mode'])
+delivery_mode = DeliveryMode[data['delivery_mode']]

Switching from getitem syntax to call syntax for looking up an enum member by
value, e.g.

-return self._enum[value]
+return self._enum(value)

Interesting that these two were exactly opposite from flufl.enum.

Switching from int() to .value to get the integer value of an enum member,
e.g.

-return (member.list_id, member.address.email, int(member.role))
+return (member.list_id, member.address.email, member.role.value)

Changing the imports (obviously), e.g.

-from flufl.enum import Enum
+from enum import Enum

Adapting to the different repr as seen in a doctest, e.g.

-
+

Fixing some type tests.  I have one case that was testing for an enum member
to do value type conversion.  Since enum members are now instances of their
enum class, and because members no longer have a .enum attribute (because you
can just ask for its __class__), the type test actually became simpler:

-elif hasattr(obj, 'enum') and issubclass(obj.enum, Enum):
+elif isinstance(obj, Enum):

An unexpected difference is that failing name lookups raise a KeyError instead
of a ValueError.  There are many cases where I catch failing lookups in my
REST API.  Fixing this was mostly easy...

-except ValueError:
+except KeyError:

...except in one case where I was previously allowing the ValueError to
percolate up to signal to a higher level that some exception handling had to
be done.  Here, I had to convert the exception:

-# This will raise a ValueError if the enum value is unknown.  Let
-# that percolate up.
-return self._enum_class[enum_value]
+# This will raise a KeyError if the enum value is unknown.  The
+# Validator API requires turning this into a ValueError.
+try:
+return self._enum_class[enum_value]
+except KeyError as exception:
+# Retain the error message.
+raise ValueError(exception.message)

Interestingly, I found an existing hidden bug in an upgrade script where I was
not converting a value from an integer to an enum.  Nice to catch that one.

For now, I'll hold out on merging this branch to trunk until I can get enum34
packaged up for Debian.  Other than that, it looks pretty good!

Merge proposal: http://tinyurl.com/l2fq38l
Branch: https://code.launchpad.net/~barry/mailman/pep435

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] RFC: PEP 445: Add new APIs to customize Python memory allocators

[Nick Coghlan]

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_size)``
>> * ``void free(void *ptr)``
>>
>> It is likely for an allocator hook to be reused for
>> ``PyMem_SetAllocator()`` and ``PyObject_SetAllocator()``, or even
>> ``PyMem_SetRawAllocator()``, but the hook must call a different function
>> depending on the allocator. The context is a convenient way to reuse the
>> same custom allocator or hook for different Python allocators.
>
> 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 the set of contexts is either
> unknown, arbitrarily large, or infinite. In other words, when it would
> be either impossible or impractical to enumerate all of the contexts.
> However, in this case, we have only 3.

Note that the context is part of the BlockAllocator structure, NOT
predefined by Python.

> Your proposal already puts forward having 3 pairs of Get/Set functions,
> so there is no distinct advantage in having a single typedef instance
> that you pass in to all 3 of them. And, having all 3 pairs use the same
> typedef is a bit of an attractive nuisance, in that one could pass the
> wrong allocators to the wrong setter. With that, I could argue that
> there should be 3 typedefs to prevent coding errors.

I'm not sure we *should* be restricting this to the CPython internal
domains indefinitely. If we use a domain based model from the start,
then that will allow us in the future to let extension modules declare
additional domains rather than having to employ library specific logic
in either the CPython core or in embedding applications.

> Nevertheless, the ctx argument buys the implementer nothing if they have
> to begin their alloc function with "if(ctx == X)". In other words, there
> is nothing simpler about:
>
> """
> void *_alloc(void *ctx, size_t size) {
>   if(ctx == PYALLOC_PYMEM)
> return _alloc_pymem(size);
>   else if(ctx == PYALLOC_PYMEM_RAW)
> return _alloc_pymem_raw(size);
>   else if(ctx == PYALLOC_PYOBJECT)
> return _alloc_pyobject(size);
>   else
> abort();
> }
>
> PyMemBlockAllocator pymem_allocator =
>   {.ctx=PYALLOC_PYMEM, .alloc=&_alloc, .free=&_free};
> PyMemBlockAllocator pymem_raw_allocator =
>   {.ctx=PYALLOC_PYMEM_RAW, .alloc=&_alloc, .free=&_free};
> PyMemBlockAllocator pyobject_allocator =
>   {.ctx=PYALLOC_PYOBJECT, .alloc=&_alloc, .free=&_free};
> """

Why would anyone do that? The context is so embedding applications can
distinguish the CPython runtime from their *other* domains that use
the same allocator functions. If you wanted to use completely
different allocators for each domain, you would just do that and
ignore the context argument entirely.

Agreed more of that rationale needs to be moved from the issue tracker
into the PEP, though.

Cheers,
Nick.

--
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] backported Enum

[Nick Coghlan]

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 gung ho about encouraging people to use the
backport.

Cheers,
Nick.

--
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] RFC: PEP 445: Add new APIs to customize Python memory allocators

[Scott Dial]

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 comments on the issue tracker, he would like to store state
for the allocators in that ctx pointer.[1] Having read that (previously,
I thought the only utility was distinguishing which domain it was -- a
small, glorified enumeration), but his use-case makes sense and
definitely is informative to have in the PEP, because the utility of
that wasn't obvious to me.

Thanks,
-Scott

[1] http://bugs.python.org/issue3329#msg190529
"""
One particular trick we have been using, which might be of interest, is
to be able to tag each allocation with a "context" id.  This is then set
according to a global sys.memcontext variable, which the program will
modify according to what it is doing.  This can then be used to track
memory usage by different parts of the program.
"""

-- 
Scott Dial
sc...@scottdial.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] RFC: PEP 445: Add new APIs to customize Python memory allocators

[Victor Stinner]

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 the set of contexts is either
> unknown, arbitrarily large, or infinite. In other words, when it would
> be either impossible or impractical to enumerate all of the contexts.
> However, in this case, we have only 3.


See the use case 3 in examples. Without the context argument, you have to
copy/paste 3 times each functions: 3 functions -> 9 functions. I don't like
having to copy/paste code, it sounds like a bad design.


> And in the latter case, there is no extra indirect branching in the
> hot-path of the allocators.


Are you concerned by performances? Did you see the Performances section,
there is no overhead according to the benchmark suite.


>
> Also, none of the external libraries cited introduce this CPS/ctx stuff.


Oops, the list is incomplete. Copy/paste from the issue:


Some customizable memory allocators I know have an extra parameter
"void *opaque" that is passed to all functions:

- in zlib: zalloc and zfree: http://www.zlib.net/manual.html#Usage
- same thing for bz2.
- lzma's ISzAlloc: http://www.asawicki.info/news_1368_lzma_sdk_-_how_to_use.html
- Oracle's OCI:
http://docs.oracle.com/cd/B10501_01/appdev.920/a96584/oci15re4.htm

OTOH, expat, libxml, libmpdec don't have this extra parameter.

Victor
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com