🌐 Mailman 3 July 2010 - Python-list - python.org

Call CFUNCTYPE, class Structure, ctype, dll and Callback function problem
by legard_new July 31, 2010

July 31, 2010

Hello, I have a problem with calling Callback function with Python. I have a DLL file. Below is a description in documentation. FUNCTION Callback Arguments: Callback ID integer read-only, immediate value CBackProc address read-only, immediate value Returns: status The Callback routine registers the callback routine for notification of a link state change. The callback procedure provided by the application must accept one parameter: the address of the structure containing the data. CallbackID An integer identifying the callback routine being provided to the API. Can be one of 1 or 2. CBackProc The address of the callback procedure that the API will execute. This procedure must accept one parameter, of type LinkStateStruct, passed by reference. LinkStateStruct read-only, by reference OldState: byte NewState byte The routine will return one of the following error codes: 1 - The callback address was successfully registered by the API. 2 - The API has not been initialised. 3 - The CallbackID value was not recognised as a valid link state callback. Here is my little code in Python: from ctypes import * class LinkStateStruct(Structure): _fields_ = [("OldState", c_byte), ("NewState", c_byte)] demoapi=windll.LoadLibrary("D:\\DEMO.dll") #DECLARE CALLBACK FUNCTION g_HLSC = CFUNCTYPE(c_int, POINTER(LinkStateStruct)) def py_g_HLSC(x): print "CALLBACK__py_g_HLSC_FIRED->", x return 0 g__HLSC = g_HLSC(py_g_HLSC) status=demoapi.Callback(1,g__HLSC) print "Status=",status My result is: Status= 1 But Callback function is not executed. If think that i call g__HLSC witohout paramter that in document "The callback procedure provided by the application must accept one parameter: the address of the structure containing the data.". I don't now how to do. Please help. Best regards, Gregory

2 1

Tkinter Label alignment problem using OS 10.6
by AJ July 31, 2010

July 31, 2010

