Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #95887 > unrolled thread

Re: Python handles globals badly.

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Python handles globals badly. tdev@freenet.de - 2015-09-02 11:47 -0700
    Re: Python handles globals badly. tdev@freenet.de - 2015-09-02 12:32 -0700
    Re: Python handles globals badly. Emile van Sebille <emile@fenx.com> - 2015-09-02 12:34 -0700
    Re: Python handles globals badly. Ian Kelly <ian.g.kelly@gmail.com> - 2015-09-02 13:38 -0600
    Re: Python handles globals badly. "Sven R. Kunze" <srkunze@mail.de> - 2015-09-02 22:08 +0200
    Re: Python handles globals badly. MRAB <python@mrabarnett.plus.com> - 2015-09-02 21:22 +0100
    Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-02 22:19 +0100
    Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-03 02:16 +0100
    Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-03 11:49 +1000
    Re: Python handles globals badly. Vladimir Ignatov <kmisoft@gmail.com> - 2015-09-04 20:05 -0400
    Re: Python handles globals badly. Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-09-08 10:40 +0200
    Re: Python handles globals badly. Vladimir Ignatov <kmisoft@gmail.com> - 2015-09-08 07:55 -0400
    Re: Python handles globals badly. Akira Li <4kir4.1i@gmail.com> - 2015-09-08 15:35 +0300
    Re: Python handles globals badly. Mario Figueiredo <marfig@gmx.com> - 2015-09-08 14:05 +0100
    Re: Python handles globals badly. Ian Kelly <ian.g.kelly@gmail.com> - 2015-09-08 08:31 -0600
      Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-09 01:56 +1000
        Re: Python handles globals badly. Michael Torrie <torriem@gmail.com> - 2015-09-08 17:55 -0600
          Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-09 13:23 +1000
            Re: Python handles globals badly. Christian Gollwitzer <auriocus@gmx.de> - 2015-09-09 18:09 +0200
              Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-10 03:22 +1000
                Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-10 03:27 +1000
                Re: Python handles globals badly. William Ray Wing <wrw@mac.com> - 2015-09-09 13:59 -0400
                Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-09 20:20 +0100
                  Re: Python handles globals badly. Peter Pearson <pkpearson@nowhere.invalid> - 2015-09-10 20:49 +0000
                Re: Python handles globals badly. MRAB <python@mrabarnett.plus.com> - 2015-09-09 20:22 +0100
                Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-10 05:27 +1000
        Re: Python handles globals badly. Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-09-09 12:42 +0200
        Re: Python handles globals badly. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-09-09 09:33 -0400
    Re: Python handles globals badly. random832@fastmail.us - 2015-09-08 12:13 -0400
    Re: Python handles globals badly. MRAB <python@mrabarnett.plus.com> - 2015-09-08 18:41 +0100
    Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-08 23:41 +0100
    Re: Python handles globals badly. MRAB <python@mrabarnett.plus.com> - 2015-09-09 00:20 +0100
    Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-09 00:32 +0100
    Re: Python handles globals badly. Random832 <random832@fastmail.com> - 2015-09-08 20:02 -0400
      Re: Python handles globals badly. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-09-11 10:23 +0200
    Re: Python handles globals badly. Mario Figueiredo <marfig@gmx.com> - 2015-09-09 02:09 +0100
      Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-10 03:55 +1000
        Re: Python handles globals badly. Laura Creighton <lac@openend.se> - 2015-09-09 20:05 +0200
        Re: Python handles globals badly. Emile van Sebille <emile@fenx.com> - 2015-09-09 11:23 -0700
          Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-10 22:20 +1000
        Re: Python handles globals badly. "Sven R. Kunze" <srkunze@mail.de> - 2015-09-09 20:26 +0200
          Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-11 01:50 +1000
        Re: Python handles globals badly. random832@fastmail.us - 2015-09-09 14:59 -0400
          Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-11 01:59 +1000
            Re: Python handles globals badly. random832@fastmail.us - 2015-09-10 12:31 -0400
              Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-11 04:13 +1000
                Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-11 04:33 +1000
                Re: Python handles globals badly. Jussi Piitulainen <harvesting@makes.email.invalid> - 2015-09-10 22:11 +0300
                Re: Python handles globals badly. random832@fastmail.us - 2015-09-10 16:30 -0400
            Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-11 02:48 +1000
            Re: Python handles globals badly. alister <alister.nospam.ware@ntlworld.com> - 2015-09-10 19:56 +0000
            Re: Python handles globals badly. random832@fastmail.us - 2015-09-10 16:07 -0400
            Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-11 11:35 +1000
            Re: Python handles globals badly. Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-09-11 12:19 +0200
              Re: Python handles globals badly. Marko Rauhamaa <marko@pacujo.net> - 2015-09-11 14:59 +0300
                Re: Python handles globals badly. Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-09-14 09:13 +0200
        Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-10 05:00 +1000
        Re: Python handles globals badly. Laura Creighton <lac@openend.se> - 2015-09-09 21:14 +0200
        Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-10 05:18 +1000
          Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-10 22:18 +1000
            Re: Python handles globals badly. jkn <jkn_gg@nicorp.f9.co.uk> - 2015-09-10 08:09 -0700
            Re: Python handles globals badly. rurpy@yahoo.com - 2015-09-10 12:04 -0700
              Re: Python handles globals badly. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-09-10 20:33 -0400
              Re: Python handles globals badly. Gene Heskett <gheskett@wdtv.com> - 2015-09-10 22:19 -0400
              Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-12 03:35 +0100
              Re: Python handles globals badly. Mario Figueiredo <marfig@gmx.com> - 2015-09-12 05:11 +0100
              Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-12 05:38 +0100
              Re: Python handles globals badly. Mario Figueiredo <marfig@gmx.com> - 2015-09-12 16:52 +0100
              Re: Python handles globals badly. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-09-12 12:24 -0400
              Re: Python handles globals badly. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-09-12 12:29 -0400
              Re: Python handles globals badly. MRAB <python@mrabarnett.plus.com> - 2015-09-12 18:09 +0100
              Re: Python handles globals badly. Mario Figueiredo <marfig@gmx.com> - 2015-09-12 22:57 +0100
              Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-12 23:05 +0100
              Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-12 23:07 +0100
        Re: Python handles globals badly. "Sven R. Kunze" <srkunze@mail.de> - 2015-09-09 21:21 +0200
        Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-09 20:24 +0100
        Re: Python handles globals badly. Mario Figueiredo <marfig@gmx.com> - 2015-09-09 20:57 +0100
        Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-09 21:15 +0100
        Re: Python handles globals badly. Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-09-10 09:27 +0200
          Re: Python handles globals badly. Marko Rauhamaa <marko@pacujo.net> - 2015-09-10 10:49 +0300
        Re: Python handles globals badly. Michael Torrie <torriem@gmail.com> - 2015-09-10 08:21 -0600
        Re: Python handles globals badly. Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-09-11 09:28 +0200
          Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-12 13:48 +1000
            Re: Python handles globals badly. Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-09-14 10:30 +0200
              Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-16 11:13 +1000
                Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-16 11:20 +1000
                  Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-16 11:58 +1000
                Re: Python handles globals badly. Random832 <random832@fastmail.com> - 2015-09-15 21:54 -0400
                Re: Python handles globals badly. Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-09-16 10:51 +0200
        Re: Python handles globals badly. random832@fastmail.us - 2015-09-11 08:50 -0400
    Re: Python handles globals badly. Ben Finney <ben+python@benfinney.id.au> - 2015-09-09 11:26 +1000
    Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-09 11:41 +1000
    Re: Python handles globals badly. Mario Figueiredo <marfig@gmx.com> - 2015-09-09 03:43 +0100
    Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-09 13:03 +1000
    Re: Python handles globals badly. Ben Finney <ben+python@benfinney.id.au> - 2015-09-09 15:53 +1000

