Recently I wanted to deprecate some functions in our the C api, and
found that warnings give weired output when running through through
our C api.
A simple test is to do this...
print range(1.5)
When I run this from python I get good output..
test.py:1: DeprecationWarning: integer argument expected, got float
print range(1.5)
But when running from our C api I get
/home/ideasman42/blender-svn/blender/blender.bin:1:
DeprecationWarning: integer argument expected, got float
ELF�p40�"4()&44�4�44�4�����F��F��F�K �K ğ<@G�K �K xxHH�H�
P�td�2?��C ��C L,L,Q�td/lib/ld-linux.so.2GNU����8�1LQ
�U�N�.yH {��d
I thought this was todo with running a compiled string so I tried
PyRun_String() on the text buffer instead of PyEval_EvalCode() but the
same problem.
Id be interested to know if anyones embedded python gives proper warnings.
On Linux testing with python 2.6 here.
--
- Campbell
Hello Everybody,
I would like to use a C++ gui library with the following (simplified) interface
in Python.
#include <stdio.h>
class Gui;
class GuiObject {
public:
GuiObject(Gui *Gui) {printf("creating GuiObject(gui: %X)\n", Gui);}
~GuiObject() {printf("deleting GuiObject\n");}
void Move(int x, int y) {printf("GuiObject move(%d, %d)\n", x, y);};
};
class Gui {
public:
Gui() {printf("creating Gui\n");}
~Gui() {printf("deleting Gui\n");}
GuiObject* AddImage() {
GuiObject* ob = new GuiObject(this);
return ob;
}
void Print() {printf("Gui: %X\n", this);}
};
int main() {
Gui *gui = new Gui();
gui->Print();
GuiObject *obj = gui->AddImage();
obj->Move(50, 50);
/*GuiObject *obj2 = new GuiObject(gui); // not allowed
delete obj2;*/
delete obj;
delete gui;
return 0;
}
I created the Python Gui and GuiObject classes (PyTypeObject), and added it to
main module (PyModule_AddObject).
It works, but there is a problem at the Gui::AddImage(), with constructs a new
GuiObject, which is available in Python layer but finally it is not collected
and freed by GC:
...
obj = _PyObject_New(&GuiObjectType);
PyObject_Init(obj, &GuiObjectType);
...
I cannot invoke the GuiObject object constructor directly from Python, because
of the implementation of the C++ gui library (in this case it would be
collected).
I use the embedded CPython as an interpreter, so I cannot add additional
external .py file for it.
So the following Python code would be the target:
gui = GUI();
background = gui.AddImage();
#background = GuiObject(gui); <-- Collected but not allowed
background.ImageFile("bg.jpg");
background.Move(0, 0);
...
How could I implement the AddImage function in order to be freed the constructed
object at the end?
Thanks in advance!
All-the-best,
Csaba
After the initial controversy regarding Python's super(), I feel that
it's now fairly well-understood when it should be used and what
problems it solves. (Even if not, this list is probably not the right
medium for objections to super.) The one question I haven't seen
covered is whether and how to use it from C.
All of the Python/C code I've seen calls its base class(es) directly,
typically by only invoking the method of their superclass in the C
layout sense. This means that such code will call into the superclass
twice in a diamond inheritance scenario. For low-level classes that
are not expected to be multiply inherited this is not a problem. But
in some cases we need to convert higher-level classes from Python to C
for efficiency, either using Python/C, or a higher-level C++ wrapping.
The classes use super() with good reason, and I'd like to avoid
breaking them during conversion to C.
Is there a documented way to use super() from C, other than
instantiating PySuper_Type? Has anyone tried to do that?
2009-03-03 23:43:35，"Stefan Behnel" <python_capi(a)behnel.de> wrote：
>Ken Hughes wrote:
>> 1) Did anyone answer the original poster's question?
>
>Yes, two people (and one right in the first post, actually).
>
>
>> 2) If this is going to persist as an OT thread, change the subject line?
>
>I think "problem with reference" isn't that far from a good subject. ;-)
>
>Stefan
>
>_______________________________________________
>capi-sig mailing list
>capi-sig(a)python.org
>http://mail.python.org/mailman/listinfo/capi-sig
Thanks for everybody's answer.
Cython is a good assistant for writing c/c++ extension, but I it is indispensable to master Python/C API also. :)
1) Did anyone answer the original poster's question?
2) If this is going to persist as an OT thread, change the subject line?
Ken
Stefan Behnel wrote:
> Gustavo Carneiro wrote:
>
>> 2009/3/3 Stefan Behnel wrote:
>>
>>> Cython is (literally) not a wrapper generator as it will not generate a
>>> wrapper for you. You have to write it yourself. Cython is a programming
>>> language to write extension modules for CPython, as generic as that.
>>>
>> OK, but surely we can say that Cython is a code generator, or compiler.
>> [...]
>> It is more or less at the same level as Boost.Python.
>> You also have to write the wrapper code using Boost.Python yourself...
>>
>
> Except that Boost.Python does not optimise the code for you, simply
> because it is a library, not a compiler. It doesn't know what called it
> with what intention. The Cython compiler can extract a lot of information
> from your code and it *will* use it to make your code run fast. For
> example, calling a Cython implemented function is very fast compared to
> normal Python, simply because we can adapt the generated code to the
> specific signature of a function, instead of relying on generic argument
> unpacking code.
>
> Stefan
>
> _______________________________________________
> capi-sig mailing list
> capi-sig(a)python.org
> http://mail.python.org/mailman/listinfo/capi-sig
>
>
2009/3/3 Stefan Behnel <python_capi(a)behnel.de>
> Gustavo Carneiro wrote:
> > And Cython *is* a wrapper generator.
>
> Well, no, but PyBindGen is, now that you mention it. It looks a bit like a
> FFI (like ctypes), but it generates the corresponding wrapper code, if I'm
> not mistaken. Using it for anything but wrapping C/C++ code to make it
> callable in Python would be futile.
>
> Cython is (literally) not a wrapper generator as it will not generate a
> wrapper for you. You have to write it yourself. Cython is a programming
> language to write extension modules for CPython, as generic as that. It
> focuses on Python-like simplicity, C-like speed and easy interfacing with
> both CPython and C (while better C++ and Fortran support is still being
> fledged out). It is being used to write wrappers, but it is also being
> used to write high-performance computational code, with or without
> interfacing to external C libraries. In the second line, it's also heading
> to become a fully-compliant Python compiler (a 1.0 goal), but that doesn't
> belong here (just like the automatic-compile-on-import support for Python
> files *wink*).
OK, but surely we can say that Cython is a code generator, or compiler. So
it's more generic than a wrapper generator. But it can fulfill the role of
wrapper generator, even if it means writing more code than other tools for
describing the same API. For me, wrapper is any C/C++ code that bindings
Python to a C/C++ library. If Cython can generate that code, then Cython
can also be considered a wrapper generator, or at least the engine for a
wrapper generator. It is more or less at the same level as Boost.Python.
You also have to write the wrapper code using Boost.Python yourself...
>
>
>
> > I clearly remember seeing (ugly) C
> > code generated by Cython, before I decided to write PyBindGen.
>
> Let's not start a discussion about taste here. Readable, commented, easy
> to debug C code is an obvious goal of the Cython project, simply because
> its developers are those who debug it most of the time. That said, we
> generally tell our users to look at the highlighted HTML page that Cython
> generates of their source code, so that they can focus more easily on
> those parts of the generated C code that are worth optimising. Having to
> read the entire C code file just to see where things go wrong is not a
> good idea.
OK. I won't comment except to mention that I am glad the Cython project
wants to generate readable code.
Regards,
--
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert
On 2009-03-03 12:14, Stefan Behnel wrote:
> Cython is not a wrapper generator. It's a programming language that sits right
> between Python and C and generates code for the C-API of Python.
I think that's where the misunderstanding lies: This list is about the
Python C-API and not about generators or other helpers that provide
ways of avoiding it :-)
http://www.python.org/community/sigs/current/capi-sig/
IMHO, the list is about:
* discussing ways of improving the Python C API
* helping developers that have questions about the Python C API
Suggesting to use Cython or any of the other available tools feels
a bit like saying "avoid the Python C API wherever you can", which
doesn't give the right impression to developers seeking help from
this forum.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Mar 03 2009)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
On 2009-03-03 10:38, Stefan Behnel wrote:
> Hrvoje Niksic wrote:
>> Stefan Behnel writes:
>>> pycnweb wrote:
>>>> I am now writing a python extension, but I confuse with the reference.
>>> If you care more about working code than fighting confusion, Cython
>>> might be worth a look.
>> Stefan, please stop doing this. This list is about helping people
>> using Python/C, not Cython advocacy.
>
> Where is the difference?
The list would be called cython-sig otherwise :-)
There are many other alternatives to approaching Python extension writing
in C/C++:
* use ctypes
* use Boost.Python
* use SWIG
* use sip
* use PyCXX
* use PyRex/Cython
* use Robin
* ...
(there are lots more)
However, this list is about the layer underneath all of those.
It's about the Python C API and there are many good reasons
to use it directly rather than using one of the above wrappers
or wrapper generators.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Mar 03 2009)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
"Stefan Behnel" <python_capi(a)behnel.de> writes:
> I take your point. Especially to a someone who has just started to
> learn the C-API, my above statement might sound misleading.
Thank you. Other than the advocacy thing :-), I very much appreciate
your contributions to the list.
"Stefan Behnel" <python_capi(a)behnel.de> writes:
> Hrvoje Niksic wrote:
>> Stefan Behnel writes:
>>> pycnweb wrote:
>>>> I am now writing a python extension, but I confuse with the reference.
>>>
>>> If you care more about working code than fighting confusion, Cython
>>> might be worth a look.
>>
>> Stefan, please stop doing this. This list is about helping people
>> using Python/C, not Cython advocacy.
>
> Where is the difference?
The point is that statements like the above don't help someone who
*wants* (for whatever reason) to learn Python/C. It's perfectly fine
to mention Cython as a viable alternative, but not to imply that
Python/C is somehow non-functional or that it doesn't result in
working code. It's like posting to a C newsgroup telling everyone to
use C++ because it's so much better. It may well be better, but there
are good reasons why there are separate C and C++ forums.
comp.lang.python is a much more appropriate venue for Cython (or
boost.python, or PyCXX) advocacy.
