On Sun, Jun 3, 2012 at 3:33 AM, Christian Tismer <tis...@stackless.com> wrote: > As an old windows guy, I very much agree with Kristjan. The venv > approach is great. Windows is just a quite weird situation to handle > in some cases, and a super-simple way to get rid of *any* built-in behavior > concerning setup would be great. > > The idea of moving path setup stuff into the python.exe stub > makes very much sense to me. This would make pythonxx.dll > a really useful library to be shared.
It's mainly Py_Initialize() that triggers the magic. What may be worth exploring is a variant on that which allows embedding applications to explicitly pass in *everything* that would otherwise be guessed by inspecting the environment. (Some things can be forced to particular values already, but certainly not everything). > Python has IMHO too much behavior like this: > 'by default, look into xxx, but if a yyy exists, behave differently'. > I don't like this, because the absense of a simple file changes the whole > system behavior. > I would do it the other way round: > As soon as you introduce the venv.cfg file, enforce its existence > completely! If that file is not there, then python exits with an error > message. > This way you can safely ensure its existence, and the file can be made > read-only and so on. A non-existent file is just a bad thing and is hard to > make > read-only ;-) > So please let's abandon the old 'if exists ...' pattern, at least this one > time. > By the explicit cfg file, the file can clearly say if there is a virtual env > or not. Backwards compatibility constraints mean we simply can't do that. However, as noted above, it may make sense to provide more ways for embedding applications to selectively access the behaviour through the C API. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
