Python "why" questions

J.B. Brown jbbrown at sunflower.kuicr.kyoto-u.ac.jp
Thu Aug 19 12:07:53 EDT 2010


2010/8/9 MRAB <python at mrabarnett.plus.com>:
> Default User wrote:
>>
>> Not to prolong a good "food fight", but IIRC, many years ago in QBasic,
>> one could choose
>>
>> OPTION BASE 0
>>
>> or
>>
>> OPTION BASE 1
>>

When I wrote my own C++ 2-D matrix class, I wrote a member function
which did exactly this - allow you to specify the initial index value.
Then users of my class (mainly my research lab coworkers) could
specify whichever behavior they wanted.

In terms of providing readable code and removing beginning programmer
confusion, why not extend python lists by using something similar to
(but not necessarily identical to)  the C++ STL containers:

C++
int myX[ ]  = { 1,2,3,4,5 };
std::vector<int> vectorX( myX, &myX[  sizeof( myX ) - 1 ] );
std::cout << vectorX.begin() << std::endl;
std::cout << vectorX.end() << std::endl;

Python
x = [ 1 , 2 , 3 , 4 , 5 ]
print x.first()
print x.last()    ,

where the first and last behavior of python is to return a deep copy
of the object, and not a pointer.
It seems that this would avoid complaints about the 0/1 issue.

Of course, the problem is the behavior of:
myList = [ myObject1, myObject2, myObject3, ... , myObjectLast ]
print myList.first() + 5   ,

in which one will conceptually might want to get the 6th item in a
list, though if first() is defined to return the object, then we get
the returned object plus 5, if such behavior is defined to exist.
I completely acknowledge that the behavior is not well defined, and
that is why I am not proposing this as a final implementation, but
rather as a concept and motivation.

For those who don't like Python's 0-based indexing, why not just build
a wrapper type which features an item() method that handles the
internal conversion from 1 to 0 as the starting index?
Better yet, include a method which sets/specifies the 0/1 behavior,
and have item() reference the 0/1 setting to obtain the proper offset.

Just a thought.

J.B. Brown
Kyoto University



More information about the Python-list mailing list