[Fred] > Now that this idea has fermented for a few days, I'm inclined to not > like it. It smells of making Unix-centric interface to something that > isn't terribly portable as a concept. > Perhaps there should be a function that does the "right thing", > extracting os.environ["HOME"] if defined, and taking an alternate approach > (os.getcwd() or whatever) otherwise. I don't think setting > os.environ["HOME"] in the library is a good idea because that changes the > environment that gets published to child processes beyond what the > application does. The passing on to child processes doesn't sound like a big deal to me. Either these are Python programs, in which case they might appreciate that the work has already been done, or they aren't, in which case they probably don't look at $HOME at all (since apparently they worked before). I could see defining a new API, e.g. os.gethomedir(), but that doesn't help all the programs that currently use $HOME... Perhaps we could do both? (I.e. add os.gethomedir() *and* set $HOME.) --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4