access violation with C API
Hello all, The following triggers an "access violation" error, why? pPyType = (PyTypeObject*)malloc(sizeof(PyTypeObject)); memset(pPyType, 0, sizeof(PyTypeObject)); pPyType->ob_refcnt= 1; pPyType->tp_name = "noname"; pPyType->tp_basicsize = sizeof(MyObject); pPyType->tp_flags = Py_TPFLAGS_DEFAULT; pPyType->tp_doc = "nodoc"; PyType_Ready(pPyType); Thanks. -- http://mail.python.org/mailman/listinfo/python-list
Re: wxpython worked out but can't find api docs for download.
Go to: http://wxpython.org/download.php#binaries and in the documentation part, download both "wxPython-docs" and "wxPython-newdocs". Hope this helps. -- http://mail.python.org/mailman/listinfo/python-list
Re: wxpython worked out but can't find api docs for download.
Sorry, I think all you want is "wxPython-newdocs", which is the wxPython-specific documentation. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is there any way to catch expections when call python method in C++
One way is to create an intermediate python function, which returns a special value when an exception is caught. def ExceptionCatcher(FunctionToCall): def F(): try: FunctionToCall() except: return -1 return 0 return F Then instead of calling your function, you would call ExceptionCatcher(YourFunction). You can then check the return value in your C++ code. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python GUI + OpenGL
You don't necessarily need an OpenGL wrapper like PyOpenGL. If you
only use a handful of OpenGL functions, it would be relatively
straight-forward to make your own, using ctypes.
Here is what it would look like:
from ctypes import cdll, windll, c_double, c_float, c_int
GL_POINTS = 0x
GL_LINES = 0x0001
GL_LINE_LOOP = 0x0002
GL_LINE_STRIP = 0x0003
GL_TRIANGLES = 0x0004
GL_TRIANGLE_STRIP = 0x0005
GL_TRIANGLE_FAN = 0x0006
GL_QUADS = 0x0007
GL_QUAD_STRIP = 0x0008
GL_POLYGON= 0x0009
gl = windll.LoadLibrary("opengl32")
glEnd = gl.glEnd
glEnd.restype = None
glBegin = gl.glBegin
glBegin.argtypes = [c_int]
glBegin.restype = None
glVertex2f = gl.glVertex2d
glVertex2f.argtypes = [c_double, c_double]
glVertex2f.restype = None
glColor3f = gl.glColor3d
glColor3f.argtypes = [c_double, c_double, c_double]
glColor3f.restype = None
glClear = gl.glClear
glClear.argtypes = [c_int]
glClear.restype = None
glClearColor = gl.glClearColor
glClearColor.argtypes = [c_double, c_double, c_double, c_double]
glClearColor.restype = None
glViewport = gl.glViewport
glViewport.argtypes = [c_int, c_int, c_int, c_int]
glViewport.restype = None
[...etc]
Regards,
Laurent
On Mar 2, 4:17 pm, Achim Domma <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm developing a GUI app in Python/C++ to visualize numerical results.
> Currently I'm using Python 2.4 with wx and PyOpenGLContext, but there
> are no windows binaries for Python 2.5 for quite some time now.
>
> I need a OpenGL context without restrictions and some settings dialogs.
> Is wx + PyOpenGL the way to go? Or could somebody recommend a better set
> of tools/libs?
>
> regards,
> Achim
--
http://mail.python.org/mailman/listinfo/python-list
Re: C++ and Python
On Mar 9, 7:04 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > Hi Everyone, > > I'm considering about generating some Python Bindings for C++ > libraries. What are considered the best tools for doing something like > this? I know that there are SWIG, SIP, Boost.Python, and GCC_XML. > > Thanks! Declare the functions you want to use in Python with 'extern "C"', and make them available in a dynamic library. Then use ctypes to call them directly. Regards, Willard -- http://mail.python.org/mailman/listinfo/python-list
Re: list comprehension help
I wonder whether the following be more efficient if DB was a
dictionnary:
Splits = (line.split(' ') for line in open('file.text', 'r'))
DB = dict([(S[0], S[-1]) for S in Splits])
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python Class Best Practice
On Dec 5, 12:18 am, Rod Person <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I've been doing python programming for about 2 years as a hobby and now > I'm finally able to use it at work in an enterprise environment. Since > I will be creating the base classes and libraries I wondering which why > is consider best when creating python classes: > > 1: > class Foo(object): > member1='' > member2=0 > > def __init__(self,member1='',member2=0): > self.member1 = member1 > self.member2 = member2 > > 2: > class Foo(object): > def __init(self,member1='',member2=0): > self.member1 = member1 > self.member2 = member2 > The short answer : if 2 works, then stick with it. -- http://mail.python.org/mailman/listinfo/python-list
Is this a bug, or is it me?
Hello all,
For some reason, the following does not work :
class C:
TYPES = [None]
DICT = {}
for Type in TYPES:
DICT.update((E,Type) for E in [1])
>>> NameError: global name 'Type' is not defined
What do you think? Is this a bug?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is this a bug, or is it me?
> > You cannot access a class's class variables in it's class-statement > scope, since the name of the type is not bound until after the class > statement is completed. > Thanks for the answer, but then why is there no error with the variable 'TYPES'? This one is accessed first... -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this a bug, or is it me?
On Jan 17, 4:14 pm, [EMAIL PROTECTED] wrote: > > Do not use those names...really poor choice... This is not the way it looks it my code. I simplified it, with generic names, in order to point out something that does not work... The only question here is why? -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this a bug, or is it me?
I filed a bug report, and here is the short answer to my question:
genexps are code blocks, and code blocks cannot see variables in class
scopes. Congrats to Neil Cerutti who figured it out.
Now here is another one for your enjoyment:
class C:
@staticmethod
def f1(): pass
F = { '1' : f1 }
C().F['1']()
>>> TypeError: 'staticmethod' object is not callable
What do you think of this one?
--
http://mail.python.org/mailman/listinfo/python-list
end of print = lower productivity ?
I want my productivity back.
In Python 2.x, I could easily write things like -- print "f" / print
"add" / print "done" -- to a lot of different places in my code, which
allowed me to find bugs that I could not track otherwise. When I found
out that "f" was not at fault, I could write -- print "g" -- to some
other place... etc, so that a significant part of the time spent
debugging was actually used to write print statements.
Now the print statement disappeared, and I have to write print("f")
instead. These parentheses not only take time to write, they also make
me think twice about using print for debugging purposes. Pressing <
SHIFT > then < ( > then < " > makes the whole process quite a hassle.
I agree with most of the arguments that have been made against using
the print statement to build code, but I did care about the efficient
debugging tool it was.
--
http://mail.python.org/mailman/listinfo/python-list
Re: end of print = lower productivity ?
On Nov 25, 4:53 pm, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote: > I used to use print a lot. Once I found > > import pdb; pdb.set_trace() > > I massively lost interest in it. And gained *much* more debugging > power/productivity. In some cases, this is not discriminatory enough : there are simply too many function calls. -- http://mail.python.org/mailman/listinfo/python-list
Re: end of print = lower productivity ?
On Nov 25, 5:05 pm, peter <[EMAIL PROTECTED]> wrote:
> BUT you now can do
>
> >>> p = print
> >>> p("f")
>
> Voila, 4 keystrokes saved :-)
All right. Let's talk about that.
When I write "print", it is both effortless and instantaneous : my
hands do not move, a wave goes through my fingers, it all happens in a
tenth of a second.
Contrast this with what one has to go through to catch the SHIFT key,
and then the "(" : move the left hand, press SHIFT, move the right
hand, aim "(", press, miss, press again. Same thing at the end of the
function call.
I know it sounds ridiculous, but it does *impair* my debugging
productivity. Taylor would agree.
--
http://mail.python.org/mailman/listinfo/python-list
Re: SWIG vs. ctypes (Was: ANN: PyEnchant 1.5.0)
On Nov 25, 4:34 pm, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote: > > You can't use ctypes for C++, only for C-style APIs. > > Diez With some work, you can convert your C++ objects to PyObject* and then return the latter in a function with C bindings. -- http://mail.python.org/mailman/listinfo/python-list
Re: HELP!...Google SketchUp needs a Python API
Don't feed the troll. -- http://mail.python.org/mailman/listinfo/python-list