Page 1 of 5  [1] 2 3 4 5  Next page →

#95887 — Re: Python handles globals badly.

I agree with Skybuck Flying. 
I am aware if a var is a module function var or a module global var.
If I want read or write a global var.

Using the keyword global inside each(!) function only 
to mark the global var writeable in each of the functions
is really an over-regulation and very annoying from my point of view.

Especially cause a module is a singleton.
And globals are only module aware vars.
Even Java (type-safe language) need not such things for its static or member vars.
I have disliked this already in PHP where one has to do
exact the same thing as in Python (and hoped Python does it better, but not).
And using an import here is no solution, cause this is
something which relates only to the scope and state of a module itself. 

I therefore would like to see a PEP which allows also writing 
global module vars inside module functions without the need 
for explicit setting the keyword "global" in more or less each(!) 
module function as the first line of code.


I hope a lot can/will agree and a new PEP will arise
to give this small responsibility back to the developer.


Thanks.

[toc] | [next] | [standalone]

#95889

And to clarify:  I have not spoken about sharing constants global (spanning over modules), where the solution provided here using imports is the solution. I have spoken from module vars which are named or are "globals" and its read/write access constraints inside module functions.  So even the naming "globals" is something what I dislike, cause it is about module scope. With all other I can agree with Skybuck Flying too: "There is so far nothing else annoying!" (Maybe a missing switch statement).  Thanks.

