Python Feature Request: Allow changing base of member indices to 1

[samjnaa]

This is like the previous one. Please check for sanity and approve for
posting at python-dev.

I would like to have something like "option base" in Visual Basic.
IIRC it used to allow me to choose whether 0 or 1 should be used as
the base of member indices of arrays. In Python, the same can be used
with strings, lists, tuples etc.

This would mean:
foo = "foo"
=foo[1] == 'f'

foo = ['foo', 'bar', 'spam' ]
=foo[1] == 'foo'

foo = ('spam', 'eggs')
=foo[1] == 'spam'

For convenience it should also affect the range function so that:

range(3) = [1, 2, 3]

because this is often used where arrays would be used in VB.

Finally, when the programmer does not specify his choice of base at
the beginning of the program, the current behaviour of using 0 as base
should continue so that there is no problem with backward
compatibility.

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

sa*****@gmail.com schrieb:

This is like the previous one. Please check for sanity and approve for
posting at python-dev.

This one is not sane. It's not possible to change the indexing of
objects on a per-module basis, as objects may cross module boundaries.

Suppose you have this code:

option base
import sys
print sys.path[1]

So should the be 0-based (because path is in module sys), or should
it be one-based (because the access occurs in a module that uses
1-indexing)?

Regards,
Martin

[jamadagni]

On Apr 14, 4:01 pm, "Martin v. Löwis" <[e-mail]:

This one is not sane. It's not possible to change the indexing of
objects on a per-module basis, as objects may cross module boundaries.

I do not request for this to be changed per-module. Once I say
something like:

from __future__ import indices_start_at_one

afterwards I would expect *any* index from *any* module to start at 1.
To my understanding, Python is going to parse the content of modules
only as and when they are called. So Python is basically reading the
content of those modules when the flag of indices_start_at_one is
active, and hence I would expect it to start counting at 1.

I can envisage, stemming from your comments, that this can lead to
trouble when a module being accessed has hard-coded indices. It would
not be fair of me to expect all module writers to declare the base
option at the head of each file, though it would be good practice. So
the solution is to allow the programmer to choose to limit this tag
locally or activate it globally.

option base 1 local
option base 1 global

[Marc 'BlackJack' Rintsch]

In <11**********************@y80g2000hsf.googlegroups .com>, jamadagni
wrote:

On Apr 14, 4:01 pm, "Martin v. Löwis" <[e-mail]:

>This one is not sane. It's not possible to change the indexing of
objects on a per-module basis, as objects may cross module boundaries.

I do not request for this to be changed per-module. Once I say
something like:

from __future__ import indices_start_at_one

afterwards I would expect *any* index from *any* module to start at 1.
To my understanding, Python is going to parse the content of modules
only as and when they are called.

Modules are parsed when they are imported. And some modules are already
imported before your module is imported because they are built-in or
loaded to be able to import your module in the first place. And what
about modules that are written in C?

Ciao,
Marc 'BlackJack' Rintsch

[jamadagni]

Modules are parsed when they are imported. And some modules are already

imported before your module is imported because they are built-in or
loaded to be able to import your module in the first place. And what
about modules that are written in C?

OK fine. It is clear that this feature must be implemented if at all
only on a per-module basis. So can we have votes for per-module
implementation of this feature?

[ici]

On Apr 14, 1:27 pm, [e-mail] wrote:
....

This would mean:
foo = "foo"
=foo[1] == 'f'

class Str1(str):
def __getitem__(self,i):
return str.__getitem__(self,i-1)

s1 = Str1("foo")
print s1[1]

[Steve Holden]

jamadagni wrote:

>Modules are parsed when they are imported. And some modules are already
imported before your module is imported because they are built-in or
loaded to be able to import your module in the first place. And what
about modules that are written in C?

OK fine. It is clear that this feature must be implemented if at all
only on a per-module basis. So can we have votes for per-module
implementation of this feature?

Like votes would make a difference. Please just accept that this is not
a sensible suggestion and leave it at that.

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Recent Ramblings http://holdenweb.blogspot.com

[Mel Wilson]

jamadagni wrote:

OK fine. It is clear that this feature must be implemented if at all
only on a per-module basis. So can we have votes for per-module
implementation of this feature?

The only way that can work is if the API to the module doesn't expose
ANY sequence indices. It would be a great pain to have to remember
which of the modules you've imported expect base 0 and which expect
base 1. (There's a Monty Python sketch: a station full of police
officers who only understand you if you speak
slowly/quickly/high-pitched/low-pitched/etc. depending on the
individual officer.)

