On Mon, Aug 07, 2017 at 08:11:40PM -0700, Diane Trout wrote: > > What I am opposing is the suggestion to install, in the near to > > medium > > term, a command of exactly the same name that has subtly similar but > > incompatible behaviour, when that behaviour *already* has a command – > > ‘python3’ – that is widely used by those who need it.
> my problem with that plan is all of the printed documentation saying to > learn python, type "python". > At the very least there needs to a usr/bin/python that prints > instructions about what you should run. FWIW I don't share Ben's concern about this being a "backwards incompatible" change (who is relying on the precise contents of the banner when running 'python' interactively?!). But I am concerned about possible implementation strategies here. exec() is a very expensive syscall, and python is a frequently used interpreter. If this were implemented as a wrapper that checked isatty(), printed a banner, and then re-execed the real python, that could have a measurable performance impact on some applications. There is a reason /usr/bin/python, /usr/bin/gcc, etc. are always symlinks to the real interpreter on Debian, not wrapper scripts - other distributions have tried to do this as a wrapper script and the result wasn't pretty. Avoiding the performance hit would require that any changes to the banner be made in the python source itself. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
