Also in respect to Issue 6203 i could talk about a project which did not link against anything in the end, only ld(1) and syscalls and the undocumented third 'char **envp' arg to UNIX main()s.
Thus: all of you should be *very* happy about the warm and cosy environment of LibC etc.!
You've decided to re-Python as Py3k, is guess it has got something to do with, let me describe it as, UNICODE.
Thus: you need a locale.

- Environment: has an encoding, though keys are ok to parse in ASCII
  (unless your OS allows wide characters *optionally*).
  Still, LC_ values may be specified in a *lot* of different ways,
  but one thing is true: it's a hard to do in plain C without being
  able to use stuff which *may* depend upon an initialized library
- Path names: have an encoding
- Console I/O: has an encoding
- File I/O: this is all dumb bytes, just do what you want

Conclusion: you need a locale.

- Hardcode defaults
- Spread specific things all across the implementation.
  I.e., in path access, use some os.path._sysdep.default_codeset(),
  in console I/O do os.console._sysdep.default_codeset() etc.
  (i'm lying about names)
- Perform an initial global initialization

So - what are you all talking about?
Noone - and i really mean NOONE - can assume that a fully blown environment like python(1) can be used as an isolated sandbox thing
like ECMAScript!  File I/O, child processes ...  Shall an entire interpreter lifecycle be possible in a signal(3) handler
(uuhh, just kiddin')?  Even if that would be true for 2.7 (don't know), in Py3k there is graceful and neatless UNICODE support.
You need a locale.

I would indeed insist on the following:
- The interpreter *has* to be initialized in the cosy LibC
  (or whatever native thing) environment.
  Like this it embeds itself neatlessly in there.
  This *has* to be performed in an *unthreaded* state.
  If you are really concerned about anything here,
  add an additional argument (or is it there yet?  I did *not*
  look in there - i would/will need long months to get an idea
  of the entire python(1) system) to your interpreter's setup()
  like thing, or allow NULL to nevertheless use setlocale() directly.
  Like this the embedder can choose herself which approach she
  wants to adhere.
- Even if 3.DID_IT ends up with a lot of 'encoding=STRING' instead
  of 'codec=None' (aka 'codec=codec_instance'), i would implement
  the system in a way that a change at a single place is automatically
  reflected all through the system (on a no-arg-then-use-default)
  base.

After the end:
someone who earned about 150 bucks from me for two books i bought
almost a decade ago once i've started Thinking In ... programming
said some years ago (as i've read in the german magazine c't):
    "In Python i am even more productive than with Java."
(I always was in doubt about that person - someone who is productive
in Java, who may that be?)
Thanks for python(1), and have a nice weekend.