erustemi

I tend to agree with you, not for the different semantic aspect, since they both are capable of expressing the same thing (with checked exceptions), but for the performance impact of exceptions. If I'm not mistaken throwing an exception has a much larger cost than a simple return due to needing to construct the stacktrace.

So using exceptions for an expected path of a function seems sub-optimal.

Maybe the issue was with how powerful and unrestricted reflection was in java before introduction of modules.

I think a proper way to solve this issue, not specific to python but languages running in a VM in general, would be to have some sort of language support where you specifically define what access rights/ system resources you allow for any given dependency.

Example of defining project dependencies:

  {
    "apollo-client": {
      "version": "...",
      "access": ["fetch"] // only fetch allowed
    },
    "stringutils": {
       "version": "...",
       "access": [] // no system resources allowed for this dependency, own or transitive
    },
    ...
  }

It would probably require the language to limit monkey-patching core primitives (such as Object.prototype in javascript), and it would be more cumbersome for the developer to define the permissions it gives to each dependency. These required permissions could be listed on the package site (eg npm or PyPI) and the developer would just copy paste the permissions when adding the dependency. But if you upgrade a dependency version and it now requires a permission that seems suspicious (eg "stringutils" needing "filesystem"), it would prompt the developer to stop and investigate, or if it seems justified add the permission to "access" list.