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 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#96198

On Thu, Sep 10, 2015 at 3:22 AM, Steven D'Aprano <steve@pearwood.info> wrote:
> 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?

They would respond that there is a subtle difference between "Please
count your bananas" and "Please, Count... you're bananas".

ChrisA

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

#96207

> On Sep 9, 2015, at 1:22 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> 
> 

[byte]

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

Right.  Note that the Arabs, who DID invent zero, still count from one.

Bill

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

#96212

On 09/09/2015 18:59, William Ray Wing wrote:
>
>> On Sep 9, 2015, at 1:22 PM, Steven D'Aprano <steve@pearwood.info> wrote:
>>
>>
>
> [byte]
>
>>
>> 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?)
>
> Right.  Note that the Arabs, who DID invent zero, still count from one.
>
> Bill
>

Would you please provide a citation to support your claim as this 
http://www.livescience.com/27853-who-invented-zero.html disagrees.

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

#96304

On Wed, 9 Sep 2015 20:20:42 +0100, Mark Lawrence wrote:
> On 09/09/2015 18:59, William Ray Wing wrote:
>>> On Sep 9, 2015, at 1:22 PM, Steven D'Aprano <steve@pearwood.info> wrote:
[snip]
>> Right.  Note that the Arabs, who DID invent zero, still count from one.
[snip]
> Would you please provide a citation to support your claim as this 
> http://www.livescience.com/27853-who-invented-zero.html disagrees.

That's baffling.  Livescience.com says this:

    Robert Kaplan, author of "The Nothing That Is: A Natural History of
    Zero," suggests that an ancestor to the placeholder zero may have
    been a pair of angled wedges used to represent an empty number
    column. However, Charles Seife, author of "Zero: The Biography of a
    Dangerous Idea," disagrees that the wedges represented a
    placeholder.

In that exact book, Seife says the exact opposite of the above allegation:

    Zero was the solution to the problem.  By around 300 BC the
    Babylonians had started using two slanted wedges, [graphics
    omitted], to represent an empty space, an empty column on the
    abacus.  This _placeholder_ [italics in original] mark made it easy
    to tell which position a symbol was in.

Either Seife completely changed his mind after my copy of his book was
published (2000), or Livescience.com got it completely wrong.

-- 
To email me, substitute nowhere->runbox, invalid->com.

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

#96214

On 2015-09-09 18:59, William Ray Wing wrote:
>
>> On Sep 9, 2015, at 1:22 PM, Steven D'Aprano <steve@pearwood.info> wrote:
>>
>>
>
> [byte]
>
>>
>> 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?)
>
> Right.  Note that the Arabs, who DID invent zero, still count from one.
>
No, they didn't invent zero.

> Bill
>

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

#96215

On Thu, Sep 10, 2015 at 5:20 AM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> On 09/09/2015 18:59, William Ray Wing wrote:
>> Right.  Note that the Arabs, who DID invent zero, still count from one.
>
> Would you please provide a citation to support your claim as this
> http://www.livescience.com/27853-who-invented-zero.html disagrees.

There will be no such citation, because it's well known that zero was
invented by the jungle natives of Papua New French Guiana.

http://www.jumbojoke.com/high_tech_natives.html

ChrisA

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

#96182

Op 09-09-15 om 01:55 schreef Michael Torrie:
> 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.

Then you have never used slices with a negative step.

If slicing would operate on the boundaries between cells
then the reverse of lst[2:7] would be lst[7:2:-1] instead
it is lst[6:1:-1]

This gets you in trouble when you want to reverse through
lst[0:8] which would be lst[7:-1:-1] but now the special
meaning of negative indexes kicks in and you are screwed.

-- 
Antoon Pardon

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

#96190

On Tue, 08 Sep 2015 17:55:02 -0600, Michael Torrie <torriem@gmail.com>
declaimed the following:


>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.
>
	Many BASICs actually did allocate a zeroth element (dim x(6) allocating
7 elements) -- likely because it made the runtime faster (start_of_array +
index*element_length, where the *element_length was basically a power of 2
shift operation... Rather than adding a "-1" operation in the middle --
especially if the processor implemented subtraction as a negate and add
sequence <G>)... They just didn't advertise it, and the intro books tended
to teach on the basis of a 1-based index.

http://dictionary.reference.com/browse/dim+statement
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#96136

On Tue, Sep 8, 2015, at 10:31, Ian Kelly wrote:
> I believe this wart is fixed in VB .NET.