The scheme could work if the module was carefully programmed to show
and accept only application-relevant values that nobody would expect
to have an alternative base -- quantities of things, arbitrary code
numbers, and the like.

Mel.

[faulkner]

On Apr 14, 6:27 am, [e-mail] wrote:

This is like the previous one. Please check for sanity and approve for
posting at python-dev.

I would like to have something like "option base" in Visual Basic.
IIRC it used to allow me to choose whether 0 or 1 should be used as
the base of member indices of arrays. In Python, the same can be used
with strings, lists, tuples etc.

This would mean:
foo = "foo"
=foo[1] == 'f'

foo = ['foo', 'bar', 'spam' ]
=foo[1] == 'foo'

foo = ('spam', 'eggs')
=foo[1] == 'spam'

For convenience it should also affect the range function so that:

range(3) = [1, 2, 3]

because this is often used where arrays would be used in VB.

Finally, when the programmer does not specify his choice of base at
the beginning of the program, the current behaviour of using 0 as base
should continue so that there is no problem with backward
compatibility.

__future__ is used to access upcoming features, and changing the base
offset is not [and never will be] slated for future development. zero
has been used as the base offset in all real languages since the dawn
of time, and isn't something that can be changed without seriously
breaking heads.

i can't believe nobody's posted this yet:
http://www.xkcd.com/c163.html

[Paddy]

On Apr 14, 11:27 am, [e-mail] wrote:

This is like the previous one. Please check for sanity and approve for
posting at python-dev.

I would like to have something like "option base" in Visual Basic.
IIRC it used to allow me to choose whether 0 or 1 should be used as
the base of member indices of arrays. In Python, the same can be used
with strings, lists, tuples etc.

This would mean:
foo = "foo"
=foo[1] == 'f'

foo = ['foo', 'bar', 'spam' ]
=foo[1] == 'foo'

foo = ('spam', 'eggs')
=foo[1] == 'spam'

For convenience it should also affect the range function so that:

range(3) = [1, 2, 3]

because this is often used where arrays would be used in VB.

Finally, when the programmer does not specify his choice of base at
the beginning of the program, the current behaviour of using 0 as base
should continue so that there is no problem with backward
compatibility.

Here is a document giving good reasons for indexing to start at
zero, as in Python.
http://www.cs.utexas.edu/users/EWD/t...xx/EWD831.html
The author has done a bit:
http://en.wikipedia.org/wiki/Dijkstra

Having more than one index start point would be a maintenance
nightmare best avoided. (It can be done in Perl).

- Paddy.

[Sherm Pendley]

"Paddy" <pa*******@googlemail.comwrites:

Having more than one index start point would be a maintenance
nightmare best avoided.

Quite right.

(It can be done in Perl).

When was the last time you used Perl? It was allowed in Perl 4 and earlier,
because many Perl users were moving from Awk, which uses an array base of 1.
Even then, having multiple index start points within a single program wasn't
the idea; the idea was to allow programs originally written in Awk to be
ported to Perl with minimal updating.

It was deprecated as of 5.0 though - which was released in '94. It still
works, for the sake of backwards compatibility, but its use in new code is
highly discouraged.

sherm--

--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net

[John Machin]

On Apr 14, 8:27 pm, [e-mail] wrote:

This is like the previous one. Please check for sanity and approve for
posting at python-dev.

I would like to have something like "option base" in Visual Basic.
IIRC it used to allow me to choose whether 0 or 1 should be used as
the base of member indices of arrays. In Python, the same can be used
with strings, lists, tuples etc.

This would mean:
foo = "foo"
=foo[1] == 'f'

foo = ['foo', 'bar', 'spam' ]
=foo[1] == 'foo'

foo = ('spam', 'eggs')
=foo[1] == 'spam'

For convenience it should also affect the range function so that:

range(3) = [1, 2, 3]

because this is often used where arrays would be used in VB.

Finally, when the programmer does not specify his choice of base at
the beginning of the program, the current behaviour of using 0 as base
should continue so that there is no problem with backward
compatibility.

+1 F***ed Concept of the Year

[Paddy]

On Apr 14, 8:55 pm, Sherm Pendley <[e-mail]:

"Paddy" <[e-mail]:

Having more than one index start point would be a maintenance
nightmare best avoided.

Quite right.

(It can be done in Perl).

When was the last time you used Perl? It was allowed in Perl 4 and earlier,
because many Perl users were moving from Awk, which uses an array base of 1.
Even then, having multiple index start points within a single program wasn't
the idea; the idea was to allow programs originally written in Awk to be
ported to Perl with minimal updating.