[toc] | [prev] | [next] | [standalone]

#95890

On 9/2/2015 11:47 AM, tdev@freenet.de wrote:
<snip>
> I therefore would like to see a PEP which allows also writing
> global module vars inside module functions without the need
> for explicit setting the keyword "global" in more or less each(!)
> module function as the first line of code.

If you're feeling like you need to add global statements to a lot of 
functions to enable variable sharing/access, it may be codesmell 
indicating it's time to make a class of things.

Emile

[toc] | [prev] | [next] | [standalone]

#95891

On Wed, Sep 2, 2015 at 12:47 PM,  <tdev@freenet.de> wrote:
> Using the keyword global inside each(!) function only
> to mark the global var writeable in each of the functions
> is really an over-regulation and very annoying from my point of view.

To me, marking a variable as global in a large number of functions is
a code smell that indicates that you're probably overusing globals.
Lua is an example of a language that takes the opposite approach: in
Lua, every variable is global unless you explicitly mark it as local.
Lua is a fine language overall, but that is one of my pet peeves with
it as it is all too easy to fall into the trap of neglecting to mark
your local variables, and then you end up with too many global
variables and a disaster of a code base.

> Especially cause a module is a singleton.
> And globals are only module aware vars.
> Even Java (type-safe language) need not such things for its static or member vars.

Because Java has static typing. It can determine that a variable is
static simply by observing that the variable is declared as such in
the class and isn't declared in the function.

Would you prefer to have to declare all your local variables as
"local" just so that you don't have to explicitly declare the (few, I
hope) global ones?

[toc] | [prev] | [next] | [standalone]

#95892

On 02.09.2015 20:47, tdev@freenet.de wrote:
> I agree with Skybuck Flying.
> I am aware if a var is a module function var or a module global var.
> If I want read or write a global var.
>
> Using the keyword global inside each(!) function only
> to mark the global var writeable in each of the functions
> is really an over-regulation and very annoying from my point of view.

It reflects the collective experience of programmers, computer 
scientists, and so forth of the last decades.


Globals are evil. Stay away from them.


Best,
Sven

[toc] | [prev] | [next] | [standalone]

#95895

On 2015-09-02 21:08, Sven R. Kunze wrote:
> On 02.09.2015 20:47, tdev@freenet.de wrote:
>> I agree with Skybuck Flying.
>> I am aware if a var is a module function var or a module global var.
>> If I want read or write a global var.
>>
>> Using the keyword global inside each(!) function only
>> to mark the global var writeable in each of the functions
>> is really an over-regulation and very annoying from my point of view.
>
> It reflects the collective experience of programmers, computer
> scientists, and so forth of the last decades.
>
>
> Globals are evil. Stay away from them.
>
I think it's like that sometimes-misquoted saying "money is the root of 
all evil".

