safer ctype? (was GUIs - A modest Proposal)

[lkcl]

On Jun 12, 6:05 pm, Stephen Hansen <me+list/pyt... at ixokai.io> wrote:
> On 6/12/10 9:55 AM, lkcl wrote:
>
> > On Jun 12, 8:11 am, "Martin v. Loewis" <mar... at v.loewis.de> wrote:
> >> Notice that it's not (only) the functions itself, but also the
> >> parameters. It's absolutely easy to crash Python by calling a function
> >> through ctypes that expects a pointer, and you pass an integer. The
> >> machine code will dereference the pointer (trusting that it actually is
> >> one), and crash.
>
> >  what's so bad about that?  (this is a genuine, non-hostile, non-
> > rhetorical, non-sarcastic question).
>
> >  (if the answer is "because you can't catch a segfault as a python
> > exception", then the question is repeated)
>
> ... ?!
>
> Its not OK for code written in Python to cause a segfault; its not OK

[i knew this would be the / an / something-like-the answer, but i'm
just... "reading the script" so to speak]

> Its one of the reasons why we *like* Python at my day job. (Though it
> applies to nearly any other high level language): its inherently safer.
> A programming goof, oversight or unexpected event causes an exception.
> It doesn't cause a buffer overflow.

 ok... analogy: when using g++ to compile c++ code, would you place
use of "asm" statements into the same sort of foot-shooting category?

> P.S. Yes, I do understand that ctypes invalidates those assumptions. And
> that's OK. Every once in awhile, with great care and research to make
> sure I know what I'm doing, I'll take the risk anyways. I do understand
> the policy in terms of the stdlib though. I just wish it didn't apply to
> win32 API's somehow. No, I know its not at all logical. Leave me alone. :)

 teehee :)