It was deprecated as of 5.0 though - which was released in '94. It still
works, for the sake of backwards compatibility, but its use in new code is
highly discouraged.

sherm--

--
Web Hosting by West Virginians, for West Virginians:http://wv-www.net
Cocoa programming in Perl:http://camelbones.sourceforge.net

I use both Perl and Awk regularly. I did at one stage use the Awk-to-
Perl
translator as I learned Awk before Perl, but gave it up as the
generated
Perl was hard to extend, and I learned more Perl.

So Perl had it, and now has it deprecated. Python does not have it,
but
the original poster wants it. I don't think we should add it to Python
because it would make porting VB code easier.

- Paddy.

[Bjoern Schliessmann]

jamadagni wrote:

OK fine. It is clear that this feature must be implemented if at
all only on a per-module basis. So can we have votes for
per-module implementation of this feature?

I don't think it's worth the hassle. BTW, what's, IYHO, the distinct
advantage of starting array indices at 1?

Regards,
Björn

--
BOFH excuse #90:

Budget cuts

[Sherm Pendley]

"Paddy" <pa*******@googlemail.comwrites:

I don't think we should add it to Python
because it would make porting VB code easier.

Great Cthulhu no!

I chimed in because your first comment regarding Perl implied that it's
commonplace for Perl programmers to fiddle with the index base. It can
be done, for historical reasons, but it's far from common.

I have to wonder, if the OP wants VB so badly, why is he using Python to
begin with?

sherm--

--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net

[Terry Reedy]

<sa*****@gmail.comwrote in message
news:11*********************@w1g2000hsg.googlegrou ps.com...
| I would like to have something like "option base" in Visual Basic.
| IIRC it used to allow me to choose whether 0 or 1 should be used as
| the base of member indices of arrays. In Python, the same can be used
| with strings, lists, tuples etc.

If you access a sequence with an iterator, perhaps now the most common
case, the index base becomes an irrelevant internal detail.

If you only access a sequence with explicit indexes, you can treat it as
1-based by ignoring the first element. This has been a standard conversion
technique for a fewdecades.

If you do not like writing range(1,n+1), use def myrange(n): return
range(1,n+1). Interface conversion wrappers are another standard
technique.

Terry Jan Reedy

[Alex Martelli]

faulkner <fa*********@gmail.comwrote:
...

__future__ is used to access upcoming features, and changing the base
offset is not [and never will be] slated for future development. zero
has been used as the base offset in all real languages since the dawn
of time, and isn't something that can be changed without seriously
breaking heads.

While I agree that base-1 indexing in Python would be crazy, I resent
the implication that Fortran isn't "a real language" -- it WAS the first
high level language of any real worth, it survived over 50 years so far,
and its chief developer John Backus, alas recently departed, vastly
deserved his 1977 Turing Award (and not just for his later contributions
in syntax notation [the BNF] and functional programming). "The dawn of
time" for high-level languages was exactly the '50s, when Fortran was
born -- with 1-based array indexing, arguably a minor technical error
(as definitely was the case for the fact that DO-loops always executed
1+ times, never 0 times), but definitely not enough to disqualify it as
"a real language".
Alex

[Alex Martelli]

Sherm Pendley <sp******@dot-app.orgwrote:

"Paddy" <pa*******@googlemail.comwrites:

I don't think we should add it to Python
because it would make porting VB code easier.

Great Cthulhu no!

I chimed in because your first comment regarding Perl implied that it's
commonplace for Perl programmers to fiddle with the index base. It can
be done, for historical reasons, but it's far from common.

Reminds me of APL's worst blunder -- "quadIO" (with IO standing for
Index Origin, NOT Input/Output) could be set to 0 or 1, with global
effect. I worked a lot with APL and mostly loved it (APL2 even more
so), and I'm saddened to read that the ACM wants to disband the APL SIG
for lack of activity (though no doubt it's a reasonable decision, it
badly tickles my nostalgia for years and decades gone) -- but the quadIO
design decision was a truly major design blunder, and made it hell to
integrate APL code from multiple sources.
Alex

[Paddy]

On Apr 15, 2:29 am, [e-mail] (Alex Martelli) wrote:

Sherm Pendley <[e-mail]:

"Paddy" <[e-mail]:

I don't think we should add it to Python
because it would make porting VB code easier.

Great Cthulhu no!