It's "the love of money is the root of all evil".

Similarly, it's the love (or misuse or overuse) of globals that's evil,
IMHO.

[toc] | [prev] | [next] | [standalone]

#95897

On 02/09/2015 19:47, tdev@freenet.de wrote:
> I agree with Skybuck Flying.

First problem.

> Using the keyword global inside each(!) function only
> to mark the global var writeable in each of the functions
> is really an over-regulation and very annoying from my point of view.
>

Second problem.  Any chance of shooting yourself *BEFORE* your code 
escapes from the laboratory?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#95910

On 02/09/2015 19:47, tdev@freenet.de wrote:
> Even Java (type-safe language) need not such things for its static or member vars.

By this comment are you stating that Python is not type safe?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#95916

On Thu, 3 Sep 2015 04:47 am, tdev@freenet.de wrote:

> I agree with Skybuck Flying.
> I am aware if a var is a module function var or a module global var.

Congratulations!

But you're not the Python compiler, which doesn't have your superior insight
and intuition.

Inside a function, how is the compiler supposed to know whether "x = 1"
refers to a global or local?

If you can explain that, then your proposal has the tiniest chance of
success. Without that explanation, it has no hope at all.


[...]
> Especially cause a module is a singleton.

What does that have to do with anything?


> And globals are only module aware vars.

What does that even mean?


> Even Java (type-safe language) need not such things for its static or
> member vars. 

Java has different rules for variables -- all variables are statically
defined in Java and known to the compiler, that is not the case with
dynamic languages like Lua, Python, Javascript, PHP.

You can't do this in Java:

name = random.choice(["foo", "bar", "baz"])
exec ("%s = 42" % name+"abc", globals())
globals()[name.upper()] = 999

So tell me, what global variables do you have now?


> I have disliked this already in PHP where one has to do 
> exact the same thing as in Python (and hoped Python does it better, but
> not). And using an import here is no solution, cause this is
> something which relates only to the scope and state of a module itself.

Again, I don't understand what your comment even means.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#96034

> To me, marking a variable as global in a large number of functions is
> a code smell that indicates that you're probably overusing globals.
> Lua is an example of a language that takes the opposite approach: in
> Lua, every variable is global unless you explicitly mark it as local.
> Lua is a fine language overall, but that is one of my pet peeves with

I had some experience programming in Lua and I'd say - that language
is bad example to follow.
Indexes start with 1  (I am not kidding)
Single data type ("table") which could suddenly flip from "list" to
"map" because you deleted one item.
Has objects but has no classes.
and so on...

Vladimir

http://itunes.apple.com/us/app/python-code-samples/id1025613117

[toc] | [prev] | [next] | [standalone]

#96105

Op 05-09-15 om 02:05 schreef Vladimir Ignatov:
>> To me, marking a variable as global in a large number of functions is
>> a code smell that indicates that you're probably overusing globals.
>> Lua is an example of a language that takes the opposite approach: in
>> Lua, every variable is global unless you explicitly mark it as local.
>> Lua is a fine language overall, but that is one of my pet peeves with
> I had some experience programming in Lua and I'd say - that language
> is bad example to follow.
> Indexes start with 1  (I am not kidding)

What is so bad about that?

[toc] | [prev] | [next] | [standalone]

#96123

>> I had some experience programming in Lua and I'd say - that language
>> is bad example to follow.
>> Indexes start with 1  (I am not kidding)
>
> What is so bad about that?

It's different from the rest 99.9% of languages for no particular reason.

( => perfect example of "design smell" => not a good example to follow)


Vladimir

http://itunes.apple.com/us/app/python-code-samples/id1025613117

[toc] | [prev] | [next] | [standalone]

#96126

Vladimir Ignatov <kmisoft@gmail.com> writes:

