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 7:44 AM, Antoine Pitrou wrote:
>
> Hello all,
>
> We still need 64-bit Windows buildbots to test for regressions.
> Otherwise we might let regressions slip through, since few people seem
> to run the test suite under Windows at home.
The machine that I used to run a Server
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
On Wed, May 16, 2012 at 2:52 AM, "Martin v. Löwis" wrote:
>> +All versions previous to 3.3 use Microsoft Visual Studio 2008, available
>> at
>>
>> +https://www.microsoft.com/visualstudio/en-us/products/2008-editions/express.
>
>
> This isn't actually the case. 2.4 and 2.5 used Visual Studio 2003,
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
Hello all,
We still need 64-bit Windows buildbots to test for regressions.
Otherwise we might let regressions slip through, since few people seem
to run the test suite under Windows at home.
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@p
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
__
+All versions previous to 3.3 use Microsoft Visual Studio 2008, available at
+https://www.microsoft.com/visualstudio/en-us/products/2008-editions/express.
This isn't actually the case. 2.4 and 2.5 used Visual Studio 2003, 2.0
to 2.3 used VC6, 1.4 and 1.5 used Visual C++ 1.5; versions before tha
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
28 matches
Mail list logo
