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?=]

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]

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]

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 address removed) 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]

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

 

[Mel Wilson]

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.

 

[Dennis Lee Bieber]

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?

And if it is per-module, how do you handle cross-module access --
does every access have to now do some module properties lookup to
convert access? Sounds like a lot of overhead...

import b_1_based
b_1_based.lst[2] = 3

has to now do something like: subtract current module base from
index, look up b_1_based module base, add this to index...

Or do you mean that INSIDE b_1_based, lst[2] will be the second
item, but from OUTSIDE (as above example) lst[2] might be the third
element (if outside is a 0-based module)?

Hint: even classical BASIC was a 0-based language...

DIM A(10)

allocated ELEVEN cells; but most learners never knew that A(0) was a
valid reference, and used just A(1)..A(10).

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... C and related are 0-based, as that makes the
executable code efficient...

item-location = array-start + (index * item-size)

1-based access has to add a subtraction:

item-location = array-start + ((index - 1) * item-size)
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[faulkner]

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]

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/transcriptions/EWD08xx/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]

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--

 

[John Machin]

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]

Quite right.


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--

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]

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

 

[Sherm Pendley]

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--

 

[Terry Reedy]

| 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]

__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]

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]

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.