From: Martin v. Loewis on 12 Jun 2010 20:21 Am 12.06.2010 17:33, schrieb Stephen Hansen: > On 6/12/10 12:21 AM, Martin v. Loewis wrote: >>> Otherwise it makes certain windows-workarounds very problematic. You >>> basically /have/ to write a C extension :| >> >> That's not problematic at all, for the standard library. Just write that >> C extension. > > Come now, of course it is. It may not be problematic for *you*, but it > *is* problematic for a lot of people. Sure, but a lot of people don't contribute to the standard library. They can happily continue to use ctypes. Please trust me that, *for the standard library*, the requirement to write explicit wrappers never was a problem. > Maybe Cython'll be mature enough eventually that the stdlib could accept > Cython-based "C" extensions for such cases. For Cython, the issue is rather the bootstrapping issue (would we need to incorporate it if we have Cython code in CPython?). Perhaps the answer is "no", assuming that the generated C file also gets checked into Python (after all, autoconf is also not distributed along with Python). Regards, Martin
From: Martin v. Loewis on 12 Jun 2010 20:25 > Would it be possible to write a program that converts a module that uses > ctypes to interface to a dll to a corresponding C extension program that > would compile to a drop in replacement extension module? If implemented at all, I think the ctypes implementation itself could do that. I.e. create all the function objects, let the Python script declare the APIs, and then generate C code from those signatures. The C code would then best be adjusted: you'd rather use the struct declarations from the header files instead of the one you learned from ctypes (which may be wrong, or processor-dependent, or version-dependent). So a manual adjustment of header files would be necessary afterwards. Regards, Martin
From: Gregory Ewing on 12 Jun 2010 23:22 Terry Reedy wrote: > Would it be possible to write a program that converts a module that uses > ctypes to interface to a dll to a corresponding C extension program that > would compile to a drop in replacement extension module? Probably, but I don't see how that could be done automatically in a way that ensured the result would be any safer than the original ctypes-using version. If you preserve the semantics of the Python code, you also preserve any bugs it might have. -- Greg
From: Gregory Ewing on 12 Jun 2010 23:34 lkcl wrote: > * in neither gtk nor qt does there exist an "auto-layout" widget > that's equivalent to putting some <span /> DOM objects into a <div />, > to "flow" widgets that wrap around. You essentially seem to be complaining here that pqyqt and pygtk are not HTML. They have their own auto-layout mechanisms that do what they're designed to do well enough -- they just happen to be based on a different model from HTML. I'm far from convinced that HTML and CSS are the One True Way to design GUIs these days, that web apps are about to take over the world, etc. There is still a place for GUI toolkits that are not based on the DOM, or whatever the W3C technology of the month is. -- Greg
From: Stephen Hansen on 13 Jun 2010 02:33
On 6/12/10 8:34 PM, Gregory Ewing wrote: > lkcl wrote: > >> * in neither gtk nor qt does there exist an "auto-layout" widget >> that's equivalent to putting some <span /> DOM objects into a <div />, >> to "flow" widgets that wrap around. > > You essentially seem to be complaining here that pqyqt and > pygtk are not HTML. They have their own auto-layout mechanisms > that do what they're designed to do well enough -- they just > happen to be based on a different model from HTML. > > I'm far from convinced that HTML and CSS are the One True Way > to design GUIs these days, that web apps are about to take over > the world, etc. There is still a place for GUI toolkits that > are not based on the DOM, or whatever the W3C technology of > the month is. Agreed. While "web interfaces" have a certain appeal, and definite strengths, they have difficulties as well. Although I have never used gtk directly, I do use wxWidgets/wxPython extensively, and its Linux-port is GTK based. Its a serious learning curve, I do freely admit. But once I began to think in wx, it works well. And all of my wxPython apps use dynamic / "auto-layout" sort of orientation and sizing without any sort of explicit management. So its clearly -possible-. Maybe its entirely done in wx, and wx does all the pain that lkcl went through trying to get gtk to do it. But that seems unlikely. But I don't actually know, one way or the other. -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ |