Guenther Sohler writes:
Hi, Guenther!
> I have successfully used C-Python (3) in a software project in unix and its
> great stuff!
> The environment was cmake using g++ in Linux
Congratulations!
> Now when i want to get my project compiled in windows, whats the easiest
> development chain
Hi Group,
I have successfully used C-Python (3) in a software project in unix and its
great stuff!
The environment was cmake using g++ in Linux
Now when i want to get my project compiled in windows, whats the easiest
development chain ?
Is there something like a python.dll which i can link to my
Hi,
I proposed two PRs to move the private C API (Include/cpython/) of PEP
523 "Adding a frame evaluation API to CPython" to the internal C API
(Include/internals/):
* https://github.com/python/cpython/pull/32052
* https://github.com/python/cpython/pull/32054
API:
* _PyFrameEvalFunction type
*
Hello.
I need to start C trace the thread after to start, its to reduce of the time of
the process.
I had a lot performance changes sys.trace to C trace, but I need to reduce more
time.
Are there any soluction to set trace during thead runtime?
Att.
Leandro Müller
_
I just would want to say that I'm very happy to read the discussions
about the C API finally happening on python-dev :-) The discussion is
very interesting!
> C is really the lingua franca
Sorry, but why not writing the API directly in french?
Victor
_
On 30Nov2018 1133, Antoine Pitrou wrote:
On Fri, 30 Nov 2018 13:06:11 -0600
Neil Schemenauer wrote:
On 2018-11-29, Armin Rigo wrote:
...Also, although I'm discussing it here, I think the whole approach
would be better if done as a third-party extension for now, without
requiring changes to CPy
On Fri, 30 Nov 2018 13:06:11 -0600
Neil Schemenauer wrote:
> On 2018-11-29, Armin Rigo wrote:
> > ...Also, although I'm discussing it here, I think the whole approach
> > would be better if done as a third-party extension for now, without
> > requiring changes to CPython---just use the existing C
Hi Steve,
On 30/11/2018, Steve Dower wrote:
> On 29Nov2018 2206, Armin Rigo wrote:
>> On Thu, 29 Nov 2018 at 18:19, Steve Dower wrote:
>>> quo. We continue to not be able to change CPython internals at all,
>>> since that will break people using option B.
>>
>> No? That will only break users if
On 2018-11-29, Armin Rigo wrote:
> ...Also, although I'm discussing it here, I think the whole approach
> would be better if done as a third-party extension for now, without
> requiring changes to CPython---just use the existing C API to
> implement the CPython version.
Hello Armin,
Thank you for
Steve Dower wrote:
> My proposed marketing pitch is: "rewrite your existing code to be
> forward-compatible today and faster in the future without more work, or
> be prepared to rewrite/update your source code for each CPython release
> to remain compatible with the low level API". The promise
On Fri, 30 Nov 2018 09:22:30 -0800
Steve Dower wrote:
>
> My proposed marketing pitch is: "rewrite your existing code to be
> forward-compatible today and faster in the future without more work, or
> be prepared to rewrite/update your source code for each CPython release
> to remain compatible
On 29Nov2018 2206, Armin Rigo wrote:
On Thu, 29 Nov 2018 at 18:19, Steve Dower wrote:
quo. We continue to not be able to change CPython internals at all,
since that will break people using option B.
No? That will only break users if they only have an option-B
``foo.cpython-318m-x86_64-linux-
Hi,
On Thu, 29 Nov 2018 at 18:19, Steve Dower wrote:
> quo. We continue to not be able to change CPython internals at all,
> since that will break people using option B.
No? That will only break users if they only have an option-B
``foo.cpython-318m-x86_64-linux-gnu.so``, no option-A .so and no
On 28Nov2018 2208, Armin Rigo wrote:
Hi Steve,
On Tue, 27 Nov 2018 at 19:14, Steve Dower wrote:
On 27Nov2018 0609, Victor Stinner wrote:
Note: Again, in my plan, the new C API would be an opt-in API. The old
C API would remain unchanged and fully supported. So there is no
impact on performanc
On Thu, Nov 29, 2018 at 5:10 PM Armin Rigo wrote:
> PS: on CPython could use ``typedef struct { PyObject *_obj; }
> PyHandle;``. This works like a pointer, but you can't use ``==`` to
> compare them.
And then you could have a macro or inline function to compare them,
simply by looking at that pr
Hi Steve,
On Tue, 27 Nov 2018 at 19:14, Steve Dower wrote:
> On 27Nov2018 0609, Victor Stinner wrote:
> > Note: Again, in my plan, the new C API would be an opt-in API. The old
> > C API would remain unchanged and fully supported. So there is no
> > impact on performance if you consider to use th
On Mon, Nov 26, 2018 at 4:10 PM Larry Hastings wrote:
> On 11/23/18 5:15 AM, Armin Rigo wrote:
>
> Also FWIW, my own 2 cents on the topic of changing the C API: let's
> entirely drop ``PyObject *`` and instead use more opaque
> handles---like a ``PyHandle`` that is defined as a pointer-sized C
>
On 27Nov2018 0609, Victor Stinner wrote:
Note: Again, in my plan, the new C API would be an opt-in API. The old
C API would remain unchanged and fully supported. So there is no
impact on performance if you consider to use the old C API.
This is one of the things that makes me think your plan is
Le mar. 27 nov. 2018 à 01:13, Larry Hastings a écrit :
> (...) I'm not convinced the nice-to-have of "you can't dereference the
> pointer anymore" is worth this runtime overhead.
About the general idea of a new C API.
If you only look at CPython in release mode, there is no benefit. But
you sho
On Mon, Nov 26, 2018 at 6:12 PM Eric V. Smith wrote:
> I thought the important part of the proposal was to have multiple
> PyHandles that point to the same PyObject (you couldn't "directly
> compare handles with each other to learn about object identity"). But
> I'll admit I'm not sure why this wo
On 2018-11-27 00:08, Larry Hastings wrote:
On 11/23/18 5:15 AM, Armin Rigo wrote:
Also FWIW, my own 2 cents on the topic of changing the C API: let's
entirely drop ``PyObject *`` and instead use more opaque
handles---like a ``PyHandle`` that is defined as a pointer-sized C
type but is not actual
On 11/26/2018 7:08 PM, Larry Hastings wrote:
On 11/23/18 5:15 AM, Armin Rigo wrote:
Also FWIW, my own 2 cents on the topic of changing the C API: let's
entirely drop ``PyObject *`` and instead use more opaque
handles---like a ``PyHandle`` that is defined as a pointer-sized C
type but is not actu
On 11/23/18 5:15 AM, Armin Rigo wrote:
Also FWIW, my own 2 cents on the topic of changing the C API: let's
entirely drop ``PyObject *`` and instead use more opaque
handles---like a ``PyHandle`` that is defined as a pointer-sized C
type but is not actually directly a pointer. The main difference
Armin Rigo schrieb am 26.11.18 um 06:37:
> On Sun, 25 Nov 2018 at 10:15, Stefan Behnel wrote:
>> Overall, this seems like something that PyPy could try out as an
>> experiment, by just taking a simple extension module and replacing all
>> increfs with newref assignments. And obviously implementing
On Fri, Nov 23, 2018 at 2:22 PM Armin Rigo wrote:
>
> Hi Hugo, hi all,
>
> On Sun, 18 Nov 2018 at 22:53, Hugh Fisher wrote:
> > I suggest that for the language reference, use the license plate
> > or registration analogy to introduce "handle" and after that use
> > handle throughout. It's short,
Hi,
On Sun, 25 Nov 2018 at 10:15, Stefan Behnel wrote:
> Overall, this seems like something that PyPy could try out as an
> experiment, by just taking a simple extension module and replacing all
> increfs with newref assignments. And obviously implementing the whole thing
> for the C-API
Just to
Hi Armin,
Armin Rigo schrieb am 25.11.18 um 06:15:
> On Sat, 24 Nov 2018 at 22:17, Stefan Behnel wrote:
>> Couldn't this also be achieved via reference counting? Count only in C
>> space, and delete the "open object" when the refcount goes to 0?
>
> The point is to remove the need to return the s
Hi Stefan,
On Sat, 24 Nov 2018 at 22:17, Stefan Behnel wrote:
> Couldn't this also be achieved via reference counting? Count only in C
> space, and delete the "open object" when the refcount goes to 0?
The point is to remove the need to return the same handle to C code if
the object is the same
Armin Rigo schrieb am 23.11.18 um 14:15:
> In PyPy we'd have a global table of
> "open objects", and a handle would be an index in that table; closing
> a handle means writing NULL into that table entry. No emulated
> reference counting needed: we simply use the existing GC to keep alive
> objects
On Fri, 23 Nov 2018 at 23:24, Armin Rigo wrote
(regarding opaque "handles" in the C API):
> The C API would change a lot, so it's not reasonable to do that in the
> CPython repo. But it could be a third-party project, attempting to
> define an API like this and implement it well on top of both CP
Armin Rigo wrote:
> The C API would change a lot, so it's not reasonable to do that in the
> CPython repo. But it could be a third-party project, attempting to
> define an API like this and implement it well on top of both CPython
> and PyPy. IMHO this might be a better idea than just changing
Hi Hugo, hi all,
On Sun, 18 Nov 2018 at 22:53, Hugh Fisher wrote:
> I suggest that for the language reference, use the license plate
> or registration analogy to introduce "handle" and after that use
> handle throughout. It's short, distinctive, and either will match
> up with what the programmer
On 2018-06-20 08:00, Stefan Behnel wrote:
Just to add another bit of background on top of the current discussion,
there is an idea around, especially in the scipy/big-data community, (and
I'm not giving any guarantees here that it will lead to a PEP +
implementation, as it depends on people's wor
Victor Stinner schrieb am 19.06.2018 um 16:59:
> 2018-06-19 13:58 GMT+02:00 Jeroen Demeyer :
>> Personally, I think that you are exaggerating these issues.
>
> I'm not trying to convince you to abandon the idea. I would be happy
> to be able to use FASTCALL in more cases! I just tried to explain w
annon [mailto:br...@python.org]
> *Sent:* Friday, January 15, 2016 6:58 PM
> *To:* Eddy Quicksall; python-dev@python.org
> *Subject:* Re: [Python-Dev] C struct for Str( )
>
>
>
> I don't quite see what this has to do with has to do with the development
> of Python, Eddy. You ca
Sorry, I must be on the wrong list. Can you please give me the correct list?
Eddy
From: Brett Cannon [mailto:br...@python.org]
Sent: Friday, January 15, 2016 6:58 PM
To: Eddy Quicksall; python-dev@python.org
Subject: Re: [Python-Dev] C struct for Str( )
I don't quite see what this h
I don't quite see what this has to do with has to do with the development
of Python, Eddy. You can always reference the C API at
https://docs.python.org/3/c-api/index.html . And `PyBytesObject` is an
instance of `bytes` in Python.
On Fri, 15 Jan 2016 at 15:33 Eddy Quicksall wrote:
> I want to fi
I want to fill an Str() string from a C function. But I think I am using the
wrong structure (PyBytesObject). I have written a C function to dump the
Python class but as you can see the structure I'm using does not match the
data in the class.
Can someone please tell me the correct structure:
--
On 15 January 2015 at 02:24, Ethan Furman wrote:
> On 01/14/2015 12:13 AM, Georg Brandl wrote:
>> On 01/14/2015 08:32 AM, Ethan Furman wrote:
>>>
>>> In the CPython source code I see
>>>
>>> #ifndef Py_LIMITED_API
>>>
>>> Is there a section in the docs that explains the purpose? If not, can
>>> s
On 01/14/2015 12:13 AM, Georg Brandl wrote:
> On 01/14/2015 08:32 AM, Ethan Furman wrote:
>>
>> In the CPython source code I see
>>
>> #ifndef Py_LIMITED_API
>>
>> Is there a section in the docs that explains the purpose? If not, can
>> someone give me the cliff notes version?
>
> PEP 384, and in
On 01/14/2015 08:32 AM, Ethan Furman wrote:
> In the CPython source code I see
>
> #ifndef Py_LIMITED_API
>
> Is there a section in the docs that explains the purpose? If not, can
> someone give me the cliff notes version?
PEP 384, and in particular [1] should get you started.
cheers,
Georg
[
In the CPython source code I see
#ifndef Py_LIMITED_API
Is there a section in the docs that explains the purpose? If not, can someone
give me the cliff notes version?
Many thanks.
--
~Ethan~
signature.asc
Description: OpenPGP digital signature
__
Looks like it's already in the works! Nevermind
On Thu, Jun 26, 2014 at 10:33 AM, Benjamin Peterson
wrote:
> You might look at https://bugs.python.org/issue14373
>
> On Thu, Jun 26, 2014, at 08:38, Peter Brady wrote:
> > Hello python devs,
> >
> > I was recently in need of some faster caching
You might look at https://bugs.python.org/issue14373
On Thu, Jun 26, 2014, at 08:38, Peter Brady wrote:
> Hello python devs,
>
> I was recently in need of some faster caching and thought this would be a
> good opportunity to familiarize myself with the Python/C api so I wrote a
> C
> extension fo
Hello python devs,
I was recently in need of some faster caching and thought this would be a
good opportunity to familiarize myself with the Python/C api so I wrote a C
extension for the lru_cache in functools. The source is at
https://github.com/pbrady/fastcache.git and I've posted it as a packa
On 03/26/2014 06:22 AM, � wrote:
[Assuming you are talking about PyUnicode_FromFormatV]
%s is a string.
No. %s is a char*; C does not have a "string" type.
The string behind the pointer should be UTF-8 encoded;
other encodings are tolerated through the "replace" error
handler.
%U is unicode?
On 03/26/2014 03:48 AM, Antoine Pitrou wrote:
On Tue, 25 Mar 2014 18:43:30 -0700
Ethan Furman wrote:
%s is a string.
%U is unicode?
What is the context?
A patch I'm adapting has these lines:
static PyObject*
module_getattr(PyObject *m, PyObject *name)
{
char *mod_name_str;
[Assuming you are talking about PyUnicode_FromFormatV]
> %s is a string.
No. %s is a char*; C does not have a "string" type.
The string behind the pointer should be UTF-8 encoded;
other encodings are tolerated through the "replace" error
handler.
> %U is unicode?
No. This is a PyObject* whose Py
2014-03-26 12:02 GMT+01:00 Antoine Pitrou :
> Ok, I suppose it's PyUnicode_Format? :-)
I don't think that PyUnicode_Format supports %U.
For PyUnicode_FromFormatV(), %U expects a Python Unicode object,
whereas "%s" expects a ASCII (or latin1?) encoded byte string "const
char*".
For PyArg_ParseTup
On Wed, 26 Mar 2014 11:48:44 +0100
Antoine Pitrou wrote:
> On Tue, 25 Mar 2014 18:43:30 -0700
> Ethan Furman wrote:
> > %s is a string.
> >
> > %U is unicode?
>
> What is the context?
Ok, I suppose it's PyUnicode_Format? :-)
(I was initially thinking PyArg_ParseTuple, but it doesn't use "%")
On Tue, 25 Mar 2014 18:43:30 -0700
Ethan Furman wrote:
> %s is a string.
>
> %U is unicode?
What is the context?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.
26.03.14 03:43, Ethan Furman написав(ла):
%s is a string.
%U is unicode?
If so, then %s should only be used when it is certain the string in
question has no unicode in it?
%s is UTF-8 encoded string.
___
Python-Dev mailing list
Python-Dev@python.o
%s is a string.
%U is unicode?
If so, then %s should only be used when it is certain the string in question
has no unicode in it?
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubsc
On 12 Oct 2013 05:49, "Eric Snow" wrote:
>
> On Fri, Oct 11, 2013 at 1:41 PM, Stefan Krah wrote:
> > Antoine Pitrou wrote:
> >> Just create a _pydecimal module (like _pyio).
> >
> > That's very fast indeed. There's one minor problem: For backwards
compatibility
> > and pickling [1] I'd need to a
2013/10/11 Antoine Pitrou :
>> So the first step I tried is something horrible (typing from memory):
>>
>> try:
>> import _decimal
>> except ImportError:
>>
>> else:
>> from _decimal import *
>>
>> That way the 2.21 msec are reduced to 912 usec, but the indentation is
>> an abomination
On Fri, Oct 11, 2013 at 1:41 PM, Stefan Krah wrote:
> Antoine Pitrou wrote:
>> Just create a _pydecimal module (like _pyio).
>
> That's very fast indeed. There's one minor problem: For backwards
> compatibility
> and pickling [1] I'd need to add
>
> __module__ = 'decimal'
>
> to every class
Antoine Pitrou wrote:
> Just create a _pydecimal module (like _pyio).
That's very fast indeed. There's one minor problem: For backwards compatibility
and pickling [1] I'd need to add
__module__ = 'decimal'
to every class of the Python version. Are there any reasons not to do that?
Stefan
Antoine Pitrou wrote:
> >
> > I'm getting about the same values as above. I may be misunderstanding
> > something, but I wanted to reduce the difference between the 2.21 msec
> > and the 112 usec.
>
> So you aren't complaining about C extension import time, but Python
> code import time, right?
Le Fri, 11 Oct 2013 17:01:35 +0200,
Stefan Krah a écrit :
>
> I'm getting about the same values as above. I may be misunderstanding
> something, but I wanted to reduce the difference between the 2.21 msec
> and the 112 usec.
So you aren't complaining about C extension import time, but Python
cod
Antoine Pitrou wrote:
> Try the following:
>
> $ ./python -m timeit -s "modname='decimal'; import sys" \
> "__import__(modname); del sys.modules[modname]"
> 1000 loops, best of 3: 2.21 msec per loop
>
> $ ./python -m timeit -s "modname='_decimal'; import sys" \
> "__import__(modname); del sy
Le Fri, 11 Oct 2013 14:24:29 +0200,
Stefan Krah a écrit :
> Hi,
>
> recently there has been some talk about reducing import times. It
> seems that the current import strategy for C extensions (i.e.
> importing the extension at the bottom of the .py file) is quite slow:
>
>
> ===
Stefan Krah wrote:
> import sys
>
> for i in range(1):
> import decimal
> del sys.modules('decimal')
> del sys.modules('_decimal')
^^^
This happens when a Linux user is forced to use Putty :(
___
Python-Dev mailing
Hi,
recently there has been some talk about reducing import times. It seems
that the current import strategy for C extensions (i.e. importing the
extension at the bottom of the .py file) is quite slow:
import sys
for i in range(1):
import decimal
del sys.module
On Tue, Jul 30, 2013 at 8:28 PM, Christian Heimes wrote:
> Am 29.07.2013 21:48, schrieb Antoine Pitrou:
> > Ideally, we should run coverage runs on different systems (Unices,
> > Windows...) and merge the results together, so that we know which paths
> > are really uncovered.
>
> I don't that is e
Am 29.07.2013 21:48, schrieb Antoine Pitrou:
> Ideally, we should run coverage runs on different systems (Unices,
> Windows...) and merge the results together, so that we know which paths
> are really uncovered.
I don't that is easily possible. The coverage report depends on GCC and
its gcov exten
Am 29.07.2013 19:15, schrieb Christian Heimes:
> Hi,
>
> I have done some experiments with GCC's gcov and lcov to get the C code
> coverage of our unit test suite. You may find today's report at
>
> http://tiran.bitbucket.org/python-lcov/
>
> I'm working on a patch for our Makefile to include
Am 29.07.2013 21:38, schrieb Brett Cannon:
> If there's a way to report just function coverage then I think
> that's a great place to start.
lcov's genhtml command doesn't support just function coverage. But I
have removed branch coverage. It makes the report a little bit more
readable.
Christian
On Mon, 29 Jul 2013 21:31:02 +0200
Christian Heimes wrote:
> Am 29.07.2013 19:58, schrieb Brett Cannon:
> > I took a quick poke around and it seems some things are legitimately not
> > being executed, while others are error conditions that we wouldn't
> > expect to occur (e.g. memory exhaustion).
On Mon, Jul 29, 2013 at 3:31 PM, Christian Heimes wrote:
> Am 29.07.2013 19:58, schrieb Brett Cannon:
> > I took a quick poke around and it seems some things are legitimately not
> > being executed, while others are error conditions that we wouldn't
> > expect to occur (e.g. memory exhaustion). If
Am 29.07.2013 19:58, schrieb Brett Cannon:
> I took a quick poke around and it seems some things are legitimately not
> being executed, while others are error conditions that we wouldn't
> expect to occur (e.g. memory exhaustion). If we ever decide to get
> serious about code coverage (both C and P
On Mon, 29 Jul 2013 13:58:55 -0400, Brett Cannon wrote:
> On Mon, Jul 29, 2013 at 1:15 PM, Christian Heimes wrote:
>
> > Hi,
> >
> > I have done some experiments with GCC's gcov and lcov to get the C code
> > coverage of our unit test suite. You may find today's report at
> >
> > http://tiran.b
On Mon, Jul 29, 2013 at 1:15 PM, Christian Heimes wrote:
> Hi,
>
> I have done some experiments with GCC's gcov and lcov to get the C code
> coverage of our unit test suite. You may find today's report at
>
> http://tiran.bitbucket.org/python-lcov/
Thanks!
I took a quick poke around and it se
Hi,
I have done some experiments with GCC's gcov and lcov to get the C code
coverage of our unit test suite. You may find today's report at
http://tiran.bitbucket.org/python-lcov/
I'm working on a patch for our Makefile to include all steps in one
simple make tag. http://bugs.python.org/issue1
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).
1 - 100 of 310 matches
Mail list logo