Dear users, I have written a sample program that ran correctly with earlier than Mac OS 10.6. The answer field Label does not align correctly. I downloaded the latest Python 2.7 release but still did not solve the problem. Look for line "L4.place(relx=0.32,rely=0.56, anchor=W)" #!/usr/bin/env python from Tkinter import * from tkMessageBox import * import sys win = Tk() #win.tk.call('console', 'hide') try: win.tk.call('after','idle','console','hide') except TclError: pass ScreenX = win.winfo_screenwidth() ScreenY = win.winfo_screenheight() ScreenX = (ScreenX/2) - 250 ScreenY = (ScreenY/2) - 200 win.geometry('500x300%+d%+d' %(ScreenX, ScreenY)) win.title("'Place' Geometry Test") win.resizable(width=False, height=False) FirstN = StringVar() SecondN = StringVar() Answer = StringVar() Verd12 = ("Verdana","11") Verd16 = ("Verdana","16") Verd25 = ("Verdana","25") Sys16 = ("System" ,"16") #----------------- AboutDialog ---------------------------- class AboutDialog(Toplevel): def __init__(self, parent): Toplevel.__init__(self, parent) self.configure(bg = 'white', borderwidth=3) self.geometry('200x300%+d%+d' %(ScreenX, ScreenY)) self.title('About...') self.resizable(height=FALSE, width=FALSE) self.transient(parent) self.grab_set() self.protocol("WM_DELETE_WINDOW", self.OkToExit) self.parent = parent self.FillDialog() self.Btn.focus_set() self.bind('<Return>',self.OkToExit) self.bind('<Escape>',self.OkToExit) self.bind('<Command-KeyPress-Q>', Done) self.bind('<Command-KeyPress-q>', Done) self.wait_window() def FillDialog(self): self.AboutText = "\n\n\nPlace Geometry Test\n\nBy\n\nAmin Aljuffali" self.Lbl = Label(self, text=self.AboutText, font=Verd16, bg = 'white') self.Lbl.pack(side=TOP) self.Lb2 = Label(self, text="April 1, 2007", height = 1, font=Verd12, bg = 'white') self.Lb2.pack(side=TOP) self.Lb3 = Label(self, text=" ", height = 3, font=Verd12, bg = 'white') self.Lb3.pack(side=TOP) self.Btn = Button(self, text='Done', font=Sys16, width=8, height=1, command=self.OkToExit) self.Btn.pack(side=TOP) self.Lb4 = Label(self, text=" ", height = 3, font=Verd12, bg = 'white') self.Lb4.pack(side=BOTTOM) self.update() def OkToExit(self, event=None): self.destroy() #---------------------------------------------------------- def ShowDialog(): AboutDialog(win) def done(): win.destroy() win.quit def Done(e): win.destroy() win.quit def CheckAlfanumeric(x): if x == '': return False for ch in x: if ch not in['.','-','+','0','1','2','3','4','5','6','7','8','9','e','E']: return False return True def Multiply(): #global FirstN, SecondN, Answer try: a = FirstN.get().strip() if not CheckAlfanumeric(a): raise ValueError b = SecondN.get().strip() if not CheckAlfanumeric(b): raise ValueError FirstN.set(a) SecondN.set(b) Answer.set(str(float(a) * float(b))) except ValueError: showwarning("Warning...","Input Error!") return def MakeToplevelMenu(topwin): top = Menu(topwin) topwin.config(menu=top) if sys.platform == 'darwin' and '.app' in sys.executable: application = Menu(top, name='apple') application.add_command(label='About...', command=ShowDialog, underline=0) top.add_cascade(label='PlaceTest', menu=application, underline=0) fileMenu = Menu(top, tearoff=0) fileMenu.add_command(label='Exit', command=done, underline=0) top.add_cascade(label='File', menu=fileMenu, underline=0) helpMenu = Menu(top, tearoff=0) helpMenu.add_command(label='About...', command=ShowDialog, underline=0) top.add_cascade(label='Help', menu=helpMenu, underline=0) return MakeToplevelMenu(win) L1 = Label(win, text='Multiply Two Numbers', font=Verd25, bg = 'white') L2 = Label(win, text='First Number:', font=Verd16, bg = 'white') L3 = Label(win, text='Second Number:', font=Verd16, bg = 'white') L4 = Label(win, text='', textvariable=Answer, font=Sys16, bg = 'white', bd=1, width=20, height=1, anchor=W, relief=SOLID) L5 = Label(win, text='Written by Amin Aljuffali', font=Verd12,padx=2, bg = 'white', anchor=W, relief=FLAT) B1 = Button(win, text='Multiply', font=Sys16, width=19, height=1, command=Multiply) B2 = Button(win, text='Quit', font=Sys16, width=19, height=1, command=done) F1 = Frame(win, relief=FLAT, bd=0, bg='#336699') F2 = Frame(win, relief=FLAT, bd=0, bg='#336699') F3 = Frame(win, relief=FLAT, bd=0, bg='#336699') E1 = Entry(win, textvariable=FirstN, relief=SOLID, font=Sys16, bg = 'white',bd=1) E2 = Entry(win, textvariable=SecondN, relief=SOLID, font=Sys16, bg = 'white', bd=1) win.bind('<Command-KeyPress-q>', Done) win.bind('<Command-KeyPress-Q>', Done) F1.place(relx=0.0,rely=0.01, anchor=NW, width=600, height=5) L1.place(relx=0.5,rely=0.09, anchor=CENTER) F2.place(relx=0.0,rely=0.16, anchor=NW, width=600, height=5) E1.place(relx=0.32,rely=0.32, anchor=W) E2.place(relx=0.32,rely=0.44, anchor=W) L2.place(relx=0.3,rely=0.32, anchor=E) L3.place(relx=0.3,rely=0.44, anchor=E) L4.place(relx=0.32,rely=0.56, anchor=W) B1.place(relx=0.525,rely=0.69, anchor=CENTER) B2.place(relx=0.525,rely=0.81, anchor=CENTER) F3.place(relx=0.0,rely=0.9, anchor=W, width=600, height=5) L5.place(relx=0.01,rely=0.95, anchor=W) E1.focus_set() win.update() win.mainloop() sys.exit(0)

5 7

Re: Newbie question regarding SSL and certificate verification
by Heikki Toivonen July 31, 2010

July 31, 2010

Jeffrey Gaynor wrote: > A final question -- how widely is M2Crypto used? Since I will have to now pitch >to our group that this is preferable the first questions they will ask are about >stability, who is using it and how secure is it really, especially since it is >at version 0.20.2 (i.e. no major release yet). The M2Crypto homepage lists dozens of applications and libraries that use M2Crypto. Additionally I believe certain Linux distros use it as more or less required piece. I know it has been used at some of the world's most largest companies. As for version number, that is pretty much irrelevant in open source. Take a look at the number and frequency of releases, how long the project has existed and so forth, and community around the project. M2Crypto is over 7 years old, has had at least one release a year, and although it doesn't have a large community around it, most of the changes over the last few years have been submitted by someone else than the maintainer. -- Heikki Toivonen - http://heikkitoivonen.net

1 0

Re: default behavior
by John Posner July 31, 2010

July 31, 2010

