Python ctypes / pywin32 [was: GUIs - A Modest Proposal]
in [Python]
|
Prev: How do subprocess.Popen("ls | grep foo", shell=True) with shell=False?
Next: WebBrowserProgramming [was: GUIs - A Modest Proposal]
From: lkcl on 12 Jun 2010 11:57 On Jun 10, 6:26 pm, "Martin v. Loewis" <mar...(a)v.loewis.de> wrote: > >> or PyGui would need to be implemented in terms of ctypes (which then > >> would prevent its inclusion, because there is a policy that ctypes > >> must not be used in the standard library). > > > Is there? I wasn't aware of that. What's the reason? > > ctypes is inherently unsafe. that's ok. only the sanest and most careful of programmers are going to use it. and all they're going to do is crash their application if they get it wrong. or, on an OS which is _known_ to be so unstable that it will fall over with the slightest provocation, crash the OS and require a press of that little button which was moved to the front _just_ to deal with that OS's instability, once again. just because a library has a means for programmers to shoot themselves in the foot doesn't mean that the programming language should come with kevlar-reinforced bullet-proof vests. > It must be possible to remove it > from a Python installation, as long as that's not an official policy statement that ctypes will, at some point in the future, be removed from python, i'm happy. the last thing i want to have to do is to have to include and maintain, as part of the pyjamas download, a complex python-ctypes library in order to get at the win32 functions "CreateWindowEx"; the second last thing i want to have to do is rewrite pyjd's MSHTML port; the third last thing i want to have to do is state that a 2nd and _much_ larger library dependency/download is required: pywin32. one of the really nice things about having chosen ctypes and a copy of henk punkt's windows.py file is that the only dependency required is one single 350k download: python-ctypes. last time i looked, pywin32 was a whopping 6mb, and there's _nothing_ in pywin32 that pyjd actually needs. i deliberately bypassed python-win32com for exactly the same reason: it turns out that direct ctypes access to Variant and all other OLE / COM types is perfectly sufficient. removal of ctypes would be a big, big mistake. i trust that i have misinterpreted the implication of what you're saying, martin. l.
From: Robert Kern on 12 Jun 2010 13:56 On 2010-06-12 10:57 , lkcl wrote: > On Jun 10, 6:26 pm, "Martin v. Loewis"<mar...(a)v.loewis.de> wrote: > >>>> or PyGui would need to be implemented in terms of ctypes (which then >>>> would prevent its inclusion, because there is a policy that ctypes >>>> must not be used in the standard library). >> >>> Is there? I wasn't aware of that. What's the reason? >> >> ctypes is inherently unsafe. > > that's ok. only the sanest and most careful of programmers are going > to use it. and all they're going to do is crash their application if > they get it wrong. or, on an OS which is _known_ to be so unstable > that it will fall over with the slightest provocation, crash the OS > and require a press of that little button which was moved to the front > _just_ to deal with that OS's instability, once again. > > just because a library has a means for programmers to shoot > themselves in the foot doesn't mean that the programming language > should come with kevlar-reinforced bullet-proof vests. That's exactly why it's *in* the standard library, but also exactly why it won't be *used by* other parts of the standard library. If it's used by other parts of the standard library, then it won't be the case that only the sanest and most careful of programmers are going to use it. >> It must be possible to remove it >> from a Python installation, > > as long as that's not an official policy statement that ctypes will, > at some point in the future, be removed from python, i'm happy. > > the last thing i want to have to do is to have to include and > maintain, as part of the pyjamas download, a complex python-ctypes > library in order to get at the win32 functions "CreateWindowEx"; the > second last thing i want to have to do is rewrite pyjd's MSHTML port; > the third last thing i want to have to do is state that a 2nd and > _much_ larger library dependency/download is required: pywin32. > > one of the really nice things about having chosen ctypes and a copy > of henk punkt's windows.py file is that the only dependency required > is one single 350k download: python-ctypes. last time i looked, > pywin32 was a whopping 6mb, and there's _nothing_ in pywin32 that pyjd > actually needs. > > i deliberately bypassed python-win32com for exactly the same reason: > it turns out that direct ctypes access to Variant and all other OLE / > COM types is perfectly sufficient. > > removal of ctypes would be a big, big mistake. i trust that i have > misinterpreted the implication of what you're saying, martin. Yes. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
From: Stephen Hansen on 12 Jun 2010 13:59 On 6/12/10 8:57 AM, lkcl wrote: > On Jun 10, 6:26 pm, "Martin v. Loewis" <mar...(a)v.loewis.de> wrote: >> It must be possible to remove it >> from a Python installation, > > as long as that's not an official policy statement that ctypes will, > at some point in the future, be removed from python, i'm happy. I believe the point is that it must be possible for users/admins to remove it, and that this removal will not cause any other part of the standard library to fail to function. -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/
From: lkcl on 12 Jun 2010 15:32 On Jun 12, 5:56 pm, Robert Kern <robert.k...(a)gmail.com> wrote: > > just because a library has a means for programmers to shoot > > themselves in the foot doesn't mean that the programming language > > should come with kevlar-reinforced bullet-proof vests. > > That's exactly why it's *in* the standard library, but also exactly why it won't > be *used by* other parts of the standard library. If it's used by other parts of > the standard library, then it won't be the case that only the sanest and most > careful of programmers are going to use it. ack. understood. thank you. > > removal of ctypes would be a big, big mistake. i trust that i have > > misinterpreted the implication of what you're saying, martin. > > Yes. ok whew :)
From: Terry Reedy on 12 Jun 2010 18:52
On 6/12/2010 11:57 AM, lkcl wrote: > On Jun 10, 6:26 pm, "Martin v. Loewis"<mar...(a)v.loewis.de> wrote: > >> ctypes is inherently unsafe. >> It must be possible to remove it >> from a Python installation, Which is to say, anyone who wants to remove it from *their* individual custom installation should be able to do so, without disabling other stdlib modules. I can imagine someone providing Python hosting on shared machines might want to do so. [snip] > removal of ctypes would be a big, big mistake. i trust that i have > misinterpreted the implication of what you're saying, martin. I believe so. It was an independent 3rd party module of Thomas Heller (who is still maintaining it) until recently and I have seen no suggestion that it be removed in general from the PSF distribution. Indeed, other distributions are implementing it also. Interface modules written with ctypes are more portable to such than the same modules written in C with, for instance, SWIG. For some people, is it also much easier than SWIG. So it is an important addition to the stdlib. Terry Jan Reedy |