This is apparently true, but the weird thing is it was done late enough
in the design cycle that the .NET runtime still has features meant to
support it. You can create such an array with the Array.CreateInstance
method. For multidimensional arrays, you can even assign them to a
variable of the proper type (You can't do that for single-dimension
arrays since a single-dimension array with a nonzero lower bound is a
different type than a normal array). And the LBound and UBound methods
in the Microsoft.VisualBasic.Information class still support it.

The feature is so obscure that even the compiler doesn't do well with it
- if you create (via MSIL) a strongly-typed method that returns such an
array, the compiler will think it returns a normal array.

Of course, on the subject of warts, Dim x(5) as Integer or Dim x as
Integer() = new Integer(5){} still creates an array with size 6 (upper
bound is 5). You're free to use indices 0..4 or 1..5 if you want, but
0..5 are valid.

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

#96138

On 2015-09-08 15:31, 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.
>
In Pascal you specify both the lower and the upper bounds.

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

#96148

On 08/09/2015 18:41, MRAB wrote:
> On 2015-09-08 15:31, 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.
>>
> In Pascal you specify both the lower and the upper bounds.
>

I vaguely recall that in CORAL66/250 you specified both bounds and the 
lower bound could be negative.  Do other languages allow this or does 
the lower bound always have to be positive?

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

#96149

On 2015-09-08 23:41, Mark Lawrence wrote:
> On 08/09/2015 18:41, MRAB wrote:
>> On 2015-09-08 15:31, 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.
>>>
>> In Pascal you specify both the lower and the upper bounds.
>>
>
> I vaguely recall that in CORAL66/250 you specified both bounds and the
> lower bound could be negative.  Do other languages allow this or does
> the lower bound always have to be positive?
>
If you're allowed to specify both bounds, why would you be forbidden
from negative ones?

A better question would be whether there's a language that allows you
to specify a lower bound, but insists that it's non-negative.

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

#96150

On 09/09/2015 00:20, MRAB wrote:
> On 2015-09-08 23:41, Mark Lawrence wrote:
>> On 08/09/2015 18:41, MRAB wrote:
>>> On 2015-09-08 15:31, 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.
>>>>
>>> In Pascal you specify both the lower and the upper bounds.
>>>
>>
>> I vaguely recall that in CORAL66/250 you specified both bounds and the
>> lower bound could be negative.  Do other languages allow this or does
>> the lower bound always have to be positive?
>>
> If you're allowed to specify both bounds, why would you be forbidden
> from negative ones?

I haven't the faintest idea :)

>
> A better question would be whether there's a language that allows you
> to specify a lower bound, but insists that it's non-negative.
>

Ditto :)

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

#96152

MRAB <python@mrabarnett.plus.com> writes:
> If you're allowed to specify both bounds, why would you be forbidden
> from negative ones?

It makes it non-obvious what value should be returned from e.g. search
methods that return a negative number on failure. .NET's IndexOf
function returns -1, but MaxValue if the array has a negative
bound. BinarySearch returns the complement of the nearest index to the
value you were searching for, which requires some gymnastics if you want
to make use of it for an array that has negative and positive bounds.

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

#96332

"Random832"  wrote in message 
news:mailman.242.1441758354.8327.python-list@python.org...

MRAB <python@mrabarnett.plus.com> writes:
> If you're allowed to specify both bounds, why would you be forbidden
> from negative ones?

"
It makes it non-obvious what value should be returned from e.g. search
methods that return a negative number on failure. .NET's IndexOf
function returns -1, but MaxValue if the array has a negative
bound. BinarySearch returns the complement of the nearest index to the
value you were searching for, which requires some gymnastics if you want
to make use of it for an array that has negative and positive bounds.
"

Yes pascal/Delphi allows negative bounds if I recall correctly, example:

var
    vIntegerArray : array[-10..10] of integer;

You have just given a very good reason why to not use negative values for 
return values/indications of success or failure.

In pascal I pretty much always try and use booleans to return success.

This is a smart thing to do... especially in pascal/Delphi, since one never 
knows when one is dealing with negative numbers having processing needs.

-1 could then cause problems/troubles/errors.

There is a drawback of using booleans which I suspect is the real reason why 
C programmers for example like to use -1 to indicate failure.

It's "speed/performance". Using a seperate boolean doubles memory 
requirement and might or might not require extra processing time from the 
CPU.

Delphi usually optimizes these booleans to be returned in EAX register... so 
it's a register based thing... if enough registers or so are available 
otherwise perhaps
some pushes/pops needed... not sure about that last thing. Whatever the case 
may be... I will assume for now... that nowadays the performance impact of 
using booleans
as return values is not that great ? Also I am not sure... but perhaps 
booleans allow safer/better procesing of boolean operations.