On 7/31/2010 11:08 AM, Christian Heimes wrote: > ... All you have to do is subclass dict and implement a > __missing__ method. See > http://docs.python.org/library/stdtypes.html?highlight=__missing__#mapping-… > Caveat -- there's another description of defaultdict here: http://docs.python.org/library/collections.html#collections.defaultdict ... and it's bogus. This other description claims that __missing__ is a method of defaultdict, not of dict. This might cause considerable confusion, leading the reader to suspect that __missing__ and default_factory fight it out for the right to supply a default value. (__missing__ would win -- I tried it.) The truth, as Christian says above and as Raymond Hettinger recently pointed out [1], is that __missing__ is used to *define* defaultdict as a subclass of dict -- it's not used *by* defaultdict. -John [1] http://mail.python.org/pipermail/python-list/2010-July/1248896.html

2 1

International IT Consultant Jobs from 14 Countries
by Bolaleman July 31, 2010

July 31, 2010

Looking for IT consultant jobs? Maybe you find your new job in the USA, Canada, Australia, India or in Europe using this IT consultant job database: http://2ajobguide.com/consulting_IT_job_database.aspx This service is free and you can apply directly without intermediates.

1 0

Re: default behavior
by Steven D'Aprano July 31, 2010

July 31, 2010

On Fri, 30 Jul 2010 07:59:52 -0400, wheres pythonmonks wrote: > Instead of defaultdict for hash of lists, I have seen something like: > > > m={}; m.setdefault('key', []).append(1) > > Would this be preferred in some circumstances? Sure, why not? Whichever you prefer. setdefault() is a venerable old technique, dating back to Python 2.0, and not a newcomer like defaultdict. > Also, is there a way to upcast a defaultdict into a dict? "Upcast"? Surely it is downcasting. Or side-casting. Or type-casting. Whatever. *wink* Whatever it is, the answer is Yes: >>> from collections import defaultdict as dd >>> x = dd(int) >>> x[1] = 'a' >>> x defaultdict(<type 'int'>, {1: 'a'}) >>> dict(x) {1: 'a'} > I have also heard some people use > exceptions on dictionaries to catch key existence, so passing in a > defaultdict (I guess) could be hazardous to health. Is this true? Yes, it is true that some people use exceptions on dicts to catch key existence. The most common reason to do so is to catch the non-existence of a key so you can add it: try: mydict[x] = mydict[x] + 1 except KeyError: mydict[x] = 1 If mydict is a defaultdict with the appropriate factory, then the change is perfectly safe because mydict[x] will not raise an exception when x is missing, but merely return 0, so it will continue to work as expected and all is good. Of course, if you pass it an defaultdict with an *inappropriate* factory, you'll get an error. So don't do that :) Seriously, you can't expect to just randomly replace a variable with some arbitrarily different variable and expect it to work. You need to know what the code is expecting, and not break those expectations too badly. And now you have at least three ways of setting missing values in a dict. And those wacky Perl people say that Python's motto is "only one way to do it" :) -- Steven

3 2

Re: default behavior
by Steven D'Aprano July 31, 2010

July 31, 2010

