On 10/30/2012 10:29 PM, Michael Torrie wrote:
As this is the case, why this long discussion? If you are arguing for
a change in Python to make it compatible with what this fork you are
going to create will do, this has already been fairly thoroughly
addressed earl on, and reasons why the semantics will not change
anytime soon have been given.
I'm not arguing for a change in the present release of Python; and I
have never done so.
Historically, if a fork happens to produce something surprisingly
_useful_; the main code bank eventually accepts it on their own. If a
fork is a mistake, it dies on its own.
That really is the way things ought to be done.
include this
The Zen of Python, by _Tim Peters_
....
Special cases aren't special enough to break the rules.
Although _practicality beats purity_.
....
Now, I have seen several coded projects where the idea of cyclic lists
is PRACTICAL;
and the idea of iterating slices may be practical if they could be made
*FASTER*.
These warrant looking into -- and carefully; and that means making an
experimental fork; preferably before I attempt to micro-port the python.
Regarding the continuing discussion:
The more I learn, the more informed decisions I can make regarding
implementation.
I am almost fully understanding the questions I originally asked, now.
What remains are mostly questions about compatibility wrappers, and how
to allow them to be used -- or selectively deleted when not necessary;
and perhaps a demonstration or two about how slices and named tuples can
(or can't) perform nearly the same function in slice processing.
--
http://mail.python.org/mailman/listinfo/python-list
