This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vinay.sajip
Recipients asvetlov, carljm, vinay.sajip
Date 2012-07-23.15:37:01
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1343057821.86.0.596881842962.issue15417@psf.upfronthosting.co.za>
In-reply-to
Content
I have no objection in principle to supporting additional shells, but do have the following comments/questions:

1. Georg feels that this is a new feature he doesn't want to add to 3.3. IMO we have to respect his judgement as RM, no matter how trivial the change might seem. It's more about the discipline of the process than it is about any one specific change.

2. Where do we draw the line in terms of support for ("arbitrary") shells? Each activation script will potentially need maintenance into the future. It was originally envisaged that the stdlib code would add minimal support for activation scripts and that third-party tools would add support for additional shells and other value-adding features. The venv API design was intended to facilitate usage by third-party code.
History
Date User Action Args
2012-07-23 15:37:01vinay.sajipsetrecipients: + vinay.sajip, carljm, asvetlov
2012-07-23 15:37:01vinay.sajipsetmessageid: <1343057821.86.0.596881842962.issue15417@psf.upfronthosting.co.za>
2012-07-23 15:37:01vinay.sajiplinkissue15417 messages
2012-07-23 15:37:01vinay.sajipcreate