On 05/18/2012 12:57 AM, Nick Coghlan wrote:
I think the main things we'd be looking for would be:
- a clear explanation of why a new metaclass is considered too complex a
solution
- what the implications are for classes that have nothing to do with the
SciPy/NumPy ecosystem
- how subclassing woul
If we in the end decide that we would like a propose the PEP, does
anyone feel the odds are anything but very, very slim? I don't think
I've heard a single positive word about the proposal so far except
from Cython devs, so I'm reluctant to spend my own and your time on
a fleshing out a ful
I think the main things we'd be looking for would be:
- a clear explanation of why a new metaclass is considered too complex a
solution
- what the implications are for classes that have nothing to do with the
SciPy/NumPy ecosystem
- how subclassing would behave (both at the class and metaclass leve
On 05/17/2012 05:00 AM, Greg Ewing wrote:
On 17/05/12 12:17, Robert Bradshaw wrote:
This is exactly what was proposed to start this thread (with minimal
collusion to avoid conflicts, specifically partitioning up a global ID
space).
Yes, but I think this part of the mechanism needs to be spell
On Thu, 17 May 2012 20:13:41 +0200, Dag Sverre Seljebotn
wrote:
> Every time Cython becomes able to do stuff more easily in this domain,
> people thank us that they didn't have to dig up Fortran but can stay
> closer to Python.
>
> Sorry for going off on a rant. I find that people will give we
On 05/17/2012 08:13 PM, Dag Sverre Seljebotn wrote:
Mark Shannon wrote:
Dag Sverre Seljebotn wrote:
from numpy import sin
# assume sin is a Python callable and that NumPy decides to support
# our spec to also support getting a "double (*sinfuncptr)(double)".
# Our mission: Avoid to have the u
Mark Shannon wrote:
Dag Sverre Seljebotn wrote:
from numpy import sin
# assume sin is a Python callable and that NumPy decides to support
# our spec to also support getting a "double (*sinfuncptr)(double)".
# Our mission: Avoid to have the user manually import "sin" from C,
# but allow just us
Mark Shannon, 17.05.2012 12:38:
> Dag Sverre Seljebotn wrote:
>> On 05/16/2012 10:24 PM, Robert Bradshaw wrote:
>>> On Wed, May 16, 2012 at 11:33 AM, "Martin v. Löwis"
>>> wrote:
> Does this use case make sense to everyone?
>
> The reason why we are discussing this on python-dev is tha
Dag Sverre Seljebotn wrote:
On 05/16/2012 10:24 PM, Robert Bradshaw wrote:
On Wed, May 16, 2012 at 11:33 AM, "Martin v.
Löwis" wrote:
Does this use case make sense to everyone?
The reason why we are discussing this on python-dev is that we are
looking
for a general way to expose these C lev
So maybe it's worth thinking about making a general mechanism
available for third parties to extend the type object without
them all needing to have their own tp_flags bits and without
needing to collude with each other to avoid conflicts.
That mechanism is already available. Subclass PyTypeType
On 17/05/12 12:17, Robert Bradshaw wrote:
This is exactly what was proposed to start this thread (with minimal
collusion to avoid conflicts, specifically partitioning up a global ID
space).
Yes, but I think this part of the mechanism needs to be spelled out in
more detail, perhaps in the form
On Wed, May 16, 2012 at 5:03 PM, Greg Ewing wrote:
> Dag wrote:
>
>> I'm not asking you to consider the details of all that. Just to allow some
>> kind of high-performance extensibility of PyTypeObject, so that we can
>> *stop* bothering python-dev with specific requirements from our parallel
>> u
Dag wrote:
I'm not asking you to consider the details of all that.
Just to allow some kind of high-performance extensibility of
PyTypeObject, so that we can *stop* bothering python-dev with
specific requirements from our parallel universe of
nearly-all-Cython-and-Fortran-and-C++ codebases :-)
On 05/16/2012 10:24 PM, Robert Bradshaw wrote:
On Wed, May 16, 2012 at 11:33 AM, "Martin v. Löwis" wrote:
Does this use case make sense to everyone?
The reason why we are discussing this on python-dev is that we are looking
for a general way to expose these C level signatures within the Python
On Wed, May 16, 2012 at 11:33 AM, "Martin v. Löwis" wrote:
>> Does this use case make sense to everyone?
>>
>> The reason why we are discussing this on python-dev is that we are looking
>> for a general way to expose these C level signatures within the Python
>> ecosystem. And Dag's idea was to ex
Does this use case make sense to everyone?
The reason why we are discussing this on python-dev is that we are looking
for a general way to expose these C level signatures within the Python
ecosystem. And Dag's idea was to expose them as part of the type object,
basically as an addition to the cur
In our specific case the value would be an offset added to the
PyObject*, and there we would find a pointer to a C function (together
with a 64-bit signature), and calling that C function (after checking
the 64 bit signature) is our final objective.
And what the C function does really is faster
Robert Bradshaw wrote:
On Wed, May 16, 2012 at 8:40 AM, Mark Shannon wrote:
Dag Sverre Seljebotn wrote:
On 05/16/2012 02:47 PM, Mark Shannon wrote:
Stefan Behnel wrote:
Dag Sverre Seljebotn, 16.05.2012 12:48:
On 05/16/2012 11:50 AM, "Martin v. Löwis" wrote:
Agreed in general, but in this c
On Wed, May 16, 2012 at 8:40 AM, Mark Shannon wrote:
> Dag Sverre Seljebotn wrote:
>>
>> On 05/16/2012 02:47 PM, Mark Shannon wrote:
>>>
>>> Stefan Behnel wrote:
Dag Sverre Seljebotn, 16.05.2012 12:48:
>
> On 05/16/2012 11:50 AM, "Martin v. Löwis" wrote:
>>>
>>> Agreed in
Dag Sverre Seljebotn wrote:
On 05/16/2012 02:47 PM, Mark Shannon wrote:
Stefan Behnel wrote:
Dag Sverre Seljebotn, 16.05.2012 12:48:
On 05/16/2012 11:50 AM, "Martin v. Löwis" wrote:
Agreed in general, but in this case, it's really not that easy. A C
function call involves a certain overhead a
On 05/16/2012 02:47 PM, Mark Shannon wrote:
Stefan Behnel wrote:
Dag Sverre Seljebotn, 16.05.2012 12:48:
On 05/16/2012 11:50 AM, "Martin v. Löwis" wrote:
Agreed in general, but in this case, it's really not that easy. A C
function call involves a certain overhead all by itself, so calling
into
On 05/16/2012 02:16 PM, Stefan Behnel wrote:
Stefan Behnel, 16.05.2012 13:13:
Dag Sverre Seljebotn, 16.05.2012 12:48:
On 05/16/2012 11:50 AM, "Martin v. Löwis" wrote:
Agreed in general, but in this case, it's really not that easy. A C
function call involves a certain overhead all by itself, so
Stefan Behnel wrote:
Dag Sverre Seljebotn, 16.05.2012 12:48:
On 05/16/2012 11:50 AM, "Martin v. Löwis" wrote:
Agreed in general, but in this case, it's really not that easy. A C
function call involves a certain overhead all by itself, so calling into
the C-API multiple times may be substantiall
Stefan Behnel, 16.05.2012 13:13:
> Dag Sverre Seljebotn, 16.05.2012 12:48:
>> On 05/16/2012 11:50 AM, "Martin v. Löwis" wrote:
Agreed in general, but in this case, it's really not that easy. A C
function call involves a certain overhead all by itself, so calling into
the C-API multip
Dag Sverre Seljebotn, 16.05.2012 12:48:
> On 05/16/2012 11:50 AM, "Martin v. Löwis" wrote:
>>> Agreed in general, but in this case, it's really not that easy. A C
>>> function call involves a certain overhead all by itself, so calling into
>>> the C-API multiple times may be substantially more cost
On 05/16/2012 11:50 AM, "Martin v. Löwis" wrote:
Agreed in general, but in this case, it's really not that easy. A C
function call involves a certain overhead all by itself, so calling into
the C-API multiple times may be substantially more costly than, say,
calling through a function pointer onc
Martin v. Löwis wrote:
> And, we want this to somehow work with existing Python; we still
> support users on Python 2.4.
This makes the question out-of-scope for python-dev - we only discuss
new versions of Python here. Old versions cannot be developed anymore
(as they are released already).
Agreed in general, but in this case, it's really not that easy. A C
function call involves a certain overhead all by itself, so calling into
the C-API multiple times may be substantially more costly than, say,
calling through a function pointer once and then running over a returned C
array compari
"Martin v. Löwis", 16.05.2012 10:36:
>> And, we want this to somehow work with existing Python; we still
>> support users on Python 2.4.
>
> This makes the question out-of-scope for python-dev - we only discuss
> new versions of Python here. Old versions cannot be developed anymore
> (as they are
On 05/16/2012 10:36 AM, "Martin v. Löwis" wrote:
> And, we want this to somehow work with existing Python; we still
> support users on Python 2.4.
This makes the question out-of-scope for python-dev - we only discuss
new versions of Python here. Old versions cannot be developed anymore
(as the
> And, we want this to somehow work with existing Python; we still
> support users on Python 2.4.
This makes the question out-of-scope for python-dev - we only discuss
new versions of Python here. Old versions cannot be developed anymore
(as they are released already).
typedef struct {
unsigned
On 05/16/2012 10:11 AM, Nick Coghlan wrote:
Use PyObject_HasAttr, just as people use hasattr() for ducktyping in Python.
In the Cython wrap-function-pointers case we really want performance
comparable to C, so we couldn't do the whole thing.
But I guess we could intern some char* (somehow),
Use PyObject_HasAttr, just as people use hasattr() for ducktyping in Python.
If you want something more structured, use Abstract Base Classes,
that's what they're for.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
Hi python-dev,
these ideas/questions comes out of the Cython and NumPy developer lists.
What we want is a way to communicate things on the C level about the
extension type instances we pass around. The solution today is often to
rely on PyObject_TypeCheck. For instance, hundreds of handcrafted
34 matches
Mail list logo
