On Sat, Jan 26, 2013 at 8:48 PM, Cameron Simpson <c...@zip.com.au> wrote: > On 25Jan2013 21:07, Nick Coghlan <ncogh...@gmail.com> wrote: > | It's a configurable setting in the same way that -Q makes the > | behaviour of "/" configurable in Python 2 (so your hypothetical > | example isn't hypothetical at all - it's a description the -Q option), > | and -R makes random hashing configurable in 2.7 and 3.2: it means we > | can change the default behaviour in a future version (perhaps Python > | 4) while allowing people to easily check if their code operates > | correctly in that state in the current version. > | > | I think the default behaviour needs to be configurable from the > | environment and the command line, but I don't believe it should be > | configurable from within the interpreter. > > Hmm. This I can live with more happily, though I'm still uneasy. > > As an aside, I tend to feel that if something is tuneable it should be > exposed within the interpreter. Maybe only in an exciting new module > called shoot_self_in_foot or some similarly alarming name...
I had missed this detail. I agree that it should be exposed in the interpreter. To my mind it is more like PYTHONPATH (which corresponds roughly to sys.path manipulations) than like -R (which changes something that should never be changed again, otherwise the sanity of the interpreter be at risk). It would seem hard to unittest the feature if it cannot be changed from within. But I can also think of other use cases for changing it from within (e.g. a script that decides on how to set it using a computation based on its arguments). -- --Guido van Rossum (python.org/~guido) _______________________________________________ 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
