4 ms·

Isn't all Python, by design, unsafe?

eru 2y ago
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.
- intelVISA 2y ago
  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'.
  - eru 2y ago
    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.
    - intelVISA 2y ago
      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
      - eru 2y ago
        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.
      - dahart 2y ago
        It’s a term of art in this case. Or someone proposed the term improper noun https://news.ycombinator.com/item?id=32673100 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?
  - recursive 2y ago
    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.
westurner 2y ago
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
- Retr0id 2y ago
  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.
  - westurner 2y ago
    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
    - maple3142 2y ago
      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.
      - jwilk 2y ago
        Complete example without eval: def f(): pass f.__code__ = f.__code__.replace(co_consts=()) f()
        Retr0id 2y ago
        yup, eval was just there for golfing purposes
emmanueloga_ 2y ago
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 https://en.wikipedia.org/wiki/Type_safety 2: https://en.wikipedia.org/wiki/Memory_safety https://en.wikipedia.org/wiki/Memory_safety 3: https://en.wikipedia.org/wiki/Type_system#Type_checking https://en.wikipedia.org/wiki/Type_system#Type_checking 4: https://en.wikipedia.org/wiki/Strong_and_weak_typing https://en.wikipedia.org/wiki/Strong_and_weak_typing
- d0mine 2y ago
  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
  - eru 2y ago
    Yes, though `ctypes' is kind of marked as `unsafe' in Python by convention.

eru 2y ago

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.

intelVISA 2y ago
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'.
- eru 2y ago
  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.
  - intelVISA 2y ago
    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
    - eru 2y ago
      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.
    - dahart 2y ago
      It’s a term of art in this case. Or someone proposed the term improper noun https://news.ycombinator.com/item?id=32673100 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?
- recursive 2y ago
  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.

westurner 2y ago

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

Retr0id 2y ago
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.
- westurner 2y ago
  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
  - maple3142 2y ago
    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.
    - jwilk 2y ago
      Complete example without eval: def f(): pass f.__code__ = f.__code__.replace(co_consts=()) f()
      - Retr0id 2y ago
        yup, eval was just there for golfing purposes

emmanueloga_ 2y ago

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 https://en.wikipedia.org/wiki/Type_safety 2: https://en.wikipedia.org/wiki/Memory_safety https://en.wikipedia.org/wiki/Memory_safety 3: https://en.wikipedia.org/wiki/Type_system#Type_checking https://en.wikipedia.org/wiki/Type_system#Type_checking 4: https://en.wikipedia.org/wiki/Strong_and_weak_typing https://en.wikipedia.org/wiki/Strong_and_weak_typing

d0mine 2y ago
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
- eru 2y ago
  Yes, though `ctypes' is kind of marked as `unsafe' in Python by convention.