Hacker News Reader

Comment by intelVISA | Hacker News Reader

Isn't all Python, by design, unsafe?

As others commented "safety" is a heavily overloaded term, for instance there's "type safety" [1] and "memory safety" [2], and then there's "static vs dynamic typing" [3], and "weak vs strong typing" [4], so talking about types and safety offered by a language can be very nuanced.

I suspect when you say "unsafe by design" you may be referring to the dynamic type checking aspect of Python, although Python has supported for a while type annotations, that can be statically checked by linter-like tools like PyRight.

1: https://en.wikipedia.org/wiki/Type_safety

2: https://en.wikipedia.org/wiki/Memory_safety

3: https://en.wikipedia.org/wiki/Type_system#Type_checking

4: https://en.wikipedia.org/wiki/Strong_and_weak_typing

Python both type and memory safe e.g., ""+1 in Python is TypeError and [][0] is IndexError

But you can perform unsafe operations e.g.,

    import ctypes
    ctypes.string_at(0)  # access 0 address in memory -> segfault

Yes, though `ctypes' is kind of marked as `unsafe' in Python by convention.

ctypes, c extensions, and CFFI are unsafe.

Python doesn't have an unsafe keyword like Rustlang.

In Python, you can dereference a null pointer and cause a Segmentation fault given a ctypes import.

lancedb/lance and/or pandas' dtype_backend="pyarrow" might work with pygame

You don't even need a ctypes import for it, you'll get a segfault from this:

   eval((lambda:0).__code__.replace(co_consts=()))

cpython is not memory safe.

Static analysis of Python code should include review of "unsafe" things like exec(), eval(), ctypes, c strings, memcpy (*),.

Containers are considered nearly sufficient to sandbox Python, which cannot be effectively sandboxed using Python itself. Isn't that actually true for all languages though?

There's a RustPython, but it does support CFFI and __builtins__.eval, so

The example given by parent does not need eval to trigger though. Just create a function and replace its code object then call it, it will easily segfault.

Complete example without eval:

  def f(): pass
  f.__code__ = f.__code__.replace(co_consts=())
  f()

yup, eval was just there for golfing purposes

Is this supposed to be a joke?

Have a look at the linked article to see what meaning of 'unsafe' the author has in mind.

Safety is catching (more) errors ahead of time ...for which Python is grossly unsuitable imo.

Fun lang though, just not one that ever comes to mind when I hear 'safe'.

That's one definition of safety. But it's not the one the author uses in this case.

The generic snide about Python that has nothing to do with the article ain't all that informative.

You could make the same remark you just made about all Python being unsafe about Rust: 'Isn't all Rust, by design, unsafe?'. And compared to eg Agda or Idris that would be true, but it wouldn't be a very useful nor interesting comment when talking about specifically 'unsafe' Rust vs normal Rust.

I would agree, Rust is not safe. We need to encourage more formal rigor in our craft and avoid misconceptions like 'safe Rust' or 'safe Python'. Thus my original comment :P

Eh, even Agda is only safe in the sense of 'does what you've proven it to do'. That doesn't mean that if you eg write a machine learning library in Agda, your AI won't come and turn us all into paperclips.

So it doesn't really make sense to pretend there's some single meaning of 'safe' vs 'unsafe' that's appropriate in all contexts.

It’s a term of art in this case. Or someone proposed the term improper noun https://news.ycombinator.com/item?id=32673100

Fine and good to advocate rigor, whether or not it’s specifically relevant to this post, but maybe be careful with the interpretation and commentary lest people decide the misconception is on your part?

Memory corruption vs type safety.

"Safety" is an overloaded term, but that happens a lot in software. You'll probably get best results if you try to understand what people are talking about, rather than just assuming everyone else is an idiot.

Reply on news.ycombinator.com