It's not enough :-) Ask the OCaml folks, they're going through this pain right now because their stdlib modules are called `Array`, `List`, and so on. They're planning to put them all under `Stdlib`, so e.g. `Stdlib.Array` and so on, but it's going to be a big effort with a lot of pain.
The main problem will arise when users create their own libraries; suppose some people create a `Option` libraries and then later you want to add a standard option type to Carp, it will be painful. Better to namespace your stuff under `Carp` from the beginning, so e.g. `Carp_IO_println`, `Carp_Option_map`, and so on.
I wonder how this compares to the Python ecosystem, whose standard library is also quite large. (Anyone remembers their famous "batteries-included" mantra?)
Python 2 didn't have a stdlib namespace, or "package" in Python speak. But when they created their clean-slate approach with Python 3, they also decided not to introduce a stdlib package. External Python packages just avoid the stdlib package names, and everything seems fine.
So, is there something in the Python language that makes the missing?
Or is it just the Python community which doesn't care about (or plays down) this issue?
As a Python programmer, I would consider code which shadows the names of built-ins to be poorly written although it's permissible in small scopes (e.g., a single block).
The main problem will arise when users create their own libraries; suppose some people create a `Option` libraries and then later you want to add a standard option type to Carp, it will be painful. Better to namespace your stuff under `Carp` from the beginning, so e.g. `Carp_IO_println`, `Carp_Option_map`, and so on.