From: lkcl on
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
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
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
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
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