>>> I had some experience programming in Lua and I'd say - that language
>>> is bad example to follow.
>>> Indexes start with 1  (I am not kidding)
>>
>> What is so bad about that?
>
> It's different from the rest 99.9% of languages for no particular reason.
>
> ( => perfect example of "design smell" => not a good example to follow)
>

It is not just a matter of tradition. Even if you were to invent the
very first programming language; there are reasons to prefer the
zero-based indexing. See "Why numbering should start at zero"
https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html

[toc] | [prev] | [next] | [standalone]

#96127

On 08-09-2015 12:55, Vladimir Ignatov wrote:
>>> I had some experience programming in Lua and I'd say - that language
>>> is bad example to follow.
>>> Indexes start with 1  (I am not kidding)
>>
>> What is so bad about that?
>
> It's different from the rest 99.9% of languages for no particular reason.
>
> ( => perfect example of "design smell" => not a good example to follow)
>

Assuming that some programming language makes design choices "for no 
apparent reason" is your first hint you should probably reevaluate your 
position. People who design programming languages don't tend to throw 
coins to the air.

Lua was based of a scientific language with a strong mathematical core, 
where 1-index arrays make more sense and are standard. The authors 
didn't expect for the language to become successful and by the time it 
did, you couldn't just change anymore such a core aspect of your language.

1-index arrays tend to be a problem in Lua, only for those people that 
don't normally program in Lua. Those that do, quickly learn to use them 
and they are not more difficult or easy to use than 0-index arrays. 
There is nothing inherently bad about 1-index arrays. They are just 
different, with some of the disadvantages being balanced by some of its 
advantages.

And there either no design smell here. From the perspective of the 
language user (the programmer), the choice of the starting index of an 
array should have no impact on their ability to code. It's just another 
semantic aspect of the language they should learn. No different than 
having to learn other semantic nuances of each particular language. In 
fact, a great language is the one that offers the ability for the user 
to decide what starting index they want to use. Depending on the data 
structure a user sometimes is better served by a 0-index array, others 
by a 1-index array, and if you are doing an array with the letters of 
the alphabet you would love to have an array starting at 'a'.

[toc] | [prev] | [next] | [standalone]

#96131

On Tue, Sep 8, 2015 at 5:55 AM, Vladimir Ignatov <kmisoft@gmail.com> wrote:
>>> I had some experience programming in Lua and I'd say - that language
>>> is bad example to follow.
>>> Indexes start with 1  (I am not kidding)
>>
>> What is so bad about that?
>
> It's different from the rest 99.9% of languages for no particular reason.

It's not "different from the rest 99.9% of languages". There are many
languages that use 1-based indexing, e.g. Matlab, Pascal, Fortran.

None of those are even the worst offender here, IMO. That honor goes
to Visual Basic 6, where the default lower bound is 0, but the
programmer has the option of declaring an array to use any lower bound
they want, or even globally change the default. As a result you have
to look up the array declaration to know the lower bound, and even
then you can't be sure if it's not explicit. The correct way to
iterate over a loop in VB 6 is thus not "FOR i = 0 TO n-1", but "FOR i
= LBound(arr) TO UBound(arr)" which is overly verbose and means that
you can't even be sure what indexes you're actually iterating over
inside the loop.

I believe this wart is fixed in VB .NET.

[toc] | [prev] | [next] | [standalone]

#96135

On Wed, 9 Sep 2015 12:31 am, Ian Kelly wrote:

> On Tue, Sep 8, 2015 at 5:55 AM, Vladimir Ignatov <kmisoft@gmail.com>
> wrote:
>>>> I had some experience programming in Lua and I'd say - that language
>>>> is bad example to follow.
>>>> Indexes start with 1  (I am not kidding)
>>>
>>> What is so bad about that?
>>
>> It's different from the rest 99.9% of languages for no particular reason.
> 
> It's not "different from the rest 99.9% of languages". There are many
> languages that use 1-based indexing, e.g. Matlab, Pascal, Fortran.