Not sure how -1 or if -1 could lead to problems with or/and statements... 
mixing C function results will also become problematic... sometimes C 
functions return 0 to indicate failure.

Sometimes 0 can even mean success.

So C is pretty inconsistent when it comes to return values.

Hence I believe Pascal/Delphi to be better/safer at this.

Bye,
  Skybuck. 

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

#96153

On 09-09-2015 01:25, Vladimir Ignatov wrote:
>>> 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.
>
> Okay, I reevaluated my position and suddenly found that 1-based
> indexes is such a honking great idea!  Now I have another difficulty
> though. How to justify absence of built-in unicode support in a
> language carefully designed in 1993 ?
>

Sarcasm noted.

Because:

a) In 1993, ANSI C (C89) of which Lua had been developed had poor 
multibyte and wide character support. It was only with C95 that this 
stabilized.

b) It didn't needed Unicode support for what it was initially designed 
for; a scripting language to provide programming capabilities to 
data-descriptive and configuration languages.

c) As the years moved Lua eventually implemented support for the storage 
of unicode strings, but doesn't provide any higher level functions 
(including character traversing or searching). This is so because by 
that time, that task had already fallen to the unicode libraries that 
had been developed in the meantime.

Note:
You know, it is a pointless exercise to try and downplay programming 
languages (any programming language) that has proven its worth by being 
generally adopted by the programming community. Adoption is the sign of 
a respected and well designed language. You are just wasting your time. 
Even if you can find here and there some apparent flaw of arguable 
design choice, that will be true of any programming language.

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

#96200

On Wed, 9 Sep 2015 11:09 am, Mario Figueiredo wrote:

> You know, it is a pointless exercise to try and downplay programming
> languages (any programming language) that has proven its worth by being
> generally adopted by the programming community. Adoption is the sign of
> a respected and well designed language.

Counter-examples: PHP and C.

Adoption of programming languages is driven by many things, technical
excellence and careful design are not even in the top 10. Most of them are
social in nature, particularly "what is everyone else using?". Network
effects dominate: you could design the perfect language, but if nobody else
uses it, nobody will use it.

Sometimes a language will actually gain a kind of technical excellence
despite some really shitty design decisions -- but usually at great cost
elsewhere. C is a good example of that. Due to lousy decisions made by the
designers of C, it is a language really well suited for writing fast,
incorrect code. Since programmers benefit from writing fast code, but
rarely suffer from writing incorrect code (it's mostly users who suffer the
consequences of security holes), we have ended up in the situation we live
in now, where compilers compete to write faster and faster code that has
less and less relation to what the programmer intended.

(I wanted to link to the "Everything Is Broken" essay on The Medium, but the
page appears to be gone. This makes me sad. BTW, what's the point of
Google's cache when it just redirects to the original, missing, page?)

In fairness to the C creators, I'm sure that nobody back in the early
seventies imagined that malware and security vulnerabilities would be as
widespread as they have become. But still, the fundamental decisions made
by C are lousy. Assignment is an expression? Lack of first-class arrays?
The C pre-processor? They're pretty awful, but *nothing* in the entire
history of computing, not even Intercal and the COMEFROM command, comes
even close to the evil that is C "undefined behaviour".

I believe that the computing industry may never recover from the harm done
to it by the widespread use of C.



-- 
Steven

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

#96202

In a message of Thu, 10 Sep 2015 03:55:54 +1000, "Steven D'Aprano" writes:
>(I wanted to link to the "Everything Is Broken" essay on The Medium, but the
>page appears to be gone. This makes me sad. BTW, what's the point of
>Google's cache when it just redirects to the original, missing, page?)

Working for me:
https://medium.com/message/everything-is-broken-81e5f33a24e1

Laura

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

#96203

On 9/9/2015 10:55 AM, Steven D'Aprano wrote:

> (I wanted to link to the "Everything Is Broken" essay on The Medium, but the
> page appears to be gone.

Is this it? 
http://www.sott.net/article/280956-Everything-is-broken-on-the-Internet

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

#96257

On Thu, 10 Sep 2015 04:23 am, Emile van Sebille wrote:

> On 9/9/2015 10:55 AM, Steven D'Aprano wrote:
> 
>> (I wanted to link to the "Everything Is Broken" essay on The Medium, but
>> the page appears to be gone.
> 
> Is this it?
> http://www.sott.net/article/280956-Everything-is-broken-on-the-Internet

Looks like that's a mirror of the original, which is the one Laura found:

https://medium.com/message/everything-is-broken-81e5f33a24e1


Thanks guys. I don't know why I couldn't get to it earlier.



-- 
Steven

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

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

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

csiph-web