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

Groups > comp.lang.python > #95968 > 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-03 12:05 -0700
    Re: Python handles globals badly. Ian Kelly <ian.g.kelly@gmail.com> - 2015-09-03 13:47 -0600
    Re: Python handles globals badly. Ian Kelly <ian.g.kelly@gmail.com> - 2015-09-03 13:51 -0600
    Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-03 23:13 +0100
    Re: Python handles globals badly. Ian Kelly <ian.g.kelly@gmail.com> - 2015-09-03 16:45 -0600
    Re: Python handles globals badly. Michael Torrie <torriem@gmail.com> - 2015-09-03 18:06 -0600
    Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-04 01:47 +0100
    Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-04 12:27 +1000
    Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-04 12:33 +1000
      Re: Python handles globals badly. Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-09-08 11:07 +0200
    Re: Python handles globals badly. Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-09-08 10:59 +0200
      Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-09 13:27 +1000
        Re: Python handles globals badly. Ian Kelly <ian.g.kelly@gmail.com> - 2015-09-08 23:08 -0600
        Re: Python handles globals badly. Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-09-09 17:04 +0200
        Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-09 17:46 +0100
    Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-08 10:22 +0100
    Re: Python handles globals badly. Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-09-08 11:59 +0200
    Re: Python handles globals badly. Laura Creighton <lac@openend.se> - 2015-09-08 12:07 +0200

#95968 — Re: Python handles globals badly.

Now I want reflecting the latest answers:


I have the position of a high-level view 
(cause of lack of Python knowledge internals and compiler stuff,
 but also cause I think a language should be as far as possible 
 user-friendly without knowing too much internals, and yes
 clearly cause of knowing OO-languages where I do not need 
 such code-contamination)
 
So, my high-level understanding of the "global"-keyword so far is:
Give write access to a global var if this is set to this var
inside a current code block.
And this specific syntax construction is probably defined not cause it
is really needed but cause it is assumed to help the developer
avoiding mistakes, which I think is too much over-regulation.


But from the answers given I maybe have to rethink about the
global keyword. It seems to be an absolute need from low-level point of view
- meaning the designer had no other choice as to invent the keyword "global":

Two main reasons for the need of keyword "global" have been posted:

  Compiler -
    Python compiler or compiler at all cannot hide this from the developer?
    (It seems really a scripting problem. PHP has it, LUA has it vice versa,  
     ...)

    Although I cannot really believe it, that technical reasons lead to this 
    design.

    E.g recognizing if it is local or global:

    If this would be under the developer responsibility than this
    is simply achieved by giving well-written var names.

    And a compiler can surely recognize if a defined var xxx outside
    is not a var yyy inside a function.

    Or does anyone really name a global var xxx and a function var xxx?
    I am sure no one at all will do it. I dont want read such a code.



 Function calls (?) -
   I have to admit I did not really get the problematic from 
   the sample provided by Chris Angelico.

   What I can see or mean to see is: 
       it has nothing to do with global-keyword from the high level point of 
       view: give write access, probably to the vars word and otherword.

       And yes, I see the vars independant. 
       And cause you set no "global" they are simple local vars 
       (readable+writeable) 

       This is more about let me assume function call stack and 
       closures things(?) which I think is handled automatically.

   But as said - here I cannot really respond.
   This have to be answered from more experienced users.
   

   
     
My conclusion:
--------------

My intention was to bring this into discussion and see what comes out and
see what are the reasons for this keyword. 
I am not the user who can open the PEP, but maybe the community out decides to do so.

But if this two problems really exists from low-level point of view, then ok, there is no other way than to use this keyword "global".  I have not the experience to answer that. I can accept low-level problems if so.

But then I ask you from high-level point of view 
(if my high level view is correct at all):
Would you remove this keyword if it would be technically possible
or is good for you from high level point of view to have a keyword "global"?

My answer is clear: remove it.
[The same e.g. with switch statement: add it]


Then this is my question now!


Thanks.

[toc] | [next] | [standalone]

#95969

On Thu, Sep 3, 2015 at 1:05 PM,  <tdev@freenet.de> wrote:
>     If this would be under the developer responsibility than this
>     is simply achieved by giving well-written var names.

So, adopt a rule whereby you prefix all your global variable names
with "global" or "g_"? How is this superior to just declaring them
once per function that needs to set them? You're just shifting the
extra typing from one place to another.

