On 10/30/2012 11:02 AM, Ian Kelly wrote:
On Tue, Oct 30, 2012 at 10:14 AM, Ethan Furman<et...@stoneleaf.us> wrote:
File a bug report?
Looks like it's already been wontfixed back in 2006:
http://bugs.python.org/issue1501180
Thanks, IAN, you've answered the first of my questions and have been a
great help.
(And yes, I was debugging interactive mode... I took a nap after writing
that post, as I realized I had reached my 1 really bad post for the day... )
I at least I finally know why Python chooses to implement slice() as a
separate object from tuple; even if I don't like the implications.
I think there are three main consequences of the present implementation
of slice():
1) The interpreter code size is made larger with no substantial
improvement in functionality, which increases debugging effort.
2) No protection against perverted and surprising (are you surprised?! I
am) memory operation exists.
3) There is memory savings associated with not having garbage collection
overhead.
D'Apriano mentioned the named values, start, stop, step in a slice()
which are an API and legacy issue; These three names must also be
stored in the interpreter someplace. Since slice is defined at the "C"
level as a struct, have you already found these names in the source code
(hard-coded), or are they part of a .py file associated with the
interface to the "C" code?
--
http://mail.python.org/mailman/listinfo/python-list