I chimed in because your first comment regarding Perl implied that it's
commonplace for Perl programmers to fiddle with the index base. It can
be done, for historical reasons, but it's far from common.

Reminds me of APL's worst blunder -- "quadIO" (with IO standing for
Index Origin, NOT Input/Output) could be set to 0 or 1, with global
effect. I worked a lot with APL and mostly loved it (APL2 even more
so), and I'm saddened to read that the ACM wants to disband the APL SIG
for lack of activity (though no doubt it's a reasonable decision, it
badly tickles my nostalgia for years and decades gone) -- but the quadIO
design decision was a truly major design blunder, and made it hell to
integrate APL code from multiple sources.

Alex

So the running count is:
Ayes to the left: VB compatibility.
Nays to the right: QuadIO, Perl, Dijkstra paper.

The nays have it!

- Paddy.

[Dan Bishop]

On Apr 14, 10:55 am, Dennis Lee Bieber <[e-mail]:

The FORTRAN family had started as 1-based (F95, and Ada, now allow
for each array to have its own "base" =x : array (-10..10) of float).
Pascal, I forget...

Pascal allows arbitrary array bases. It's where Ada got the idea.

[Steven D'Aprano]

On Sat, 14 Apr 2007 20:34:46 -0700, Dan Bishop wrote:

On Apr 14, 10:55 am, Dennis Lee Bieber <[e-mail]:

> The FORTRAN family had started as 1-based (F95, and Ada, now allow
for each array to have its own "base" =x : array (-10..10) of float).
Pascal, I forget...

Pascal allows arbitrary array bases. It's where Ada got the idea.

It does? Since when?

When I was being taught Pascal at University (20 years ago...) Pascal
always started indices at 1. We used to joke you could tell musicians who
were trained as C programmers from those who were Pascal programmers
because they did sound checks "Testing, 0 1 2".
--
Steven.

[Alex Martelli]

Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrote:

On Sat, 14 Apr 2007 20:34:46 -0700, Dan Bishop wrote:

On Apr 14, 10:55 am, Dennis Lee Bieber <[e-mail]:

The FORTRAN family had started as 1-based (F95, and Ada, now allow
for each array to have its own "base" =x : array (-10..10) of float).
Pascal, I forget...

Pascal allows arbitrary array bases. It's where Ada got the idea.

It does? Since when?

Ever since Pascal existed, the syntax has been "array[lower..upper] of
sometype" -- no default value for lower (neither 0 nor 1 nor other).
Alex

[Steven D'Aprano]

On Sat, 14 Apr 2007 22:02:47 -0700, Alex Martelli wrote:

Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrote:

>On Sat, 14 Apr 2007 20:34:46 -0700, Dan Bishop wrote:

On Apr 14, 10:55 am, Dennis Lee Bieber <[e-mail]:

The FORTRAN family had started as 1-based (F95, and Ada, now allow
for each array to have its own "base" =x : array (-10..10) of float).
Pascal, I forget...

Pascal allows arbitrary array bases. It's where Ada got the idea.

It does? Since when?

Ever since Pascal existed, the syntax has been "array[lower..upper] of
sometype" -- no default value for lower (neither 0 nor 1 nor other).

*slaps head*

Of course it does! D'oh!

We always used to write array[1..n] for an n item array, which is a
convention, not enforced by the compiler.

--
Steve

[Nick Craig-Wood]

Sherm Pendley <sp******@dot-app.orgwrote:

"Paddy" <pa*******@googlemail.comwrites:

Having more than one index start point would be a maintenance
nightmare best avoided.

Quite right.

(It can be done in Perl).

When was the last time you used Perl? It was allowed in Perl 4 and earlier,
because many Perl users were moving from Awk, which uses an array base of 1.
Even then, having multiple index start points within a single program wasn't
the idea; the idea was to allow programs originally written in Awk to be
ported to Perl with minimal updating.

It was deprecated as of 5.0 though - which was released in '94. It still
works, for the sake of backwards compatibility, but its use in new code is
highly discouraged.

I seem to remember from "Programming Perl" that Larry Wall said it was
a serious mistake to add this feature to perl.

If it is a feature too far for perl then it is *definitely* a feature
too far for python ;-)

--
Nick Craig-Wood <ni**@craig-wood.com-- http://www.craig-wood.com/nick

[Javier Bezos]

Here is a document giving good reasons for indexing to start at
zero, as in Python.
http://www.cs.utexas.edu/users/EWD/t...xx/EWD831.html
The author has done a bit:
http://en.wikipedia.org/wiki/Dijkstra

Dijkstra's argument is obsolete, as it is based on
how array length was computed many years ago -- if
we have an array a = b..e, then the lenght of a
is e-b (half open range). Good at low level
programming.

But a quarter of a century after we know concepts
are much better than low level programming and
explicit computations -- if we have an array
a = b..e, then the length of a should be a.length()
(or a.length(b,e)), and it is independent of
arbitrary ranges, index bases, or even steps
(eg, {-4, -2, 0, 2, 4}).

Of course, the index base should be always the
same _by default_ (individual lists could require
another index base, and that's fine). Otherwise
it would a mess, as you said.

Javier
-----------------------------
http://www.texytipografia.com

[Paddy]

On Apr 15, 6:42 pm, "Javier Bezos" <[e-mail]:

Here is a document giving good reasons for indexing to start at
zero, as in Python.
http://www.cs.utexas.edu/users/EWD/t...xx/EWD831.html
The author has done a bit:
http://en.wikipedia.org/wiki/Dijkstra

Dijkstra's argument is obsolete, as it is based on
how array length was computed many years ago -- if
we have an array a = b..e, then the lenght of a
is e-b (half open range). Good at low level
programming.

But a quarter of a century after we know concepts
are much better than low level programming and
explicit computations -- if we have an array
a = b..e, then the length of a should be a.length()
(or a.length(b,e)), and it is independent of
arbitrary ranges, index bases, or even steps
(eg, {-4, -2, 0, 2, 4}).

Of course, the index base should be always the
same _by default_ (individual lists could require
another index base, and that's fine). Otherwise
it would a mess, as you said.

Javier
-----------------------------http://www.texytipografia.com

Hi Javier,
You seem to have missed out array *indexing*
in your argument, or is array indexing obsolete?

- Paddy.

[Beliavsky]

On Apr 14, 10:55 am, Dennis Lee Bieber <[e-mail]:

<snip>

The FORTRAN family had started as 1-based (F95, and Ada, now allow
for each array to have its own "base" =x : array (-10..10) of float).

Fortran has allowed a user-specified base since at least the 1977
standard -- see for example http://www.umiacs.umd.edu/~jhu/DOCS/...l/essl159.html
..

[Beliavsky]

On Apr 14, 10:12 pm, "Paddy" <[e-mail]:

<snip>

So the running count is:
Ayes to the left: VB compatibility.
Nays to the right: QuadIO, Perl, Dijkstra paper.

The nays have it!

One-based indexing would also Python more compatible with Fortran,
Matlab/Octave/Scilab, and S (the language of S-Plus and R). It appears
that engineers, scientists, and statisticians, as opposed to
professional programmers, like 1-based indexing. An obvious argument
for 1-based indexing in the FORmula TRANslation programming language
is that formulas involving arrays in textbooks almost always use 1-
based indexing.

Since Python has always had 0-based indexing and since a user-defined
base can cause problems, as has been discussed, I think Python and
extensions such as NumPy should be left as is.

[Dan Bishop]

On Apr 15, 6:06 pm, "Beliavsky" <[e-mail]:

On Apr 14, 10:12 pm, "Paddy" <[e-mail]:

<snip>

So the running count is:
Ayes to the left: VB compatibility.
Nays to the right: QuadIO, Perl, Dijkstra paper.

The nays have it!

One-based indexing would also Python more compatible with Fortran,
Matlab/Octave/Scilab, and S (the language of S-Plus and R). It appears
that engineers, scientists, and statisticians, as opposed to
professional programmers, like 1-based indexing. An obvious argument
for 1-based indexing in the FORmula TRANslation programming language
is that formulas involving arrays in textbooks almost always use 1-
based indexing.

I've seen plenty of examples of zero-based indexing in math
textbooks. For example, the coefficients of polynomials and Fourier
cosine series, both of which use a zero subscript for the constant
term.

[Javier Bezos]

Paddy,

>Dijkstra's argument is obsolete, as it is based on
how array length was computed many years ago -- if
we have an array a = b..e, then the lenght of a
is e-b (half open range). Good at low level
programming.

But a quarter of a century after we know concepts
are much better than low level programming and
explicit computations -- if we have an array
a = b..e, then the length of a should be a.length()
(or a.length(b,e)), and it is independent of

Hi Javier,
You seem to have missed out array *indexing*
in your argument, or is array indexing obsolete?

Of course, it isn't, but it has evolved over the
past 25 years. When Djikstra wrote that, many
people (including me) was using a Spectrum---
Now we have OO programming to deal with concepts
and a more generic programming. So, to me it's
clear his _argument_ is very outdated and cannot
be applied directly and withot reservations to
modern languages like Python.

Javier
-----------------------------
http://www.texytipografia.com

[Tim Roberts]

"Beliavsky" <be*******@aol.comwrote:

>
Fortran has allowed a user-specified base since at least the 1977
standard -- see for example http://www.umiacs.umd.edu/~jhu/DOCS/...l/essl159.html
.

You can strike "at least"; this extension was introduced in FORTRAN 77.
FORTRAN 66 didn't do this.
--
Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.

[Dustan]

On Apr 14, 4:06 pm, Bjoern Schliessmann <usenet-
[e-mail]:

jamadagni wrote:

OK fine. It is clear that this feature must be implemented if at
all only on a per-module basis. So can we have votes for
per-module implementation of this feature?

I don't think it's worth the hassle. BTW, what's, IYHO, the distinct
advantage of starting array indices at 1?

For newbies, it's easier to count starting with 1. It's rather
unintuitive to start at 0.

That's not to say that I support this feature request; I got used to
counting from 0. It just took me some time.

Regards,

Björn

--
BOFH excuse #90:

Budget cuts

[Zara]

On Mon, 16 Apr 2007 10:15:19 +0200, "Javier Bezos"
<se***************@yahoo.eswrote:

>Paddy,

>>Dijkstra's argument is obsolete, as it is based on
how array length was computed many years ago -- if
we have an array a = b..e, then the lenght of a
is e-b (half open range). Good at low level
programming.

But a quarter of a century after we know concepts
are much better than low level programming and
explicit computations -- if we have an array
a = b..e, then the length of a should be a.length()
(or a.length(b,e)), and it is independent of

>Hi Javier,
You seem to have missed out array *indexing*
in your argument, or is array indexing obsolete?

Of course, it isn't, but it has evolved over the
past 25 years. When Djikstra wrote that, many
people (including me) was using a Spectrum---
Now we have OO programming to deal with concepts
and a more generic programming. So, to me it's
clear his _argument_ is very outdated and cannot
be applied directly and withot reservations to
modern languages like Python.

One language created by and for mathematicians: Haskell.
It uses zero based list indexing (the most similar to array indexing
they have), so that list!!0 is the first element and list!!3 the
fourth element.

And they tend to reason in Dijkstra's style. They love natural numbers
beginning with zer:

zara

[Antoon Pardon]

On 2007-04-14, Paddy <pa*******@googlemail.comwrote:

On Apr 14, 11:27 am, [e-mail] wrote:

>This is like the previous one. Please check for sanity and approve for
posting at python-dev.

I would like to have something like "option base" in Visual Basic.
IIRC it used to allow me to choose whether 0 or 1 should be used as
the base of member indices of arrays. In Python, the same can be used
with strings, lists, tuples etc.

This would mean:
foo = "foo"
=foo[1] == 'f'

foo = ['foo', 'bar', 'spam' ]
=foo[1] == 'foo'

foo = ('spam', 'eggs')
=foo[1] == 'spam'

For convenience it should also affect the range function so that:

range(3) = [1, 2, 3]

because this is often used where arrays would be used in VB.

Finally, when the programmer does not specify his choice of base at
the beginning of the program, the current behaviour of using 0 as base
should continue so that there is no problem with backward
compatibility.

Here is a document giving good reasons for indexing to start at
zero, as in Python.

I find he just picks the reasons he agrees with.

If you pick your values as a <= i <= b it has the advantage that
the bounds are explicit. No need to add or substract 1 from
one of the values to get the exact boundis. Now how much weight
you want to give this characteristic is open for debate but
the fact that it isn't even mentioned doesn't give me much
confidence in the author's ability to weight all the pro's
and con's.

http://www.cs.utexas.edu/users/EWD/t...xx/EWD831.html
The author has done a bit:
http://en.wikipedia.org/wiki/Dijkstra

Having more than one index start point would be a maintenance
nightmare best avoided. (It can be done in Perl).

It was never a problem when I still programmed in Pascal.

--
Antoon Pardon

[Bjoern Schliessmann]

Dustan wrote:

For newbies, it's easier to count starting with 1. It's rather
unintuitive to start at 0.

Cool. So Python will become a "newbie language", and everyone
that "jumps" from Python to a different language will have to
relearn 0-based indices? ;)

Regards,
Björn

--
BOFH excuse #418:

Sysadmins busy fighting SPAM.