>     Or does anyone really name a global var xxx and a function var xxx?
>     I am sure no one at all will do it. I dont want read such a code.

Intentionally, it's probably rare. But if I'm adding a new variable, I
shouldn't need to first make sure that it's safe to do so by scanning
over the entire file to make sure that the name hasn't already been
used elsewhere in the opposite scope.

>  Function calls (?) -
>    I have to admit I did not really get the problematic from
>    the sample provided by Chris Angelico.
>
>    What I can see or mean to see is:
>        it has nothing to do with global-keyword from the high level point of
>        view: give write access, probably to the vars word and otherword.
>
>        And yes, I see the vars independant.
>        And cause you set no "global" they are simple local vars
>        (readable+writeable)

So in order for something to be global, it would have to be referenced
at least once in the global scope? Currently it's possible to do this:

def set_foo(value):
    global foo
    foo = value

def get_foo():
    return foo

With your proposal that would change to:

foo = None

def set_foo(value):
    foo = value

def get_foo():
    return foo

So again the declaration has just been moved from one place to another.

> But then I ask you from high-level point of view
> (if my high level view is correct at all):
> Would you remove this keyword if it would be technically possible
> or is good for you from high level point of view to have a keyword "global"?

Provided that the proposal doesn't open up the possibility of
unintentionally creating a global variable where I wanted a local, I'd
be okay with it.

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

#95970

On Thu, Sep 3, 2015 at 1:47 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Thu, Sep 3, 2015 at 1:05 PM,  <tdev@freenet.de> wrote:
>
>> But then I ask you from high-level point of view
>> (if my high level view is correct at all):
>> Would you remove this keyword if it would be technically possible
>> or is good for you from high level point of view to have a keyword "global"?
>
> Provided that the proposal doesn't open up the possibility of
> unintentionally creating a global variable where I wanted a local, I'd
> be okay with it.

Let me clarify that I'd be okay with making the keyword optional. It
should probably still be kept around for the occasional use like this:

exec("""def function():
    global {0}
    {0} = 42
""".format('x'))

where the compiler would have little hope of figuring out that the
variable was meant to be global without it.

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

#95974

On 03/09/2015 20:47, Ian Kelly wrote:
> On Thu, Sep 3, 2015 at 1:05 PM,  <tdev@freenet.de> wrote:
>>      Or does anyone really name a global var xxx and a function var xxx?
>>      I am sure no one at all will do it. I dont want read such a code.
>
> Intentionally, it's probably rare. But if I'm adding a new variable, I
> shouldn't need to first make sure that it's safe to do so by scanning
> over the entire file to make sure that the name hasn't already been
> used elsewhere in the opposite scope.
>

I'm just curious as I've never used it myself, but how does nonlocal 
https://docs.python.org/3/reference/simple_stmts.html#the-nonlocal-statement 
fit into this?

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

#95978

On Thu, Sep 3, 2015 at 4:13 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> On 03/09/2015 20:47, Ian Kelly wrote:
>>
>> On Thu, Sep 3, 2015 at 1:05 PM,  <tdev@freenet.de> wrote:
>>>
>>>      Or does anyone really name a global var xxx and a function var xxx?
>>>      I am sure no one at all will do it. I dont want read such a code.
>>
>>
>> Intentionally, it's probably rare. But if I'm adding a new variable, I
>> shouldn't need to first make sure that it's safe to do so by scanning
>> over the entire file to make sure that the name hasn't already been
>> used elsewhere in the opposite scope.
>>
>
> I'm just curious as I've never used it myself, but how does nonlocal
> https://docs.python.org/3/reference/simple_stmts.html#the-nonlocal-statement
> fit into this?

I don't know whether the proposal also applies to nonlocals, but such
conflicts would be less of an issue since you would only need to check
the outermost function scope (and also, nested functions aren't really
all that common).

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

#95983

On 09/03/2015 01:05 PM, tdev@freenet.de wrote:
> And a compiler can surely recognize if a defined var xxx outside is
> not a var yyy inside a function.

At issue here is the idea of Python namespaces and how Python uses them
in a consistent way with your code.  The consistency is that binding of
a name to an object within a function is in the function's namespace.
Makes things fast and simple.  To facilitate writing to the module's
namespace the global keyword is an elegant way of preserving
consistency. But this has been said a few times I'm sure so we're going
in circles here.

> Or does anyone really name a global var xxx and a function var xxx? I
> am sure no one at all will do it.

