> > That fixes all your scripts/applications/buildsystems at once, which
is an
> > approach that scales much better than adding complexity to 150 other
projects.
>
This argument may apply for some tools. Certainly I think it is fair to
expect
'touch' to be the touch tool, and rm to be that tool that removes things.
If a
user overrides touch or rm that seems like a silly thing to do which should
be
fixed.
Python is different because my python binary _is_ python - it's just python
3
and not python 2.7. This is not an inherent bug or problem that I want to
fix.
This CL is an example of complexity that I think can be avoided. If you
happen
to run one of the 1% of Unix-like operating systems where "python" isn't
called
"python", fixing your system is easier, more robust and more scalable than
fixing all scripts that expect to have a plain "python" binary somewhere
on
the
$PATH. (Even better, upstream the change to make the OS more usable for
everyone.)
python3 is the future of python. There may be only a few oses that have
taken
the plunge to having it as default, but that will change. It is a release
goal
for Ubuntu 14.04 LTS to have only Python 3 on the desktop CD images[1].
While it
is fine to use python 2 for now, recognizing that python is not and will not
always be python 2 is important to allow all users to build.
[1] https://wiki.ubuntu.com/Python/3
https://codereview.chromium.org/11418101/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