On Sat, 31 Jul 2010 01:02:47 -0400, wheres pythonmonks wrote: >> Hint -- what does [].append(1) return? >> >> > Again, apologies from a Python beginner. It sure seems like one has to > do gymnastics to get good behavior out of the core-python: > > Here's my proposed fix: > > m['key'] = (lambda x: x.append(1) or x)(m.get('key',[])) > > Yuck! Yuk is right. What's wrong with the simple, straightforward solution? L = m.get('key', []) L.append(1) m['key'] = L Not everything needs to be a one-liner. But if you insist on making it a one-liner, that's what setdefault and defaultdict are for. > So I guess I'll use defaultdict with upcasts to dict as needed. You keep using that term "upcast". I have no idea what you think it means, so I have no idea whether or not Python does it. Perhaps you should explain what you think "upcasting" is. > On a side note: does up-casting always work that way with shared > (common) data from derived to base? (I mean if the data is part of > base's interface, will b = base(child) yield a new base object that > shares data with the child?) Of course not. It depends on the implementation of the class. -- Steven

2 1

Re: Builtn super() function. How to use it with multiple inheritance? And why should I use it at all?
by Steven D'Aprano July 31, 2010

July 31, 2010

On Thu, 29 Jul 2010 12:08:54 +0200, Jean-Michel Pichavant wrote: > Steven D'Aprano wrote: >> That incorrect. You can certainly use super() with classic classes in >> the hierarchy, and super() didn't even exist when they were created. >> The problem isn't super(), and people who give glib advise "don't use >> super()" are just compounding the problem. The problem is with multiple >> inheritance where methods have different method signatures. If you >> don't change the method signatures, super() will work fine. [...] > I think you're missing the point that super for most of us is a > dangerous guess game. It makes implicit what would *really* need to be > explicit. No, I'm not missing the point. I'm *disagreeing* with the point. I'm saying that for simple inheritance hierarchies, super() does no harm, and it is *required* for most complex inheritance hierarchies. Given that, why not use it? I suppose that, if you're inheriting from an existing class which doesn't use super(), there may be issues (although I'm not convinced that those issues go away if you avoid super!) but for a new class under your control, there are no negatives to super() that didn't already exist with the nature of multiple inheritance. There is, as far as I can tell, ONE use-case where super() must be avoided, and that is a use-case that is discouraged for other reasons: where you change the method signature. If you're changing the method signature, you're already in dubious territory and better know what you're doing. You're violating the Liskov Substitution Principle, and if so, you better have a good reason. (I'm a bit skeptical about the LSP, but many people much smarter than I think it's virtually gospel, so who knows?) But either way, if you change the method signature, you're going to have problems somewhere unless you've really careful. The problems with super() are merely symptoms of that change. If you don't change the method signature, then I don't believe super() does any harm, regardless of whether you have single inheritance or multiple inheritance, whether it is a diamond diagram or not. The worst that can be said about it is that super()'s signature is hard to understand. I would argue that your argument about "explicit" and "implicit" is incorrect. You shouldn't want to explicitly specify which class you are inheriting from, at least not under normal circumstances. It is enough to say that you are inheriting behaviour. If you have a Widget class, and you find yourself explicitly calling methods by *named* superclasses, you're probably doing something wrong. It should always be possible to insert a class higher up the hierarchy, or rename a grandparent, without effecting your class. (Obviously you can't expect to rename an immediate parent class.) super() is just as explicit as len(), or str.upper(). It says, explicitly, that it will call the method belonging to one or more superclass of the given class. That's no more implicit than mylist[5] is implicit merely because you didn't have to walk the list by hand. > class Base1(object): > def foo(self): > print 'Base1' > > > class Base2(object): > def foo(self): > print 'Base1' > > > class Sub(Base1, Base2): > def foo(self): > # which base version to call ??? > # choice A > # use super an pray that it will do what I need (better > know exactly how the MRO works) But the point is, super() knows exactly how the MRO works, so you don't have to. > # also pray that further readers know as much as I do > about super Now that's just silly. Do you write all your classes for the lowest common denominator? Do you assume all you users are ignorant? If you subclass dict, do you feel the need to "pray" that your users won't try to use mutable objects as keys? If you avoid super(), do you "pray" that your users won't try to use your class in a multiple inheritance situation, and have a buggy class? I bet you don't. If they misuse your class, that's their responsibility. > # choice B > # use explicit calls so I can choose which algorithm I > want to use, calling Base1, Base2 or both of them That's a fair point. super() uses the standard MRO algorithm, it isn't a "Do What I Mean" mind- reading function. If you want an unusual MRO, then you're responsible for managing it yourself. Go right ahead, this is Python and you have all the tools to do so. Nothing forces you to inherit behaviour from the superclasses at all -- super() is designed for overloading (extending) the behaviour of methods, and so the assumption is that you want to call the method in each superclass. But if you're overriding the method instead, or doing something unusual, then you're in charge. > # If the choice is too difficult, that means one thing > => my inheritance design is crap => rewrite it properly. > > Super is known for being required for diamond inheritance, and this > reputation is well earned. Outside this scope, super's not required. Of course it's not required. Nor does it do any harm. Far from it -- your single inheritance subclass might be just what another user needs for a multiple inheritance class, and by not using super(), you ruin it for him. -- Steven

4 6

Electronic purchase with the latest technology know this fantastic store you make your purchase and receive in five days at home buy to resell or use propio
by jhom July 31, 2010

July 31, 2010

Electronic purchase with the latest technology know this fantastic store you make your purchase and receive in five days at home buy to resell or use propio http://www.internationaleletronicos.com/

1 0

Get perl method documentation in python wrapper
by srinivasan munisamy July 31, 2010

July 31, 2010

Hi, I would like to get the documentation of a perl method inside python wrapper. To say it with example, there is a perl module ‘X.pm’. It has a method ‘print_hello()’. x.py is a wrapper module over X.pm. when I say x.print_hello.__doc__ then I need to get the documentation of X::print_hello. The main reason why i want to do that i do not want to re-write the whole documentation again in python. Is there a way to do that? Thanks, Srini

1 0