Not sure I follow you here.  What do the names programmers choose have
to do with it?  If I'm looking at a function, which should never be more
than a screen of code long, if I see a reference to a variable that has
never been assigned, I know it's defined in a parent scope.  If I see as
assignment, then I know it's local.  If I see the word global then I
know that any assignments are to the global namespace. Doesn't matter
what the name is.  It's consistent and explicit, which is one of
Python's mantras, so I feel justified in defending this
quirk/foible/feature of the language.

> My answer is clear: remove it.

But the global keyword serves a purpose.  It's just different from the
purpose you think you need.  I get the impression you'd rather bend
Python to your will, rather than work with it and learn the powerful
Python idioms, which is just going to end in frustration.  I don't think
anyone would support a PEP to change python as you suggest (and it
couldn't be done anytime soon until Python 4000 anyway). Seems a rather
Quixote-esque quest you are on here. Spend some time to understand how
Python variables differ from variables in other languages (most python
"variables" are names bound to immutable objects like numbers).

> [The same e.g. with switch statement: add it]

Switch is a nice-to-have thing, but definitely not essential. A PEP here
(probably already has been several) would at least be read anyway.
However, there are several idiomatic ways of accomplishing the same
thing that are often good enough and familiar to any Python programmer
out there.  Since functions are first-class objects, often a dispatch
table is the best way to go here.

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

#95984

On 04/09/2015 01:06, Michael Torrie wrote:
> On 09/03/2015 01:05 PM, tdev@freenet.de wrote:
>
>> [The same e.g. with switch statement: add it]
>
> Switch is a nice-to-have thing, but definitely not essential. A PEP here
> (probably already has been several) would at least be read anyway.
> However, there are several idiomatic ways of accomplishing the same
> thing that are often good enough and familiar to any Python programmer
> out there.  Since functions are first-class objects, often a dispatch
> table is the best way to go here.
>

https://www.python.org/dev/peps/pep-3103/ "A Switch/Case Statement" by 
Guido van Rossum, "Rejection Notice - A quick poll during my keynote 
presentation at PyCon 2007 shows this proposal has no popular support. I 
therefore reject it".

https://www.python.org/dev/peps/pep-0275/ "Switching on Multiple Values" 
by Marc-André Lemburg, "Rejection Notice - A similar PEP for Python 
3000, PEP 3103 [2], was already rejected, so this proposal has no chance 
of being accepted either."

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

#95993

On Fri, 4 Sep 2015 05:05 am, tdev@freenet.de wrote:

> Or does anyone really name a global var xxx and a function var xxx?
> I am sure no one at all will do it. I dont want read such a code.


You should reflect on the purpose of namespaces and local variables.

Some programming languages do not distinguish local and global variables.
There are only variables, and they are shared by the entire program. That
is terrible for encapsulation, because every time you use a variable, you
have to stop and think whether that name is already being used *anywhere*
else:


def function(x):
    ...
    y = x + 1

What if y is being used somewhere else? You have just over-written the value
of y that another part of the program relies on.

Instead, most languages over the last 40 or 50 years have separate
namespaces for variables. Each function's local variables are separate from
every other function's locals: writing "y = x + 1" inside a function
*cannot possibly* affect another function, if y is a local variable.

So when writing a function, and creating local variables, you do not need to
care whether the names you use have been used elsewhere. There is no need
for every name in the entire program to be unique. The only time you need
care is to avoid using the same name for a local and a global *that you
intend to use*. If you don't intend to use it, there is no possible harm.


Think about a program where last week I have written a function:

def function(x):
    ...
    y = x + 1

y here is local to the function.

Most commercial programs have dozens or hundreds of developers working on
them (for something big like Microsoft Windows). Open source software might
have thousands of developers. So today you come along and work on the same
program as me, and you add a global variable:

y = 999

What do you expect to happen? Do you think it is a good idea for your change
*outside* of the function to suddenly change the meaning of the line 
"y = x + 1" *inside* the function?

Fortunately, in Python, nothing changes. My function continues to work as
before. You adding a global variable that happens to have the same name as
one of my local variables does not break my function. Local variables are
completely isolated to the function they are in.

Which is exactly the way it should be. Worrying about local variables using
the same name as globals is silly. The only time that is harmful is if you
intend to use the global in a function but have a local of the same name.



-- 
Steven

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

#95995

On Fri, 4 Sep 2015 05:05 am, tdev@freenet.de wrote:

> Would you remove this keyword if it would be technically possible

Absolutely not.

I do not believe that it is technically possible, but even if it were, I
would still argue that the Zen of Python applies:

Explicit is better than implicit.

Local variables should be the default, and you should explicitly declare any
time you want to write to a global.

Not the other way around, like Lua does. I've always thought that was silly:
you should make the *desirable* thing easy to do, and the *dangerous* think
(using globals) possible but not easy to do by accident.


> or is good for you from high level point of view to have a keyword
> "global"?

Yes.


> My answer is clear: remove it.
> [The same e.g. with switch statement: add it]


What would a switch statement do? How will it be different from if...elif?

Out of the dozen or so different switch statements offered by other
languages, which would you choose?



-- 
Steven

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

#96107

Op 04-09-15 om 04:33 schreef Steven D'Aprano:
> On Fri, 4 Sep 2015 05:05 am, tdev@freenet.de wrote:
>
>> Would you remove this keyword if it would be technically possible
> Absolutely not.
>
> I do not believe that it is technically possible, but even if it were, I
> would still argue that the Zen of Python applies:
>
> Explicit is better than implicit.
>
> Local variables should be the default, and you should explicitly declare any
> time you want to write to a global.
>
> Not the other way around, like Lua does. I've always thought that was silly:
> you should make the *desirable* thing easy to do, and the *dangerous* think
> (using globals) possible but not easy to do by accident.

You are trying to have your cake and eat it. If explicit is better than implicit
then declaring your variable at the scope it has to live in, is what you need
to do, that is the explicit way.

Not needing to declare local variables, is an implicit way, since it is behaviour
depending on something not being indicated.

-- 
Antoon Pardon

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

#96106

Op 04-09-15 om 02:47 schreef Mark Lawrence:
> On 04/09/2015 01:06, Michael Torrie wrote:
>> On 09/03/2015 01:05 PM, tdev@freenet.de wrote:
>>
>>> [The same e.g. with switch statement: add it]
>>
>> Switch is a nice-to-have thing, but definitely not essential. A PEP here
>> (probably already has been several) would at least be read anyway.
>> However, there are several idiomatic ways of accomplishing the same
>> thing that are often good enough and familiar to any Python programmer
>> out there.  Since functions are first-class objects, often a dispatch
>> table is the best way to go here.
>>
>
> https://www.python.org/dev/peps/pep-3103/ "A Switch/Case Statement" by
> Guido van Rossum, "Rejection Notice - A quick poll during my keynote
> presentation at PyCon 2007 shows this proposal has no popular support.
> I therefore reject it".
>
> https://www.python.org/dev/peps/pep-0275/ "Switching on Multiple
> Values" by Marc-André Lemburg, "Rejection Notice - A similar PEP for
> Python 3000, PEP 3103 [2], was already rejected, so this proposal has
> no chance of being accepted either."
>
Were those polls, like the poll he once did for the condtional expression?
There the poll indicated no specific proposal had a majority, so for each
specific proposal one could say it didn't have popular support, but the
majority still prefered to have a conditional expression. But at that
time Guido used that poll as an indication there was not enough support.

So colour me a bit sceptical when Guido comes with such a poll.

-- 
Antoon Pardon

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

#96159

On Tue, 8 Sep 2015 06:59 pm, Antoon Pardon wrote:

> Op 04-09-15 om 02:47 schreef Mark Lawrence:
>> On 04/09/2015 01:06, Michael Torrie wrote:
>>> On 09/03/2015 01:05 PM, tdev@freenet.de wrote:
>>>
>>>> [The same e.g. with switch statement: add it]
>>>
>>> Switch is a nice-to-have thing, but definitely not essential. A PEP here
>>> (probably already has been several) would at least be read anyway.
>>> However, there are several idiomatic ways of accomplishing the same
>>> thing that are often good enough and familiar to any Python programmer
>>> out there.  Since functions are first-class objects, often a dispatch
>>> table is the best way to go here.
>>>
>>
>> https://www.python.org/dev/peps/pep-3103/ "A Switch/Case Statement" by
>> Guido van Rossum, "Rejection Notice - A quick poll during my keynote
>> presentation at PyCon 2007 shows this proposal has no popular support.
>> I therefore reject it".
>>
>> https://www.python.org/dev/peps/pep-0275/ "Switching on Multiple
>> Values" by Marc-André Lemburg, "Rejection Notice - A similar PEP for
>> Python 3000, PEP 3103 [2], was already rejected, so this proposal has
>> no chance of being accepted either."
>>
> Were those polls, like the poll he once did for the condtional expression?
> There the poll indicated no specific proposal had a majority, so for each
> specific proposal one could say it didn't have popular support, but the
> majority still prefered to have a conditional expression. But at that
> time Guido used that poll as an indication there was not enough support.

In the case of conditional expression, there is *no good alternative*.

Using if...then statement is too heavyweight, and cannot be used in an
expression. Using "flag and true_value or false_value" is buggy -- it fails
if true_value is itself false. Refactoring it to a function uses eager
rather than lazy evaluation. So there was no existing alternative to a
ternary if expression that worked correctly.

In the case of case/switch, there is no consensus on what the statement
should do, how it should work, what purpose it has, or what syntax it
should use. Rather than "there's no alternative to a case statement", the
situation was more like "there are many good alternatives to the various
different case statements people want".



-- 
Steven

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

#96160

On Tue, Sep 8, 2015 at 9:27 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> Using if...then statement is too heavyweight, and cannot be used in an
> expression. Using "flag and true_value or false_value" is buggy -- it fails
> if true_value is itself false. Refactoring it to a function uses eager
> rather than lazy evaluation. So there was no existing alternative to a
> ternary if expression that worked correctly.

I used to see "(flag and [true_value] or [false_value])[0]" fairly
often, which solves the bugginess problem by ensuring that the second
term can't be false. Not that I would recommend it over an actual
conditional expression.

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

#96191

Op 09-09-15 om 05:27 schreef Steven D'Aprano:
>
>> Were those polls, like the poll he once did for the condtional expression?
>> There the poll indicated no specific proposal had a majority, so for each
>> specific proposal one could say it didn't have popular support, but the
>> majority still prefered to have a conditional expression. But at that
>> time Guido used that poll as an indication there was not enough support.
> In the case of conditional expression, there is *no good alternative*.

Yet there were people who passionatly argued against introducing one.
Even when list comprehensions were introduced where they really would
be useful some people still fought it.

Just to show that people fighting something is not a strong argument.

> Using if...then statement is too heavyweight, and cannot be used in an
> expression. Using "flag and true_value or false_value" is buggy -- it fails
> if true_value is itself false. Refactoring it to a function uses eager
> rather than lazy evaluation. So there was no existing alternative to a
> ternary if expression that worked correctly.

Yes there was. There were even two. One was packing your values into
a one element list, the other was packing them in a lambda. It was ugly
but it was what people came up with for lack of better.

> In the case of case/switch, there is no consensus on what the statement
> should do, how it should work, what purpose it has, or what syntax it
> should use. Rather than "there's no alternative to a case statement", the
> situation was more like "there are many good alternatives to the various
> different case statements people want".

Since when does Guido need a consensus? Look the developers have only limited
time, and they get to choose what they consider a priority and what they don't.
And if they think other things have higher priority, fine by me. But don't
come with, no support/consensus with the users, because if the dev-team thinks
something is a good idea, they'll implement it without much consideration for
support/consensus among the users.

-- 
Antoon Pardon 

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

#96196

On 09/09/2015 16:04, Antoon Pardon wrote:
> Op 09-09-15 om 05:27 schreef Steven D'Aprano:
>
>> In the case of case/switch, there is no consensus on what the statement
>> should do, how it should work, what purpose it has, or what syntax it
>> should use. Rather than "there's no alternative to a case statement", the
>> situation was more like "there are many good alternatives to the various
>> different case statements people want".
>
> Since when does Guido need a consensus? Look the developers have only limited
> time, and they get to choose what they consider a priority and what they don't.
> And if they think other things have higher priority, fine by me. But don't
> come with, no support/consensus with the users, because if the dev-team thinks
> something is a good idea, they'll implement it without much consideration for
> support/consensus among the users.
>

A number of recent PEPs have been given delegated authority, so someone 
other than Guido makes the final decision as to whether to accept or 
reject it. I can only suggest you don't follow some of the intense wars 
of words that go on on python-dev, or even python-ideas, as the part 
about this dev-team simply overriding users is nonsense.

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

#96108

On 08/09/2015 09:59, Antoon Pardon wrote:
> Op 04-09-15 om 02:47 schreef Mark Lawrence:
>> On 04/09/2015 01:06, Michael Torrie wrote:
>>> On 09/03/2015 01:05 PM, tdev@freenet.de wrote:
>>>
>>>> [The same e.g. with switch statement: add it]
>>>
>>> Switch is a nice-to-have thing, but definitely not essential. A PEP here
>>> (probably already has been several) would at least be read anyway.
>>> However, there are several idiomatic ways of accomplishing the same
>>> thing that are often good enough and familiar to any Python programmer
>>> out there.  Since functions are first-class objects, often a dispatch
>>> table is the best way to go here.
>>>
>>
>> https://www.python.org/dev/peps/pep-3103/ "A Switch/Case Statement" by
>> Guido van Rossum, "Rejection Notice - A quick poll during my keynote
>> presentation at PyCon 2007 shows this proposal has no popular support.
>> I therefore reject it".
>>
>> https://www.python.org/dev/peps/pep-0275/ "Switching on Multiple
>> Values" by Marc-André Lemburg, "Rejection Notice - A similar PEP for
>> Python 3000, PEP 3103 [2], was already rejected, so this proposal has
>> no chance of being accepted either."
>>
> Were those polls, like the poll he once did for the condtional expression?

Polls, there is only one referred to above?

> There the poll indicated no specific proposal had a majority, so for each
> specific proposal one could say it didn't have popular support, but the
> majority still prefered to have a conditional expression. But at that
> time Guido used that poll as an indication there was not enough support.
>
> So colour me a bit sceptical when Guido comes with such a poll.
>

In that case there were either two different polls, or one of us is 
mistaken, as I was very much under the impression that as there was no 
clear winner for a conditional expression, but a majority wanted one, 
Guido simply picked the one he favoured.  Hum, IIRC that was backed up 
by an analysis of the standard library.

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

#96111

Op 08-09-15 om 11:22 schreef Mark Lawrence:
> On 08/09/2015 09:59, Antoon Pardon wrote:
>
>> There the poll indicated no specific proposal had a majority, so for
>> each
>> specific proposal one could say it didn't have popular support, but the
>> majority still prefered to have a conditional expression. But at that
>> time Guido used that poll as an indication there was not enough support.
>>
>> So colour me a bit sceptical when Guido comes with such a poll.
>>
>
> In that case there were either two different polls, or one of us is 
> mistaken, as I was very much under theimpression that as there was no 
> clear winner for a conditional expression, but a majority wanted one, 
> Guido simply picked the one he favoured.  Hum, IIRC that was backed up 
> by an analysis of the standard library.
>

You are mistaken. Guido originally used the fact that there was no
clear winner to reject the proposal for a conditional expression.
And each time someone would ask for one on this list they would
be referred to the "and or" construction that was proposed as
an alternative.

But then some time later one of the core developers was bitten
by an elusive bug (in the standard library I think) because the
and-or construction didn't work as expected when the middle
expression evaluated to something equivallent to false. It was
then that Guido decided to have a conditional expression and
chose the one he favoured.

-- 
Antoon Pardon

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

#96112

In a message of Tue, 08 Sep 2015 10:59:01 +0200, Antoon Pardon writes:
>Were those polls, like the poll he once did for the condtional expression?
>There the poll indicated no specific proposal had a majority, so for each
>specific proposal one could say it didn't have popular support, but the
>majority still prefered to have a conditional expression. But at that
>time Guido used that poll as an indication there was not enough support.
>
>So colour me a bit sceptical when Guido comes with such a poll.

That's not how I remember it:

There were people who wanted, a conditional expression, 'preferably
<this syntax>, but if I cannot have that, any of the other syntaxes'.
These were the people who were very passionate about wantinhg a
conditional expression.

There were other people who wanted a conditional expression, _but only
with my preferred syntax_.  Given a choice between another syntax and
not having it, they would prefer to not have one.  A good number of
these people were more in the 'I wouldn't mind ...' than passionate
wanters of a conditional expression.

I was in the third group.  Passionately not wanting any
conditional expression whatsoever.

Group 2 was the largest group.

Thus while 1 plus 2 outnumbered 3, for each proposed syntax 3 plus
'the members of group 2 who didn't want this syntax' outnumbered 1 plus 'the
members of group 2 who did'.

Thus a mess, heavily complicated by a very interesting discussion about
what sort of voting method would be appropriate to make such a choice,
and non-winner-take-all systems in general.

Laura

[toc] | [prev] | [standalone]

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

csiph-web