Correct. Nearly all natural languages start counting at 1, not 0, as do
quite a few programming languages, such as PL/I, Algol60 and others. You'll
note that languages that are designed for mathematics (Matlab, Mathematica,
Julia) tend to use 1-based indexes. This is not an accident.

Guido discusses why he choose 0-based indexing like in C, instead of 1-based
indexing like in ABC:

http://python-history.blogspot.com.au/2013/10/why-python-uses-0-based-indexing.html

He links to this fantastic discussion of why C ended up with 0-based
indexing:

http://exple.tive.org/blarg/2013/10/22/citation-needed/

It's a wonderful read.

See also:

http://c2.com/cgi/wiki?WhyNumberingShouldStartAtOne
http://c2.com/cgi/wiki?WhyNumberingShouldStartAtZero

Anyone who thinks that there is one right answer here simply isn't paying
attention.


> None of those are even the worst offender here, IMO. That honor goes
> to Visual Basic 6, where the default lower bound is 0, but the
> programmer has the option of declaring an array to use any lower bound
> they want, or even globally change the default. 

I'll just point out that some algorithms are best written with 0-based
arrays, and some are best with 1-based arrays. I shouldn't have to change
languages to change from one to the other!



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#96151

On 09/08/2015 09:56 AM, Steven D'Aprano wrote:
> http://exple.tive.org/blarg/2013/10/22/citation-needed/
> 
> It's a wonderful read.

I read this article, but I'm still uncertain to what his point actually
is.  It's a great review of the history of C, some batch computing, and
IBM's CEO's penchant for boat racing.  He tries to say that 0-based
indexing made for faster compiling, but given the runtime nature of
BCPL's ! operator, I don't see how it wouldn't affect runtime also.  He
also says that saying pointers are the reason for 0-based indexing then
you're wrong, except that BCPL's creator says in this same article that
array variables are essentially pointers.  A few people tried to point
this out in the comments but the author simply lambasted them, saying
thinks like, "Thanks for leaving a comment. I'm sure it's made you feel
clever."  Like I say I guess I must have missed his point in there
somewhere.  I suppose his point is C is 0-based because BCPL was, and
I'm sure that's true, but I'm also sure K&R saw some benefits to keeping
this in C.

In any case, 0-based indexing in Python makes a lot of sense when you
bring in the slicing syntax. Especially if you think of slicing as
operating on the boundaries between cells as it were.

I used a 1-based indexed language (BASIC) for many years, and I was
always having to subtract 1 from things.  So 0-based is simply more
convenient for me.

[toc] | [prev] | [next] | [standalone]

#96158

On Wed, 9 Sep 2015 09:55 am, Michael Torrie wrote:

> On 09/08/2015 09:56 AM, Steven D'Aprano wrote:
>> http://exple.tive.org/blarg/2013/10/22/citation-needed/
>> 
>> It's a wonderful read.
> 
> I read this article, but I'm still uncertain to what his point actually
> is.  It's a great review of the history of C, some batch computing, and
> IBM's CEO's penchant for boat racing.  He tries to say that 0-based
> indexing made for faster compiling, but given the runtime nature of
> BCPL's ! operator, I don't see how it wouldn't affect runtime also.  He
> also says that saying pointers are the reason for 0-based indexing then
> you're wrong, except that BCPL's creator says in this same article that
> array variables are essentially pointers.

You know about the boat races, so you obviously read the article... so how
did you miss the part where the author explicitly raises the exact
objection you do?

   [quote]
   “Now just a second, Hoye”, I can hear you muttering. “I’ve looked at
   the BCPL manual and read Dr. Richards’ explanation and you’re not 
   fooling anyone. That looks a lot like the efficient-pointer-arithmetic
   argument you were frothing about, except with exclamation points.” 
   And you’d be very close to right. That’s exactly what it is – the
   distinction is where those efficiencies take place, and why.
   [end quote]


> A few people tried to point 
> this out in the comments but the author simply lambasted them, saying
> thinks like, "Thanks for leaving a comment. I'm sure it's made you feel
> clever."  

If people raise an objection that is already raised and covered in the text,
I'd be a tad snarky too. Like the guy who objects, tells the author he
ought to read Dijkstra, and *utterly failed* to notice that the article
links to the same paper.

Or the guy who somehow decided that the length of a 1-based array wasn't
end-start, but "there’s always a +1 or -1 to be strewn in there". O rly?

0-based indexes: [0|1|2|3|4], end-start = 4-0 = 4
1-based indexes: [1|2|3|4|5], end-start = 5-1 = 4

And yes, the fellow Joe who completely missed the point of the blog post,
and made the comment "You don’t think you’re wrong and that’s part of a
much larger problem, but you’re still wrong" completely deserved to be
called out on his lack of reading comprehension and smugness.


> Like I say I guess I must have missed his point in there 
> somewhere.  I suppose his point is C is 0-based because BCPL was, and
> I'm sure that's true, but I'm also sure K&R saw some benefits to keeping
> this in C.

The post has *nothing* to do with why languages today might use 0-based
arrays. It's not a post about which is better, or an attack on 0-based
languages. It's about the historical forces that lead to design decisions
being made, and how computer science is almost completely blind to those
forces. Lacking real insight into why decisions are made, the IT field is
dominated by superstitious post-hoc rationales being given as "the reason"
why things are the way they are, when the truth is far more interesting.


> In any case, 0-based indexing in Python makes a lot of sense when you
> bring in the slicing syntax. Especially if you think of slicing as
> operating on the boundaries between cells as it were.
> 
> I used a 1-based indexed language (BASIC) for many years, and I was
> always having to subtract 1 from things.  So 0-based is simply more
> convenient for me.

There are certainly advantages to 0-based indexing. But there are also
advantages to 1-based. For example, many mathematical algorithms are best
written in terms of 1-based indexes, or at least are described as such. For
example, quartile calculations. I'm constantly having to adjust such
algorithms to work with Python.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#96193

Am 09.09.15 um 05:23 schrieb Steven D'Aprano:
> And yes, the fellow Joe who completely missed the point of the blog post,
> and made the comment "You don’t think you’re wrong and that’s part of a
> much larger problem, but you’re still wrong" completely deserved to be
> called out on his lack of reading comprehension and smugness.

This sentence is a very arrogant one, yes, but it is quoted from the 
article. Overall I have the feeling that the point he wants to make is a 
very subtle one.

	Christian

[toc] | [prev] | [next] | [standalone]

#96197

On Thu, 10 Sep 2015 02:09 am, Christian Gollwitzer wrote:

> Am 09.09.15 um 05:23 schrieb Steven D'Aprano:
>> And yes, the fellow Joe who completely missed the point of the blog post,
>> and made the comment "You don’t think you’re wrong and that’s part of a
>> much larger problem, but you’re still wrong" completely deserved to be
>> called out on his lack of reading comprehension and smugness.
> 
> This sentence is a very arrogant one, yes, but it is quoted from the
> article. Overall I have the feeling that the point he wants to make is a
> very subtle one.

Subtle enough that his quoting the author's words back at him escaped me,
but I suspect not subtle enough to escape the author's notice. Hence the
reply "Thanks for leaving your comment. I’m sure it’s made you feel very
clever."

I think my favourite is the guy who claims that the reason natural languages
all count from 1 is because the Romans failed to invent zero. (What about
languages that didn't derive from Latin, say, Chinese?) And that now that
we have zero, counting from it should be more natural. So if you give
somebody two apples, but no banana, and ask them to count their apples,
they would count "Zero, one... therefore I have two apples". And if you
then ask them to count their bananas, they would do what?

+++ Divide By Cucumber Error. Please Reinstall Universe And Reboot +++



-- 
Steven

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | comp.lang.python

csiph-web