Re: Python handles globals badly.

[Antoon Pardon]

Op 16-09-15 om 03:13 schreef Steven D'Aprano:
> On Mon, 14 Sep 2015 06:30 pm, Antoon Pardon wrote:
>
>> Op 12-09-15 om 05:48 schreef Steven D'Aprano:
>>> I believe I already acknowledged that assignment-as-expression was fine
>>> if it avoided the = versus == error, from the perspective of avoiding
>>> errors. But from the perspective of a clean and logical programming
>>> model, perhaps not so much. Assignment is imperative, not functional, and
>>> requiring it to return a result is somewhat unclean.
>> I thought practicallity beats purity? AFAICS python doesn't use such a
>> clean and logical programming model and it isn't given much critique over
>> it. So I don't think it is fair to critique assignment as an expression
>> because of this aspect.
> Python is a remarkably clean and consistent language.

Which is beside the point. Python may generally be a remarkable clean
and consistent language, we were not discussing the language in general
but a specific aspect. Arguing against C because it doesn't makes a
clear seperation between questions and actions (because the assignment
is an expression) while python doesn't either (but in other places) strikes
me as disingineous.
 

>> But we are not talking about all commands, we are just talking about
>> assignments. Sure an assignment has a side effect. But so has ls.pop(). So
>> something having a side-effect and a value is not unheard of even within a
>> python context.
> Sure, I already said that some commands might return a value.
>
> But assignment? Assignment is a pure command. There's nothing to return.
> Having `x = 23` return 23 is, well, weird. If we start from the premise
> that a return result is generated from a *calculation* or a *query*, we
> have to ask what is being calculated or asked?

You are stating your opinion as fact. Suppose I write the following class

class SetGet:
def __init__(self, value):
self.val = value

def get(self):
return self.val

def set(self, value):
self.val = value
return value

So now I can write the following

index = SetGet(0)
while index.set(index.get() + 1) < 10:
  do_what_ever


So how would you answer your question as to what is calculated or asked
in the while condition here? The answer would be similar if we had just
allowed an assignment in the condition.

> And one other reason why I dislike it: it makes for a verbose and messy
> interactive experience. Take Ruby:

We are not talking about likes and dislikes. This discussion started
by you stating the the assignment as an expression in C was a design
flaw in the language. I can understand people preferring the assignment
not to be an operator. But when people start suggesting that assignment
as an operator is some kind of design flaw, which they use to criticise
a specific language, personal likes and dislikes are not important.

-- 
Antoon Pardon

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Steven D'Aprano]

On Wed, 16 Sep 2015 11:13 am, Steven D'Aprano wrote:

> Python is a remarkably clean and consistent language. There's only one
> kind of value (the object -- everything is an object, even classes are
> objects). The syntax isn't full of special cases. For example, there's
> nothing like this horror from Ruby:
> 
> #!/usr/bin/ruby
> def a(x=4)
> x+2
> end
> 
> b = 1
> print "a + b => ", (a + b), "\n"
> print "a+b   => ", (a+b), "\n"
> print "a+ b  => ", (a+ b), "\n"
> print "a +b  => ", (a +b), "\n"
> 
> 
> which prints:
> 
> 7
> 7
> 7
> 3


Of course it doesn't. It prints:

a + b => 7
a+b   => 7
a+ b  => 7
a +b  => 3


Sorry about that.



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Random832]

Steven D'Aprano  writes:
> I don't need to see 23 printed, because I already know what the value is, so
> that takes two lines where one would do. (On the rare case I did want to
> see the value of something I had just assigned to, I could just print the
> expression.)

Of course, you could just as well say that you _never_ need to see
anything printed unless you ask for it. The first time I used the REPL I
was irritated by the fact that None wasn't printed. The reason that None
isn't printed is, of course, because Python has no distinction between a
function that returns None as a value and a function that doesn't return
a value.

The alternative is to make assignments special within the REPL, or even
turn it into something that looks less like a REPL and more like the
variable/expression list that some IDE debuggers have.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Chris Angelico]

On Wed, Sep 16, 2015 at 11:20 AM, Steven D'Aprano  wrote:
> On Wed, 16 Sep 2015 11:13 am, Steven D'Aprano wrote:
>
>> Python is a remarkably clean and consistent language. There's only one
>> kind of value (the object -- everything is an object, even classes are
>> objects). The syntax isn't full of special cases. For example, there's
>> nothing like this horror from Ruby:
>>
>> #!/usr/bin/ruby
>> def a(x=4)
>> x+2
>> end
>>
>> b = 1
>> print "a + b => ", (a + b), "\n"
>> print "a+b   => ", (a+b), "\n"
>> print "a+ b  => ", (a+ b), "\n"
>> print "a +b  => ", (a +b), "\n"
>>
>>
>> which prints:
>>
>> 7
>> 7
>> 7
>> 3
>
>
> Of course it doesn't. It prints:
>
> a + b => 7
> a+b   => 7
> a+ b  => 7
> a +b  => 3
>
>
> Sorry about that.

I'm not a Rubyist, but my reading of this is that the last one is
calling a with +b as its argument, where all the others are calling a
with no argument, and then using the result in an expression. ISTM the
problem here is omitting the parentheses on a function call.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Steven D'Aprano]

On Mon, 14 Sep 2015 06:30 pm, Antoon Pardon wrote:

> Op 12-09-15 om 05:48 schreef Steven D'Aprano:
>> I believe I already acknowledged that assignment-as-expression was fine
>> if it avoided the = versus == error, from the perspective of avoiding
>> errors. But from the perspective of a clean and logical programming
>> model, perhaps not so much. Assignment is imperative, not functional, and
>> requiring it to return a result is somewhat unclean.
> 
> I thought practicallity beats purity? AFAICS python doesn't use such a
> clean and logical programming model and it isn't given much critique over
> it. So I don't think it is fair to critique assignment as an expression
> because of this aspect.

Python is a remarkably clean and consistent language. There's only one kind
of value (the object -- everything is an object, even classes are objects).
The syntax isn't full of special cases. For example, there's nothing like
this horror from Ruby:

#!/usr/bin/ruby
def a(x=4)
x+2
end

b = 1
print "a + b => ", (a + b), "\n"
print "a+b   => ", (a+b), "\n"
print "a+ b  => ", (a+ b), "\n"
print "a +b  => ", (a +b), "\n"


which prints:

7
7
7
3

This is not a bug in the language (well, yes it is, it's a design bug), but
it is a consequence of the syntax.

Python has nothing like this. Python's syntax is quite clean and consistent.


[...]
> But we are not talking about all commands, we are just talking about
> assignments. Sure an assignment has a side effect. But so has ls.pop(). So
> something having a side-effect and a value is not unheard of even within a
> python context.

Sure, I already said that some commands might return a value.

But assignment? Assignment is a pure command. There's nothing to return.
Having `x = 23` return 23 is, well, weird. If we start from the premise
that a return result is generated from a *calculation* or a *query*, we
have to ask what is being calculated or asked? 

I'm not quite willing to say that assignment-as-expression is an error,
because I acknowledge that it could be useful in some places. But it seems
bolted on and arbitrary, like having del return the name you just unbound:

assert (del x) == 'x'

And one other reason why I dislike it: it makes for a verbose and messy
interactive experience. Take Ruby:

irb(main):001:0> a = 23
=> 23


I don't need to see 23 printed, because I already know what the value is, so
that takes two lines where one would do. (On the rare case I did want to
see the value of something I had just assigned to, I could just print the
expression.)


-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Skybuck Flying]

"Ned Batchelder"  wrote in message 
news:180fe671-7bf9-4544-a3ad-d98a4a497...@googlegroups.com...


On Sunday, September 13, 2015 at 8:11:13 AM UTC-4, Skybuck Flying wrote:

I don't even understand how python interpreter works but I can understand 
it

better than you guys do apperently hahaha.


"
As tempting as it is to respond to Skybuck, with a brief pause to consider,
and a deep breath, I'm sure we can all agree that there is no point in it.

Skybuck: go in peace, and thanks for being part of the Python community.
"

Go in Peace yourself

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Antoon Pardon]

Op 11-09-15 om 13:59 schreef Marko Rauhamaa:
> Antoon Pardon :
>
>> I just don't get why people want to introduce special cases in python.
>> Why allow such a construct only in while and if? Why not just allow
>> it generally as an assignment expression?
>>
>> Why not allow:
>>
>>   while (f(x) as fx) > 5:
>> proces(fx)
>>
>> or
>>
>>   if check(nextvalue() as new):
>> treat(new)
> Hey, I know, I know!... Let's allow:
>
>while (fx = f(x)) > 5:
>process(fx)
>
>if check(new = nextvalue()):
>treat(new)
>
> Seriously, though, I share your distaste of special cases, Antoon. Only
> I don't like too much syntax (just look at Perl).

This proposal would have as an effect less syntax. The 'as ...' syntax
already exists, but as special cases. Making 'as ...' a general assignment
operator would eliminated the special cases and collect them all in the
expression syntax. So less syntax.

>  There's nothing wrong
> in:
>
>while True:
>fx = f(x)
>if fx <= 5:
>break
>process(fx)

There was also nothing wrong with:

  if b > c:
a = 5
  else:
a = 2

>new = nextvalue()
>if check(new):
>treat(new)

Except that it would need an extra indentation level if
it was an elif.

-- 
Antoon Pardon

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Antoon Pardon]

Op 12-09-15 om 05:48 schreef Steven D'Aprano:
> I believe I already acknowledged that assignment-as-expression was fine if
> it avoided the = versus == error, from the perspective of avoiding errors.
> But from the perspective of a clean and logical programming model, perhaps
> not so much. Assignment is imperative, not functional, and requiring it to
> return a result is somewhat unclean.

I thought practicallity beats purity? AFAICS python doesn't use such a clean
and logical programming model and it isn't given much critique over it.
So I don't think it is fair to critique assignment as an expression because
of this aspect.

> Look at it this way: suppose you had a robot servant that always, without
> fail or misunderstanding, did what you instructed. There are broadly two
> sorts of things that you can give as instructions: questions, and commands.
> Questions always require an answer: "What's the length of this list?" is
> functional. Commands are imperative, not functional, and don't necessarily
> require an answer: "Move the small red pyramid onto the large green cube."
> Some commands arguable might require an answer, but arguable they are
> better served by an out-of-band error condition (an exception). *Requiring*
> all commands to give an answer is silly, given that the robot servant is
> infallible.

But we are not talking about all commands, we are just talking about 
assignments.
Sure an assignment has a side effect. But so has ls.pop(). So something having
a side-effect and a value is not unheard of even within a python context.

-- 
Antoon Pardon

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Steven D'Aprano]

On Sun, 13 Sep 2015 10:04 pm, Skybuck Flying wrote:

> "
> Namespaces don't "become writeable".
> 
> The purpose of "global" is to tell the compiler that this name should
> be bound in the global namespace, not the local namespace.
> "
> 
> How does it become writeable then ?

It's always writeable.






-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Skybuck Flying]

"
Namespaces don't "become writeable".

The purpose of "global" is to tell the compiler that this name should
be bound in the global namespace, not the local namespace.
"

How does it become writeable then ?

Bye,
 Skybuck.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Skybuck Flying]

"Steven D'Aprano"  wrote in message 
news:55f566c8$0$1644$c3e8da3$54964...@news.astraweb.com...


On Sun, 13 Sep 2015 10:04 pm, Skybuck Flying wrote:


"
Namespaces don't "become writeable".

The purpose of "global" is to tell the compiler that this name should
be bound in the global namespace, not the local namespace.
"

How does it become writeable then ?


"
It's always writeable.
"

Thus my logic is correct.

By making something global, it ends up in the global namespace, and it 
becomes writeable.


I don't even understand how python interpreter works but I can understand it 
better than you guys do apperently hahaha.


Bye,
 Skybuck. 


--
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Skybuck Flying]

I may add to that:

Just like most programmers don't truely understand what a compiler does ! 
HAHAHAHAHA.


C programmers, Delphi programmers, Java programmers.

What python's interpreter is doing same thing, probably completely 
irrelevant.


Except when it comes to making changes to how python works ;)

I don't need to know how the Python interpreter works, cause I will never 
change Python's implementation.


However as indicated I did try to help out.

Reversing the logic for python's global functioning should be possible.

Bye,
 Skybuck. 


--
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Skybuck Flying]

"Emile van Sebille"  wrote in message 
news:mailman.433.1442078406.8327.python-l...@python.org...


On 9/11/2015 10:22 PM, Skybuck Flying wrote:



I didn't learn anything from this posting, sorry ! ;)


"
I'm seeing a pattern here...
"

Only thing I might have learned from him was global namespace make thing 
writeable.


But now somebody else says nope.

So I can truely say nothing was learned.

Explaining concepts to people takes something different.

As far as I am concerned python works with objects like Delphi.

And everything else is a reference to it.

And the globals are somehow protected.

But he's as clueless as everybody else seems to be.

For me it doesn't matter since I will write python code just fine without 
understanding any of it.


Bye,
 Skybuck.


--
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Skybuck Flying]

From what he wrote I can see he's not making much sense...


Neither are you.

Just lot's of nag and little python related stuff.

Bye,
 Skybuck.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Ned Batchelder]

On Sunday, September 13, 2015 at 8:11:13 AM UTC-4, Skybuck Flying wrote:

> I don't even understand how python interpreter works but I can understand it 
> better than you guys do apperently hahaha.

As tempting as it is to respond to Skybuck, with a brief pause to consider,
and a deep breath, I'm sure we can all agree that there is no point in it.

Skybuck: go in peace, and thanks for being part of the Python community.

--Ned.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Mark Lawrence]

On 12/09/2015 17:29, Dennis Lee Bieber wrote:

On Sat, 12 Sep 2015 05:11:46 +0100, Mario Figueiredo 
declaimed the following:


On 12-09-2015 03:35, Mark Lawrence wrote:


Ada took over from CORAL in the UK, at least in military projects.  It
was also used in the aircraft industry. My old work mates tell me that
its completely died a death, to be replaced by C++.  Someone please
remind me never to fly again.


Alright. But then someone should probably have reminded you that a long
time ago.

Maybe you missed it when an Ada integer overflow bug produced one of the
most expensive software bugs in history by crashing the Ariane 501
rocket and its 4 cluster sattelites payload.



As I recall, the software did exactly what it was supposed to do in
that situation...

But no one had tested the algorithm with the rate of change the Ariane
5 could produce -- so an algorithm that was developed for, and safe with,
the smaller Ariane suddenly went "something's wrong -- abandon ship"

Nothing inherent in the language...



Well if the backup system that took over when the primary system gave up 
the ghost had used a different algorithm, and had been tested for an 
appropriate range of inputs, we wouldn't be having this discussion.  It 
didn't.  The rest is history, and very expensive history at that.


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

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[MRAB]

On 2015-09-12 06:22, Skybuck Flying wrote:



"Michael Torrie"  wrote in message
news:mailman.384.1442016089.8327.python-l...@python.org...

On 09/11/2015 03:50 PM, Skybuck Flying wrote:

Something which python does not seem to do currently ?!

So that's weird.

I will leave it at that for now.


"
Seems to me you have a completely mistaken understanding of how
variables work in Python.  This is one of the reasons why I have said in
the past, erroneously, that Python does not have variables.  It does of
course but not in the same way as C or Pascal.  In those languages names
are source-code abstractions only, and irrelevant to the compiler and
machine code.  C and Pascal define variables as boxes that can be
written to.  Not so in Python.
"

Well you basically said it yourself:

" irrelevant to the compiler and machine code".

That's kinda nice about a high level language.

Programmer does not need to understand anything below the language.

A python programmer shouldn't need to understand a damn thing to write:

A  =  10
A = A + 1
print A

However for sake of your discussion I will continue your arguments below,
since I get the impression you guys are clueless how to change python
implementation ;)

"
In Python most common objects are immutable. Meaning they can never
change or be overwritten.  They are bound to names.  This binding is
what makes names look like and act like traditional variables.

The secret to understanding the global keyword is to understand how
Python namespaces work.  The statement "a=5" does not assign a 5 to the
box called "a."  Rather it binds the name "a" to the "5" object, which
is immutable and called into existence by the interpreter
implementation.  Subsequently "a=6" disconnects a from the 5 object,
casting the 5 object loose to be reclaimed in some fashion that doesn't
matter at this point.  "a" is then rebound to a new object, 6.
"

What happens for following code:

A=123456789011

Are you going to claim it's going to bind to all these numbers and then also
multiple times ?


"all these numbers"? I see only one number there.

At runtime, it'll bind the name to the number, putting the pair into a
dict. (Actually, in a function, it can determine the names of all of
the local variables, so it uses 'slots' instead, as an optimisation.)


Sounds a bit shady ?! ;)

Perhaps python considers it a string ?

Python applies math to strings ?

Sounds a bit slow... therefore perhaps you're wrong...


Why would _he_ be wrong? _He_ never claimed any such thing!


"
When doing a look-up on a name, the interpreter first checks the local
scope's dictionary and if it does not find the name there there, goes to
the outer scope and so forth until you get to the module global
namespace.  So we don't need any special keywords to do Pascal-style
constants.  We just define them in the module and they work.  Usually we
name them in all caps so we have a bit of a convention as to where they
come from.  And yes we're talking about looking up strings in a
dictionary here.
"

So big deal, solution is easy to see, invert interpreter logic:

Everything declared is "not constant".

Everything declared as "constant" suddenly becomes constant.

And thus everything declared as not constant behaves the same way as
"global", problem solved.

"
When binding a name to an object, the interpreter always binds a name in
the local namespace, unless the global keyword has been used previously
and then it goes right to the global namespace.  As has been said
numerous times on this thread, how else would the interpreter do this?
There simply isn't any other way that makes sense. Certainly you haven't
made the case for it, seeing as you have some fundamental
misunderstandings about variables in Python.
"

You didn't completely explain how the global namespace becomes writeable ?
or re-bindeable ?

(It seems not necessary to explain it you implement the constant idea, as
explained above already).

Do I have to assume that global namespace is "re-bindeable" = writeable ?

"
You keep saying things like "writing to a variable" or "declared
variables" which just don't apply to Python because that's not how
Python variables work.  It may appear this way on the surface, but the
differences are subtle yet important.  Namespaces are written to, not
variables, some objects can be mutated. Names are bound to objects, but
variables are not declared, as a name can be bound to an object of any type.
"

Well again you didn't explain how using namespaces suddenly lead to
"rewritable" and/or "rebinding"


Namespaces don't "become writeable".

The purpose of "global" is to tell the compiler that this name should
be bound in the global namespace, not the local namespace.


if A is declared as global as follows:

global A

and then code is written as follows:

A = 10
A = 20

def Test()
 global A = 30
 return

How does this make A "rewriteable" ? Or "rebindable" to 30 ?

"
Namespaces are powerful constructs that give Python 

Re: Python handles globals badly.

[MRAB]

On 2015-09-12 17:29, Dennis Lee Bieber wrote:

On Sat, 12 Sep 2015 05:11:46 +0100, Mario Figueiredo 
declaimed the following:


On 12-09-2015 03:35, Mark Lawrence wrote:


Ada took over from CORAL in the UK, at least in military projects.  It
was also used in the aircraft industry. My old work mates tell me that
its completely died a death, to be replaced by C++.  Someone please
remind me never to fly again.


Alright. But then someone should probably have reminded you that a long
time ago.

Maybe you missed it when an Ada integer overflow bug produced one of the
most expensive software bugs in history by crashing the Ariane 501
rocket and its 4 cluster sattelites payload.



As I recall, the software did exactly what it was supposed to do in
that situation...

But no one had tested the algorithm with the rate of change the Ariane
5 could produce -- so an algorithm that was developed for, and safe with,
the smaller Ariane suddenly went "something's wrong -- abandon ship"

Nothing inherent in the language...


What would C++ have done in the same situation? Would Ariane still have
failed? Probably...

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Mario Figueiredo]

On 12-09-2015 18:09, MRAB wrote:
> On 2015-09-12 17:29, Dennis Lee Bieber wrote:
>> But no one had tested the algorithm with the rate of change the
>> Ariane
>> 5 could produce -- so an algorithm that was developed for, and safe with,
>> the smaller Ariane suddenly went "something's wrong -- abandon ship"
>>
>> Nothing inherent in the language...
>>
> What would C++ have done in the same situation? Would Ariane still have
> failed? Probably...
> 

And that's exactly the point. C++, or Ada, for that matter have decades
old documented best practices and code patterns to deal with those
aspects of the language that can induce in error. Integer overflow is a
well documented problem. And relying on it, is documented as a bad idea
for several reasons, including the changes in the underlying system that
eventually led to Ariane incident.

For all that is worth, C++ issues with all sorts of overflows and
unchecked memory are documented from the very first beginning of the
language. Same with C and same with Ada own particular issues.

A safe(r) language just presents different ways of shooting one's foot.
We can discuss how much of a bad boy C++ is, but at the end of the day
programers will just keep on make mistakes and eventually on those very
areas the safer language doesn't provide a safety net.

One can argue that by offering more ways to shoot one's foot, C and C++
are more dangerous to use than other considered safer languages. But
that doesn't gel with the operative history of C or C++ that are running
mission critical systems, from stock markets to nuclear power plants.
These languages just demand a different breed of programmers and
different methods of testing.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Emile van Sebille]

On 9/11/2015 10:22 PM, Skybuck Flying wrote:



I didn't learn anything from this posting, sorry ! ;)


I'm seeing a pattern here...

Emile



--
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Mark Lawrence]

On 12/09/2015 17:24, Dennis Lee Bieber wrote:

On Sat, 12 Sep 2015 03:35:00 +0100, Mark Lawrence 
declaimed the following:



Ada took over from CORAL in the UK, at least in military projects.  It
was also used in the aircraft industry. My old work mates tell me that
its completely died a death, to be replaced by C++.  Someone please
remind me never to fly again.


Still used on some of the boxes being made... (I've just spent a month
investigating problem reports for a software release).

Granted, that's an Ada 83 cross compiler running on VAX/VMS itself
running on a Windows server box with an emulator. It would cost way too
much money to try to recompile with, say, GNAT Pro -- as the entire suite
(including the compiler) would have to be recertified for airworthiness.



Having seen the comments on this thread I think some of the participants 
need to be recertified for programmerworthiness.


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

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Michael Torrie]

On 09/11/2015 11:22 PM, Skybuck Flying wrote:
> I didn't learn anything from this posting, sorry ! ;)

I too am not surprised.  You're not here to learn, either about
programming language theory, or about Python apparently.

I would refer you to a good programming language theory class, but I
suspect you're not interested in learning formal definitions and theory.
 The terms I used here are all from formal programming language theory,
particularly the term "binding." If you're interested in it, this topic
makes for a fascinating class. I loved my programming language theory
class at uni.  We used scheme to explore language construction and to
build our own programming language.  Cool stuff.

I'm truly sorry you aren't interested in learning the underlying
theories of things, or the reasons for certain aspects of the language.
 To me Python's ability to enable so many different programming
paradigms, and to bring some of the coolest parts of LISP and Scheme to
a language for the masses is really cool.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Chris Angelico]

On Sat, Sep 12, 2015 at 4:25 PM, Random832  wrote:
> Chris Angelico  writes:
>> Here. Ned Batchelder explains it better than I can.
>
> See, those diagrams are perfect (well, almost, I think the names should
> have square boxes too). They're arrows. They *point* at
> things. *Pointers*.
>
> The boxes are variables. The circles represent special boxes
> (implemented in C or Java or whatever) that hold things other than
> pointers and therefore can't be used as Python variables.

Okay, okay, you've won. They're pointers. Now, try to do anything with
them. They *instantly* devolve to their referent objects, which means
you cannot do anything with the pointer at all. Congratulations,
pointers do not exist.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Steven D'Aprano]

On Sat, 12 Sep 2015 01:03 am, Ian Kelly wrote:

> On Fri, Sep 11, 2015 at 2:42 AM, Steven D'Aprano 
> wrote:
[...]
>> Almost. If it's never assigned within the function, then it is looked up
>> according to the non-local scoping rules:
>>
>> - closures and enclosing functions (if any);
>> - globals;
>> - builtins;
>>
>> in that order.
> 
> I excluded non-locals intentionally, but if you want to be pedantic
> about it, then that's still not quite right. Non-locals are indeed
> identified by the compiler and compiled with the
> LOAD_DEREF/STORE_DEREF opcodes (rather than the _GLOBAL and _FAST
> variants used by globals and locals, respectively). 

Ah, nice, yes I forgot about that, thanks for the correction.


> The compiler 
> doesn't make any such distinction between globals and builtins
> however, as that can only be determined at run-time.
> 
>> There's also a bunch of specialised and complicated rules for what
>> happens if you make a star import ("from module import *") inside a
>> function, or call eval or exec without specifying a namespace. Both of
>> these things are now illegal in Python 3.
> 
> Huh?
> 
 exec("x = 42")
 x
> 42
 exec("x = 43", None, None)
 x
> 43
> 
> That's in Python 3.4.0. Maybe I don't understand what you mean by
> "without specifying a namespace".

Inside a function star imports are illegal in Python 3:

py> def f():
... from math import *
...
  File "", line 1
SyntaxError: import * only allowed at module level


My recollection was incorrect about exec. You can still exec inside a
function, but it may have no effect:

py> def f():
... x = 1
... exec("x = 2")
... return x
...
py> f()
1

You can specify locals, but it doesn't help:

py> def f():
... x = 1
... exec("x = 2", globals(), locals())
... return x
...
py> f()
1


However, in Python 2, Python tried hard to make exec work:

py> def f():
... x = 1
... exec("x = 2")
... return x
...
py> f()
2


I don't recall all the details, but in Python 2 functions could use two
different schemes for local variables: the regular, optimized one using
memory slots, and a dict-based one that came into play with exec. So we
have this:

py> def g():
... a = 1
... exec("b = 2")
... return (a, b)
...
py> dis.dis(g)
  2   0 LOAD_CONST   1 (1)
  3 STORE_FAST   0 (a)

  3   6 LOAD_CONST   2 ('b = 2')
  9 LOAD_CONST   0 (None)
 12 DUP_TOP
 13 EXEC_STMT

  4  14 LOAD_FAST0 (a)
 17 LOAD_NAME0 (b)
 20 BUILD_TUPLE  2
 23 RETURN_VALUE



`a` is a regular, optimized local looked up with LOAD_FAST; but `b` gets the
same old LOAD_NAME used for globals and built-ins.


In Python 3.3, that same function uses LOAD_GLOBAL for `b`, even though the
variable does actually exist:


py> dis.dis(g)
  2   0 LOAD_CONST   1 (1)
  3 STORE_FAST   0 (a)

  3   6 LOAD_GLOBAL  0 (exec)
  9 LOAD_CONST   2 ('b = 2')
 12 CALL_FUNCTION1 (1 positional, 0 keyword pair)
 15 POP_TOP

  4  16 LOAD_FAST0 (a)
 19 LOAD_GLOBAL  1 (b)
 22 BUILD_TUPLE  2
 25 RETURN_VALUE
py> g()
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 4, in g
NameError: global name 'b' is not defined



The conclusion I draw from all this is that the rules governing local
variables in Python are a mess :-)


-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Chris Angelico]

On Sat, Sep 12, 2015 at 3:35 PM, Random832  wrote:
> Mark Lawrence  writes:
>> Let's put it another way, in the 15 years I've been using Python I do
>> not recall any experienced Python programmer using "pointer", so what
>> makes you think, in 2015, that you are correct and everybody else is
>> wrong?  I still say that everything in Python is an object, and should
>> add that it has one or more things, "names", that are associated with
>> it.  Hence my preferred analogy about the sticky note.
>
> So is player3[3] also a name, a sticky note? What if we copy player3 to
> another name; does it get two sticky notes, player3[3] and foo[3]? Your
> "sticky note" analogy doesn't unify variables/names/whatever you want to
> call them with other places that you can assign stuff to, and it implies
> that the objects themselves have knowledge of their "names", and that
> names are global (if I have two functions each with a result variable,
> does that mean there are two different result sticky notes?)

Whatever you want to use to describe a name-binding reference, the
exact same thing applies to a list element or anything else. If your
analogy is strings tied to sheets of paper, with sticky notes on the
ends of strings to represent actual names, then you have similar
strings connecting list elements to their referents. (The sticky notes
aren't actually part of the objects, and you just have to understand
that you can't trace a string "backwards", only "forwards"; there's no
way to start with an object and ask "what refers to this?".)

Here. Ned Batchelder explains it better than I can.

http://nedbatchelder.com/text/names1.html
https://www.youtube.com/watch?v=_AEJHKGk9ns

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Random832]

Chris Angelico  writes:
> Here. Ned Batchelder explains it better than I can.

See, those diagrams are perfect (well, almost, I think the names should
have square boxes too). They're arrows. They *point* at
things. *Pointers*.

The boxes are variables. The circles represent special boxes
(implemented in C or Java or whatever) that hold things other than
pointers and therefore can't be used as Python variables.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Jonas Wielicki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On 08.09.2015 16:31, Ian Kelly wrote:
> On Tue, Sep 8, 2015 at 5:55 AM, 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. 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.

To be fair, that is not entirely true. In Pascal, there are three
cases (you can argue that this doesn’t improve anything):

(a) statically allocated arrays where the programmer chooses the
bounds, e.g.

  const
InBitData: array [1..4] of Integer = (128, 32, 16, 64);


(b) strings, which start at 1, as historically, the length of the
string was stored at position 0; pascal uses length-delimiting instead
of NUL-delimiting.

(c) dynamically allocated arrays which always start at 0.

So let aside the historical cruft from Strings, Pascal uses zero-based
indexing unless told otherwise.

regards,
jwi
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJV8+eJAAoJEMBiAyWXYliKe4gP/ipqzEWQvp3jDwINm8Ofdlpc
4ngOlwUQxAo25DNPG1qnT06iRj+CN5wpJDr5CgYW0Hb6nkoLzlJG6XDqK7S3BAQy
msTvDlZFwnWEJ7AQcLP1RCYNy1Z0O9j+/XAEWD7wDk02wlZnEtrIWXGvxpR98fjx
HOKLxHHEQsi4+qhgpQJzqXHEi5UozN52f6AC1B7JGAwueCx8+gjAeIGHwcYQXFRZ
L78pBRZQpwoLBumylShUOO8HvouHSyRwfMF+we907oDAgWREnmwu82Q2jOHqAPXt
UDMlyi2hueQXNvJFTqCfdkOAEcDk/Jn2Agx7w5A5k2oHptK8uwS+2/SghmPwPZuh
G+Gqi5+FxSEkQDJBvsU9dUwCy/OIBm2kxGlaVB+MRN8LxvLVYsx5DdZbIlce9VVn
SrehJPo6TnFBsgpRsjr9Ahpnmh769ej/jcyfKDgYb6tXW0XANlPUQ/nGxtNES4hJ
l7ds3VE/n91WU/cQlTKB9EviteMDit0iqYRlPOwV1QPNWx0z2a+/nMGyRH/Baaqj
r1rdmzWkks+vMmkYd8Yl+IlHmnWUBM/gI4qh9I1mA+iyH/n/Se9SdSISLqmccdoB
0ph1UmM3Tz/vGvguVdaF8WJzpL2sdtaR4ibjeN5IhYyhzREOFnJkKvofxfYNm3TF
kCSAK5/Q6qPg4s9X2nCt
=KixQ
-END PGP SIGNATURE-
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Mario Figueiredo]

On 12-09-2015 05:38, Mark Lawrence wrote:
> 
> Nothing to do with this being untested software then?  Actually it was
> so I'd put that down to a programmer error.  "The code always worked
> before so it's bound to work this time".  Such a pity that this
> particular launch wasn't the same as anything done previously.

I am not even sure what you are saying. Can't be that C++ bugs are not
not caused by programmer errors. Because C++ is actually used in
numerous mission critical systems.

But anyways. If you are that scared of C++ it is indeed best you don't fly.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Chris Angelico]

On Sat, Sep 12, 2015 at 1:57 AM,   wrote:
> On Fri, Sep 11, 2015, at 11:55, Chris Angelico wrote:
>> On Sat, Sep 12, 2015 at 1:49 AM, Ian Kelly  wrote:
>> > Ah, that makes sense. It's writing into the dict that is created and
>> > returned by locals(), but not actually updating the frame locals which
>> > are the source of truth.
>>
>> Yeah... but it only makes sense to people who understand the
>> implementation. It's certainly not a logical and sane behaviour that
>> would be worth documenting and using.
>
> What else would you document? Reading from them is a reasonable thing to
> do, and works. Writing to them is a reasonable thing to want to do, but
> won't work, so you need to document that it doesn't work.

Documenting that "it doesn't work" seems fine. Documenting the
specific behaviour (that it gives you a sort of "shadow" locals, into
which you can write, but which won't persist past the execution of
that block of code) seems pointless. Especially since this behaviour
is implementation-dependent anyway.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Ian Kelly]

On Fri, Sep 11, 2015 at 10:04 AM, Chris Angelico  wrote:
> On Sat, Sep 12, 2015 at 1:57 AM,   wrote:
>> On Fri, Sep 11, 2015, at 11:55, Chris Angelico wrote:
>>> On Sat, Sep 12, 2015 at 1:49 AM, Ian Kelly  wrote:
>>> > Ah, that makes sense. It's writing into the dict that is created and
>>> > returned by locals(), but not actually updating the frame locals which
>>> > are the source of truth.
>>>
>>> Yeah... but it only makes sense to people who understand the
>>> implementation. It's certainly not a logical and sane behaviour that
>>> would be worth documenting and using.
>>
>> What else would you document? Reading from them is a reasonable thing to
>> do, and works. Writing to them is a reasonable thing to want to do, but
>> won't work, so you need to document that it doesn't work.
>
> Documenting that "it doesn't work" seems fine. Documenting the
> specific behaviour (that it gives you a sort of "shadow" locals, into
> which you can write, but which won't persist past the execution of
> that block of code) seems pointless. Especially since this behaviour
> is implementation-dependent anyway.

It's documented in the standard library docs:
https://docs.python.org/3.4/library/functions.html#exec

I think that's probably sufficient.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Rustom Mody]

On Friday, September 11, 2015 at 9:27:46 PM UTC+5:30, rand...@fastmail.us wrote:
> On Fri, Sep 11, 2015, at 11:55, Chris Angelico wrote:
> > On Sat, Sep 12, 2015 at 1:49 AM, Ian Kelly  wrote:
> > > Ah, that makes sense. It's writing into the dict that is created and
> > > returned by locals(), but not actually updating the frame locals which
> > > are the source of truth.
> > 
> > Yeah... but it only makes sense to people who understand the
> > implementation. It's certainly not a logical and sane behaviour that
> > would be worth documenting and using.
> 
> What else would you document? Reading from them is a reasonable thing to
> do, and works. Writing to them is a reasonable thing to want to do, but
> won't work, so you need to document that it doesn't work.

This is actually an old elusive holy grail -- first class environments.
In denotational semantics the two tools used to model variables and control-flow
respectively are environments and continuations.
The Scheme inventors were brave enough to mandate first-class continuations
but could not make the courage for first-class environments.
So every Scheme dialect introduces 1½ class envs in a ½-assed inconsistent way

Likewise python's locals-dicts and (I am guessing) most languages with some
commitment to first-classness
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Skybuck Flying]

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


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


--
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Antoon Pardon]

Op 10-09-15 om 16:21 schreef Michael Torrie:
> On 09/10/2015 01:27 AM, Antoon Pardon wrote:
>> Op 09-09-15 om 19:55 schreef Steven D'Aprano:
>>> 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?
>> What is wrong with that?
> Makes for a common error of putting an assignment in a conditional
> expression like:
>
> if (a=4) this_is_always_true();

No it doesn't. You confuse a semantic characteristic with the
specifix syntax that was chosen to express it in C.

Should C have chosen '<-' as token for assignment, that error
would have been far less common.

The error is also facilitated because C doesn't have booleans
and so everything can be used as one. If C would have had
proper booleans and only allowed those as conditions in if
and while statements, most of those errors would have been
caught too, because the expression a=4 wouldn't produce a
boolean.

> GCC will give you a warning over that these days.  But many C
> programmers still adopt a notation of
>
> if (4 == a) do_something();
>
> to protect them if they accidentally leave out one =.  If assignment was
> not an expression, then the compiler would properly error out every time
> you used a solitary = in the conditional of an if statement.

A language can provide this kind of protection and still allow
assignment as an expression. A lousy syntactical choice, doesn't
invalidate a particular choice in semantics.

> Python strikes a good compromise.  You can chain = in an assignment
> statement, but you can't use them in a conditional expression.

Python could have chosen other options, like a different assignment
token, like providing a proper boolean type and expection such a type
in a condition context. It could reverse the assignment so that you
would have to write: expression = var, so that if someone accidently
writes if var = expression instead of if var == expression, that would
have been caught. It could combine some of these options.

Now you possibly don't like these possibilities, but they show there
are multiple syntactical possibilities that all allow for assignment
as expressions, and that are less vulnerable than C for a specific
kind of error.

-- 
Antoon Pardon

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Steven D'Aprano]

On Fri, 11 Sep 2015 10:35 am, Ian Kelly wrote:

> On Thu, Sep 10, 2015 at 4:25 PM,   wrote:
[...]
>> So the compiler knows the distiction between global and local already.
> 
> As we've said before, it doesn't. The compiler's current rules are
> fairly simple:
> 
> 1) If it's in the function's argument list, it's an argument (and
> therefore local).
> 2) If it's explicitly declared global, then it's global.
> 3) If it's never assigned within the function, then it's global.

Almost. If it's never assigned within the function, then it is looked up
according to the non-local scoping rules:

- closures and enclosing functions (if any);
- globals;
- builtins;

in that order.


> 4) Otherwise, it's local.

"Otherwise" meaning "if it is assigned to", except that "del" counts as an
assignment. That is:

def spam():
del x

makes x a local variable inside the function spam.


There's also a bunch of specialised and complicated rules for what happens
if you make a star import ("from module import *") inside a function, or
call eval or exec without specifying a namespace. Both of these things are
now illegal in Python 3.

And lastly, in Python 3 only, there is also a nonlocal declaration which
works like global except it applies only to closures and enclosing
functions.


>> Another proof about identation:
>> The parser can recognise identation with tabs and spaces.
> 
> You can use tabs *or* spaces. 

In Python 3.

In Python 2, you can mix tabs *and* spaces, and Python will try to guess
what you mean. This causes more trouble than it is worth, and is removed in
Python 3.


[...]
> I really doubt that you're going to gain any traction with this one,
> because the decision that was made with Python 3 was to make the
> compiler *more* rigid about not mixing tabs and spaces, not less.

Correct.

[...]
>> Who is responding or has responded?
>> Extreme Programmers, Python-Hardliner, Python-Evangelists, ... .
>> Presumably no core Python Programmers (wrting compiler and standard
>> library stuff)
> 
> Ad hominem.

For the record, I am the author of the statistics module in Python 3.4, and
Terry Reedy is the very active maintainer of IDLE. If I have missed anyone,
my apologies. So, yes, there are core developers here.

(Although not any of the senior core devs, as far as I know.)



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Chris Angelico]

On Fri, Sep 11, 2015 at 6:42 PM, Steven D'Aprano  wrote:
>>> Who is responding or has responded?
>>> Extreme Programmers, Python-Hardliner, Python-Evangelists, ... .
>>> Presumably no core Python Programmers (wrting compiler and standard
>>> library stuff)
>>
>> Ad hominem.
>
> For the record, I am the author of the statistics module in Python 3.4, and
> Terry Reedy is the very active maintainer of IDLE. If I have missed anyone,
> my apologies. So, yes, there are core developers here.
>
> (Although not any of the senior core devs, as far as I know.)

I don't know what the definition of "senior core dev" would be.
Checking the Experts List [1] shows you and Terry both, as does the
list of committers [2] (and it has me as well, although that's because
I wear a PEP Editor hat, so I don't count as even a non-senior core
dev). Is there an "inner circle" of people Guido trusts more than
"just ordinary core devs"? I rather suspect not, but maybe I'm wrong.

Hacking on CPython without core dev status is actually pretty easy.
I've done it. (Added a "while ... as name:" syntax, just to see how
hard it would be. Conclusion: It's not hard at all.) If anything,
that's a _lower_ bar to clear than "idiomatic Python programmer",
because anyone can hack on C code without understanding the goals and
beauties of the Python language. So I'm really not sure what the
original complaint was about, nor how to answer it.

ChrisA

[1] https://docs.python.org/devguide/experts.html#experts
[2] https://hg.python.org/committers.txt
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Rustom Mody]

On Friday, September 11, 2015 at 10:04:25 AM UTC+5:30, Marko Rauhamaa wrote:
> Ian Kelly :
> 
> > You can use tabs *or* spaces. If you want to mix the two, then there
> > would need to be some official decision made about how many spaces
> > compose a tab, and then everybody who wants to use tabs would have to
> > configure their editors to conform to that decision, or risk breaking
> > their code. Some people like to indent two spaces. Some people like to
> > indent four spaces. On the other hand, the de facto standard for
> > terminal tab width is eight spaces. However, virtually nobody prefers
> > eight spaces of indentation. So the question is which standard are you
> > going to adopt, and which groups are you going to upset?
> 
> Indentation preferences and the interpretation of TABs are two separate
> things.

Required reading
http://www.jwz.org/doc/tabs-vs-spaces.html

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[tdev]

Reflecting latest answers to global and "proposals"


Ad hominem. 
There is a slogan: "There are always two persons involved"
This I dont want talk about. I dont go into such a discussion.
It seems more a problem of misinterpretations.


Proofs. 
Not really proofs. I meant more or less proofs. Proofs in "Proofs".
Proofs from my point of view or you can say from my understanding 
(or say also high level position view) and from the answers given so far


Samples 
(+main discussion "global"). 
Samples are often as text only in this thread. 
I think it is clear when you have followed the thread.
But the thread has now taken some new directions.
Yes, it is litte awkward searching back now.

But you can say, the "general" sample is:
You have to specify global that the compiler can distinguish
between local and global
Other words: global is needed to distinct global from local.

But this is "not" true.
You specify global cause you want write access.
Even the rules specified proves it:

> 1) If it's in the function's argument list, it's an argument (and
> therefore local).
> 2) If it's explicitly declared global, then it's global.
> 3) If it's never assigned within the function, then it's global.
> 4) Otherwise, it's local.

Take step 2 out than it is again recognized as global.  
So the global keyword is not needed to distinguish global from local.
Rule 3 proves it.



Identation.
It is stated
> It is correct that there have to be a decision for spaces or tabs.

With that I meant clearly no mixing of tabs and spaces.
So forget tabs (tabs changed to spaces) and take spaces.

The meaning is clearly:

def x():
  pass 2 spaces to the right

def y():
   pass3 spaces to the right


Surprisingly this runs now.
Sometimes I run into indentations errors similiar to sample above for no 
reasons 
(maybe cause of existing spaces on the end of a line - next occurences I will 
try to note it down)
But I have to remove this proposal for now.
Sorry.


PEP.
As previously stated I am not in the position (and/or knowledge)
to write a PEP. I wanted only to start a general (high-level point of view) 
discussion about it, in the hope there is somehow an agreement which starts 
somehow a PEP.

But from answers in this list I would say: No chance.
Practically no agreements. This I have to accept, although 
I cannot understand it (reasons given in previous post:
it was/is nothing more than to enhance and give even more flexibility 
to the language as with all the other features already available in 
parallel for the same reasons).


Conclusion.
I will use Python, but never become a Pythonier, 
although quite conform with its philosophy "One best way".
But even a traditional switch is denied, although much clearer
in reading and writing than any if-else construct.
I can and will not understand it.


Thanks for your answers.


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Skybuck Flying]

Hello,

I'll add some arguments to the global discussion for you.

First a look back at the origin of this "global" keyword, basically it's 
idea behind it, which is probably a flawed assumption.


The origin/purpose of global as I now understand it is to give "write" 
access to globally declared variables.


This is first of all something unusual. Which other programmer language has 
this weird/whacky inconsistency ?


In general I believe inconsistent behaviour should be prevented in 
programming languages.


Anyway... having written/said that... there is a flawed assumption with this 
idea.


The assumption is that: "writing to globals is bad and can lead to bugs".

The further assumption is that: "denieing write access to globals prevents 
bugs".


Especially the last assumption is just plain wrong.

Not giving write access to globals can also lead to even much harder to find 
bugs.


The unaware programmer may assume that a global was changed, while in 
reality it was not.


How will such a bug be found ? Very hard to do in general, especially in an 
interpreter like python... where these bugs will need to be catched at run 
time.


Catching these bugs at runtime is far more difficult than bugs/errors which 
show up during compile time.


Thus forgetting "global" is going to be a far worse mistake... then actually 
overwritten or re-using some global accidently.


This kind of mistake can be checked by the programmer without requiring 
runtime inspection.


As soon as the programmer notices that some global is being re-used 
abusively the programmer can correct the situation.


With forgetting the global keyword not so... much harder to find.

Only possibility is to add "global" everywhere out of paranoya... which 
prevents the programmer from having to inspect every possibly line of code.


The global/write access requirement right now basically forces the 
programmer to check EVERY line of python code to see if a global is being 
written to which actually does not have the required write permission ?!?


How can anybody in their right mind think that is is somehow an improvement 
? It simply is not... unless the interpreter at runtime would start to BEEP 
or show ERROR messages in some log... that a global is being written too 
which actually does not have WRITE permissions ?


So far I have only used Sikuli to develop in Python... so let me ask a 
question here: Is there ANY Python IDE that actually produces such a warning 
or error message at runtime 


Is there any IDE which outputs:

"Error: GLOBAL variable being written too without WRITE permission ?!?".

How would the interpreter know that it is a global variable ? Well it's 
declared somewhere outside the scope of the function... so that's not the 
issue... issue is missing GLOBAL declaration inside the function... so it's 
more of a "WRITE" permission than "global permission".


So the name itself: "GLOBAL" is somewhat misleading... it's more a "WRITE" 
permission lol.


Just that reason alone is enough to remove "GLOBAL" from python language and 
replace it with: "WRITE".


or if it has to be: "GLOBAL-WRITE".

But any programmer would probably find that ridicilous.

So that basically proves that this GLOBAL requirement in itself is pretty 
ridicilous... though it does give a nice hint that this variable is a global 
variable ?! But is that really necessary ?!?


Perhaps, perhaps not... in PASCAL one would simply look at the top section 
of the function... where all variable must be declared, python lacks this 
feature which is kinda nice... but it does make it a bit problematic to spot 
if something is local or global.


While the next best thing the python programmer can do is: inspect the 
entire function to see if the variable is being written to or read from 
somewhere... but in reality this is no garantuee that it is local or 
global... so hence a little bit of a problem... adding global to the 
language is not really going to solve that... since programmer will have to 
add that manually to a variable... might forget it... and then the variable 
will actually still be a global variable.. and any bug fixer will still need 
to inspect code.


So basically this global requirement doesn't really help that much... as 
some say... it's a bit of a hint... a shitty one for that... it's almost 
like fuzzy logic... 50% chance that it's gonna help... 50% it's not gonna 
help ;) or might even lead to problems if read-only behaviour was actually 
required.


So when it comes to assumptions which bug is worse:

1. Willfully writing to a read-only global variable. (assignment failed-bug)
2. Mistakenly writing to a writeable global variable. (overwrite-bug)

As I already wrote before I think bug1 is much harder to spot then bug 2 by 
pure code inspection.


Ask yourself one question:

How many times does a programmer actually want a "read-only" global variable 
? This seems very weird to me.


Pascal solves this very nicely for "constants" with 

Re: Python handles globals badly.

[MRAB]

On 2015-09-11 22:26, t...@freenet.de wrote:

Reflecting latest answers to global and "proposals"


[snip]


But you can say, the "general" sample is:
You have to specify global that the compiler can distinguish
between local and global
Other words: global is needed to distinct global from local.

But this is "not" true.
You specify global cause you want write access.
Even the rules specified proves it:


1) If it's in the function's argument list, it's an argument (and
therefore local).
2) If it's explicitly declared global, then it's global.
3) If it's never assigned within the function, then it's global.
4) Otherwise, it's local.


Take step 2 out than it is again recognized as global.
So the global keyword is not needed to distinguish global from local.
Rule 3 proves it.


I'd would rephrase 3 and 4:

1) If it's in the function's argument list, it's local.

2) If it's declared global, it's global.

3) If it's assigned within the function, it's local.

4) Otherwise, it's global.



Conclusion.
I will use Python, but never become a Pythonier,
although quite conform with its philosophy "One best way".
But even a traditional switch is denied, although much clearer
in reading and writing than any if-else construct.
I can and will not understand it.


No-one can decide on how it should be written without it looking
syntactically inconsistent in some way compared to the other control 
structures.




Thanks for your answers.




--
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Ian Kelly]

On Fri, Sep 11, 2015 at 3:26 PM,   wrote:
> Ad hominem.
> There is a slogan: "There are always two persons involved"
> This I dont want talk about. I dont go into such a discussion.
> It seems more a problem of misinterpretations.

I think you misunderstand my comment. The paragraph that I was
responding to commits the ad hominem logical fallacy by supposing that
the credentials of the person making an argument have any bearing on
the validity of the argument. It therefore is dismissed as being
poorly reasoned. I point this out not to criticize, but to point out
that your argument is fallacious.

> But you can say, the "general" sample is:
> You have to specify global that the compiler can distinguish
> between local and global
> Other words: global is needed to distinct global from local.

This is not what I would consider a sample. I thought you were
referring to actual code examples demonstrating something.

> But this is "not" true.
> You specify global cause you want write access.
> Even the rules specified proves it:
>
>> 1) If it's in the function's argument list, it's an argument (and
>> therefore local).
>> 2) If it's explicitly declared global, then it's global.
>> 3) If it's never assigned within the function, then it's global.
>> 4) Otherwise, it's local.
>
> Take step 2 out than it is again recognized as global.
> So the global keyword is not needed to distinguish global from local.
> Rule 3 proves it.

Rule 3 works because it's generally safe to assume that a variable
that is never assigned locally can't be local; any attempt to access
it would result in an UnboundLocalError. (I say "generally" because
this assumption only holds as long as it's not possible to set locals
via eval or by updating locals(). That's true in the C implementation
of Python but not necessarily true in other implementations.)

Rule 3 doesn't imply that the compiler is capable of distinguishing
globals from locals. It's a guess based on a rule of thumb. So it's
less accurate to say that "you specify global cause you want write
access" and more accurate to say that "you specify global in cases
where the compiler can't guess it without assistance". It just so
happens that the two line up with one another.

> Surprisingly this runs now.
> Sometimes I run into indentations errors similiar to sample above for no 
> reasons
> (maybe cause of existing spaces on the end of a line - next occurences I will 
> try to note it down)
> But I have to remove this proposal for now.
> Sorry.

Yes, you can already choose between tabs or spaces for indentation.
You just can't mix them within the same code block.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Random832]

Mark Lawrence  writes:
> My favourite analogy for Python names, the sticky note, here
> https://mail.python.org/pipermail/tutor/2006-October/049767.html

Is player3[3] also a sticky note? Wouldn't the note have to have the id
of player3 written on it somehow? Should the player3 sticky note have
the id of the global namespace that "player3" is valid in written on it?

I like my analogy better because it means both player3 and (the list we
call player3)[3] are both the *same* kind of thing: boxes that have
pointers in them (i.e. variables).

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Mario Figueiredo]

On 12-09-2015 03:35, Mark Lawrence wrote:
>
> Ada took over from CORAL in the UK, at least in military projects.  It
> was also used in the aircraft industry. My old work mates tell me that
> its completely died a death, to be replaced by C++.  Someone please
> remind me never to fly again.

Alright. But then someone should probably have reminded you that a long
time ago.

Maybe you missed it when an Ada integer overflow bug produced one of the
most expensive software bugs in history by crashing the Ariane 501
rocket and its 4 cluster sattelites payload.

But sure. Don't let that get in your way of thinking there are safe
languages.


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Mark Lawrence]

On 12/09/2015 05:06, Random832 wrote:

Mark Lawrence  writes:


On 12/09/2015 01:11, random...@fastmail.us wrote:
If everything in Python is an object, how can it assign a pointer?
Especially how do Jython and IronPython assign pointers?


The Java and .NET runtimes also have pointers, they just don't [usually]
call them pointers, just like Python doesn't call them pointers (a match
made in... well, somewhere starting with an H, for sure).

Honestly, whether you want to call the thing a pointer or a reference,
you have to call it *something*, and I think "reference" is a worse fit
based on its connotations from C++. Whatever you call it, it's an arrow
on a diagram.



I think pointer is even worse because of its connection with C and hence 
cPython.  What is wrong with object if that is the only thing Python 
knows about?


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

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Mark Lawrence]

On 12/09/2015 05:11, Mario Figueiredo wrote:

On 12-09-2015 03:35, Mark Lawrence wrote:


Ada took over from CORAL in the UK, at least in military projects.  It
was also used in the aircraft industry. My old work mates tell me that
its completely died a death, to be replaced by C++.  Someone please
remind me never to fly again.


Alright. But then someone should probably have reminded you that a long
time ago.

Maybe you missed it when an Ada integer overflow bug produced one of the
most expensive software bugs in history by crashing the Ariane 501
rocket and its 4 cluster sattelites payload.

But sure. Don't let that get in your way of thinking there are safe
languages.



Nothing to do with this being untested software then?  Actually it was 
so I'd put that down to a programmer error.  "The code always worked 
before so it's bound to work this time".  Such a pity that this 
particular launch wasn't the same as anything done previously.


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

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Random832]

Mark Lawrence  writes:
> How do I access these pointers?  Is there a builtin called pointer()
> that's analogous to id()?

You access them *all the time*. They are the *only* thing you access.

But if you want... pointer = lambda x: return x

> I'll ask again, where do pointers come into
> the Jython and IronPython models?  How do I access their pointers, the
> same builtin?  The fact that the underlying implementation language
> has some terminology that it uses, has no bearing on the actual
> language being implemented.

I am not using "pointer" as language-specific terminology, I am using it
as *the* name of the concept we are talking about. The Java and .NET
runtimes *don't* use that terminology, but they still *actually* have
pointers, in the same way that Python does.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Mark Lawrence]

On 12/09/2015 06:35, Random832 wrote:

Mark Lawrence  writes:

Let's put it another way, in the 15 years I've been using Python I do
not recall any experienced Python programmer using "pointer", so what
makes you think, in 2015, that you are correct and everybody else is
wrong?  I still say that everything in Python is an object, and should
add that it has one or more things, "names", that are associated with
it.  Hence my preferred analogy about the sticky note.


So is player3[3] also a name, a sticky note? What if we copy player3 to
another name; does it get two sticky notes, player3[3] and foo[3]? Your
"sticky note" analogy doesn't unify variables/names/whatever you want to
call them with other places that you can assign stuff to, and it implies
that the objects themselves have knowledge of their "names", and that
names are global (if I have two functions each with a result variable,
does that mean there are two different result sticky notes?)

It doesn't matter that a pointer isn't what it's *called*, it's what it
*is*. And it's not an object, because you can copy it to more than one
place with only one object.



There is NO CONCEPT in Python of a "pointer".  player3[3] is the fourth 
item of a list or similar, or a reference to something in a dictionary, 
but regardless of the type it is an object that has a name player3. 
player3 then gets copied to foo.  Both names are referring to the same 
object.  It certainly DOES NOT imply anything about objects having 
knowledge of their names and it DOES NOT say anything about the scope of 
names.  As for "two functions each with a result variable" I haven't the 
faintest notion what you could be talking about, would you please 
explain for the benefit of everybody reading this thread.


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

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Terminology: “reference” versus “pointer” (was: Python handles globals badly.)

[Ben Finney]

Random832  writes:

> Honestly, whether you want to call the thing a pointer or a reference,
> you have to call it *something*, and I think "reference" is a worse
> fit based on its connotations from C++. Whatever you call it, it's an
> arrow on a diagram.

With the significant difference that “pointer” implies that it has its
own value accessible directly by the running program, such as a pointer
in C.

That's different from a “reference”, which to my understanding implies
the running program does *not* normally have direct access to it as a
distinct value. The only way you can use a reference is to get at the
object to which it refers.

That's the distinction I've been reying on for years, anyway: Python's
names are references, collections are collections of references, etc.
They aren't pointers because you can't get them as a distinct value; you
can only use them to refer to the object at the other end.

-- 
 \ “If we don't believe in freedom of expression for people we |
  `\   despise, we don't believe in it at all.” —Noam Chomsky, |
_o__)   1992-11-25 |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Mark Lawrence]

On 12/09/2015 05:16, Random832 wrote:

Mark Lawrence  writes:

My favourite analogy for Python names, the sticky note, here
https://mail.python.org/pipermail/tutor/2006-October/049767.html


Is player3[3] also a sticky note? Wouldn't the note have to have the id
of player3 written on it somehow? Should the player3 sticky note have
the id of the global namespace that "player3" is valid in written on it?

I like my analogy better because it means both player3 and (the list we
call player3)[3] are both the *same* kind of thing: boxes that have
pointers in them (i.e. variables).



For the final time I hope, "pointer" is not appropriate for Python, so 
I'll stick with the sticky note analogy, thanks all the same.


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

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Random832]

Mark Lawrence  writes:
> I think pointer is even worse because of its connection with C and
> hence cPython.  What is wrong with object if that is the only thing
> Python knows about?

Because the object is the *thing the arrow points at*. You don't have
two objects when store the same object in two variables (names, list
slots, whatever), but you do have two pointers.

And they *are* pointers in cPython - so that "connection" is a feature,
not a bug.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Mark Lawrence]

On 12/09/2015 05:34, Random832 wrote:

Mark Lawrence  writes:

I think pointer is even worse because of its connection with C and
hence cPython.  What is wrong with object if that is the only thing
Python knows about?


Because the object is the *thing the arrow points at*. You don't have
two objects when store the same object in two variables (names, list
slots, whatever), but you do have two pointers.

And they *are* pointers in cPython - so that "connection" is a feature,
not a bug.



How do I access these pointers?  Is there a builtin called pointer() 
that's analogous to id()?  I'll ask again, where do pointers come into 
the Jython and IronPython models?  How do I access their pointers, the 
same builtin?  The fact that the underlying implementation language has 
some terminology that it uses, has no bearing on the actual language 
being implemented.  This seems to me rather important, or have I missed 
something here?


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

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Skybuck Flying]

"Michael Torrie"  wrote in message 
news:mailman.384.1442016089.8327.python-l...@python.org...


On 09/11/2015 03:50 PM, Skybuck Flying wrote:

Something which python does not seem to do currently ?!

So that's weird.

I will leave it at that for now.


"
Seems to me you have a completely mistaken understanding of how
variables work in Python.  This is one of the reasons why I have said in
the past, erroneously, that Python does not have variables.  It does of
course but not in the same way as C or Pascal.  In those languages names
are source-code abstractions only, and irrelevant to the compiler and
machine code.  C and Pascal define variables as boxes that can be
written to.  Not so in Python.
"

Well you basically said it yourself:

" irrelevant to the compiler and machine code".

That's kinda nice about a high level language.

Programmer does not need to understand anything below the language.

A python programmer shouldn't need to understand a damn thing to write:

A  =  10
A = A + 1
print A

However for sake of your discussion I will continue your arguments below, 
since I get the impression you guys are clueless how to change python 
implementation ;)


"
In Python most common objects are immutable. Meaning they can never
change or be overwritten.  They are bound to names.  This binding is
what makes names look like and act like traditional variables.

The secret to understanding the global keyword is to understand how
Python namespaces work.  The statement "a=5" does not assign a 5 to the
box called "a."  Rather it binds the name "a" to the "5" object, which
is immutable and called into existence by the interpreter
implementation.  Subsequently "a=6" disconnects a from the 5 object,
casting the 5 object loose to be reclaimed in some fashion that doesn't
matter at this point.  "a" is then rebound to a new object, 6.
"

What happens for following code:

A=123456789011

Are you going to claim it's going to bind to all these numbers and then also 
multiple times ?


Sounds a bit shady ?! ;)

Perhaps python considers it a string ?

Python applies math to strings ?

Sounds a bit slow... therefore perhaps you're wrong...

"
When doing a look-up on a name, the interpreter first checks the local
scope's dictionary and if it does not find the name there there, goes to
the outer scope and so forth until you get to the module global
namespace.  So we don't need any special keywords to do Pascal-style
constants.  We just define them in the module and they work.  Usually we
name them in all caps so we have a bit of a convention as to where they
come from.  And yes we're talking about looking up strings in a
dictionary here.
"

So big deal, solution is easy to see, invert interpreter logic:

Everything declared is "not constant".

Everything declared as "constant" suddenly becomes constant.

And thus everything declared as not constant behaves the same way as 
"global", problem solved.


"
When binding a name to an object, the interpreter always binds a name in
the local namespace, unless the global keyword has been used previously
and then it goes right to the global namespace.  As has been said
numerous times on this thread, how else would the interpreter do this?
There simply isn't any other way that makes sense. Certainly you haven't
made the case for it, seeing as you have some fundamental
misunderstandings about variables in Python.
"

You didn't completely explain how the global namespace becomes writeable ? 
or re-bindeable ?


(It seems not necessary to explain it you implement the constant idea, as 
explained above already).


Do I have to assume that global namespace is "re-bindeable" = writeable ?

"
You keep saying things like "writing to a variable" or "declared
variables" which just don't apply to Python because that's not how
Python variables work.  It may appear this way on the surface, but the
differences are subtle yet important.  Namespaces are written to, not
variables, some objects can be mutated. Names are bound to objects, but
variables are not declared, as a name can be bound to an object of any type.
"

Well again you didn't explain how using namespaces suddenly lead to 
"rewritable" and/or "rebinding"


if A is declared as global as follows:

global A

and then code is written as follows:

A = 10
A = 20

def Test()
   global A = 30
   return

How does this make A "rewriteable" ? Or "rebindable" to 30 ?

"
Namespaces are powerful constructs that give Python much of its dynamic
nature and expressivity. Learn to use them!
"

I didn't learn anything from this posting, sorry ! ;)

Bye,
 Skybuck. 


--
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Mark Lawrence]

On 12/09/2015 06:07, Random832 wrote:

Mark Lawrence  writes:

How do I access these pointers?  Is there a builtin called pointer()
that's analogous to id()?


You access them *all the time*. They are the *only* thing you access.

But if you want... pointer = lambda x: return x


I'll ask again, where do pointers come into
the Jython and IronPython models?  How do I access their pointers, the
same builtin?  The fact that the underlying implementation language
has some terminology that it uses, has no bearing on the actual
language being implemented.


I am not using "pointer" as language-specific terminology, I am using it
as *the* name of the concept we are talking about. The Java and .NET
runtimes *don't* use that terminology, but they still *actually* have
pointers, in the same way that Python does.



Let's put it another way, in the 15 years I've been using Python I do 
not recall any experienced Python programmer using "pointer", so what 
makes you think, in 2015, that you are correct and everybody else is 
wrong?  I still say that everything in Python is an object, and should 
add that it has one or more things, "names", that are associated with 
it.  Hence my preferred analogy about the sticky note.


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

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Random832]

Mark Lawrence  writes:
> Let's put it another way, in the 15 years I've been using Python I do
> not recall any experienced Python programmer using "pointer", so what
> makes you think, in 2015, that you are correct and everybody else is
> wrong?  I still say that everything in Python is an object, and should
> add that it has one or more things, "names", that are associated with
> it.  Hence my preferred analogy about the sticky note.

So is player3[3] also a name, a sticky note? What if we copy player3 to
another name; does it get two sticky notes, player3[3] and foo[3]? Your
"sticky note" analogy doesn't unify variables/names/whatever you want to
call them with other places that you can assign stuff to, and it implies
that the objects themselves have knowledge of their "names", and that
names are global (if I have two functions each with a result variable,
does that mean there are two different result sticky notes?)

It doesn't matter that a pointer isn't what it's *called*, it's what it
*is*. And it's not an object, because you can copy it to more than one
place with only one object.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Antoon Pardon]

Op 10-09-15 om 18:48 schreef Chris Angelico:
> I'm not sure what the point would be of having an expression that
> doesn't return a value. The point of assignment-as-an-expression is
> that you can do other things with the result:
>
> while ((ch=getchar()) != EOF)
>
> In Python, we have a couple of cases where that's done with the 'as' keyword:
>
> with open(fn) as in_file:
>
> except KeyError as e:
>
> and there've been proposals now and then to have the same thing added
> to if and while, which actually isn't hard:
>
> while getchar() as ch:

I just don't get why people want to introduce special cases in python.
Why allow such a construct only in while and if? Why not just allow
it generally as an assignment expression?

Why not allow:

  while (f(x) as fx) > 5:
proces(fx)

or

  if check(nextvalue() as new):
treat(new)

One of the things I don't like about python is the limitation of the
slice syntax. I have been in situations where the natural thing to
do was write a method that takes a slice as a parameter and
have it called like: for key, value in Tree.items(lowkey:highkey).

But that doesn't work because slice notation is only allowed in
a subscription context.

It is kind of frustrating when you see something in the language
you think useful, to then notice the language doesn't allow you
to use in the context you need/want it.

At this moment I feel that introducing the "as v" possibily only
in while and if statements would mainly enlargen my frustration.

-- 
Antoon Pardon

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Marko Rauhamaa]

Antoon Pardon :

> I just don't get why people want to introduce special cases in python.
> Why allow such a construct only in while and if? Why not just allow
> it generally as an assignment expression?
>
> Why not allow:
>
>   while (f(x) as fx) > 5:
> proces(fx)
>
> or
>
>   if check(nextvalue() as new):
> treat(new)

Hey, I know, I know!... Let's allow:

   while (fx = f(x)) > 5:
   process(fx)

   if check(new = nextvalue()):
   treat(new)

Seriously, though, I share your distaste of special cases, Antoon. Only
I don't like too much syntax (just look at Perl). There's nothing wrong
in:

   while True:
   fx = f(x)
   if fx <= 5:
   break
   process(fx)

   new = nextvalue()
   if check(new):
   treat(new)


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Mark Lawrence]

On 10/09/2015 23:25, t...@freenet.de wrote:

Some notes to the "global"-keyword and the other proposals.

It has been proposed to have these six enhancements

1. optional keyword "global"


Won't happen.


2. switch statement


Won't happen.


3. less restrictive indentation


Won't happen.


4. universal scope


No idea what you mean by this.


5. goto label


Won't happen.


6- "include" script statement


No idea what you mean by this.



with following proofs uncommented:



Your "proofs" hold about as much water as a bottomless bucket.


There is the big question:

Who is responding or has responded?
Extreme Programmers, Python-Hardliner, Python-Evangelists, ... .
Presumably no core Python Programmers (wrting compiler and standard library 
stuff)


Core Python Programmers have better things to do than waste their time 
on rubbish like this.  Examples include writing code and fixing bugs.  I 
understand that some of them are actually really weird and do other 
things like paid jobs, see their families, take holidays and worst of 
all, have other hobbies.




On Google groups you can currently read for this thread:
37 Authors. 152 posts. 443 views.

That is not that much for views (probably mostly from the writer's itself)

So, is this really the place where a PEP can be started?
When has a proposal to be accepted? If ten-thousands say yes?
Which ten-thousands? Who decides it?



The BDFL or his delegate decides, not that a PEP like this should be 
written.  If you want to waste your time please feel free to go ahead, I 
won't stop you.  However I do feel you should put this on python-ideas 
where it will be shot to pieces and then with any luck we'll get some 
peace and quiet.


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

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Mark Lawrence]

On 11/09/2015 03:19, Gene Heskett wrote:

On Thursday 10 September 2015 20:33:03 Dennis Lee Bieber wrote:


On Thu, 10 Sep 2015 12:04:05 -0700 (PDT), rurpy--- via Python-list

 declaimed the following:

I also doubt there were more programming languages around in the
1970s than now, on the grounds that there were far fewer people
capable of writing a compiler or interpreter in those days, and
there were far fewer tools to help, or easily accessible knowledge
about how to do do it.


Yet there were enough assorted semi-specialized languages in use on
military programs to induce the DoD to run the competition for a
singular language -- which became Ada.


And which should be noted that it has been a rather spectacular failure
in the commercial market.  Does that mean that those who can code in Ada
are working only for the military's suppliers, and because they are a
scarce commodity, writing their own paycheck? I don't know, other than
no one is publically bragging about it.


--
Wulfraed Dennis Lee Bieber AF6VN
 wlfr...@ix.netcom.comHTTP://wlfraed.home.netcom.com/



Cheers, Gene Heskett



Ada took over from CORAL in the UK, at least in military projects.  It 
was also used in the aircraft industry. My old work mates tell me that 
its completely died a death, to be replaced by C++.  Someone please 
remind me never to fly again.


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

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Gene Heskett]

On Friday 11 September 2015 22:35:00 Mark Lawrence wrote:

> On 11/09/2015 03:19, Gene Heskett wrote:
> > On Thursday 10 September 2015 20:33:03 Dennis Lee Bieber wrote:
> >> On Thu, 10 Sep 2015 12:04:05 -0700 (PDT), rurpy--- via Python-list
> >>
> >>  declaimed the following:
> >>> I also doubt there were more programming languages around in the
> >>> 1970s than now, on the grounds that there were far fewer people
> >>> capable of writing a compiler or interpreter in those days, and
> >>> there were far fewer tools to help, or easily accessible knowledge
> >>> about how to do do it.
> >>
> >>Yet there were enough assorted semi-specialized languages in use
> >> on military programs to induce the DoD to run the competition for a
> >> singular language -- which became Ada.
> >
> > And which should be noted that it has been a rather spectacular
> > failure in the commercial market.  Does that mean that those who can
> > code in Ada are working only for the military's suppliers, and
> > because they are a scarce commodity, writing their own paycheck? I
> > don't know, other than no one is publically bragging about it.
> >
> >> --
> >>Wulfraed Dennis Lee Bieber AF6VN
> >>  wlfr...@ix.netcom.comHTTP://wlfraed.home.netcom.com/
> >
> > Cheers, Gene Heskett
>
> Ada took over from CORAL in the UK, at least in military projects.  It
> was also used in the aircraft industry. My old work mates tell me that
> its completely died a death, to be replaced by C++.  Someone please
> remind me never to fly again.
>
Oh my gawd. C++ in a airplane autopilot?  Now that's scarey.  And I was 
just in one, three each way actually, round trip halfway across the 
country, last December.

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


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Steven D'Aprano]

On Fri, 11 Sep 2015 05:28 pm, Antoon Pardon wrote:

> Should C have chosen '<-' as token for assignment, that error
> would have been far less common.
> 
> The error is also facilitated because C doesn't have booleans
> and so everything can be used as one. If C would have had
> proper booleans 
[...]


In other words, "If C were some other language, then assignment as an
expression would be fine."

I believe I already acknowledged that assignment-as-expression was fine if
it avoided the = versus == error, from the perspective of avoiding errors.
But from the perspective of a clean and logical programming model, perhaps
not so much. Assignment is imperative, not functional, and requiring it to
return a result is somewhat unclean.

Look at it this way: suppose you had a robot servant that always, without
fail or misunderstanding, did what you instructed. There are broadly two
sorts of things that you can give as instructions: questions, and commands.
Questions always require an answer: "What's the length of this list?" is
functional. Commands are imperative, not functional, and don't necessarily
require an answer: "Move the small red pyramid onto the large green cube."
Some commands arguable might require an answer, but arguable they are
better served by an out-of-band error condition (an exception). *Requiring*
all commands to give an answer is silly, given that the robot servant is
infallible.

There's an argument to be made that, clean or not, assignment as an
expression is useful. So be it -- other languages do that. I personally
find it more confusing and annoying than useful when I come across it, but
YMMV.



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Michael Torrie]

On 09/11/2015 03:50 PM, Skybuck Flying wrote:
> Something which python does not seem to do currently ?!
> 
> So that's weird.
> 
> I will leave it at that for now.

Seems to me you have a completely mistaken understanding of how
variables work in Python.  This is one of the reasons why I have said in
the past, erroneously, that Python does not have variables.  It does of
course but not in the same way as C or Pascal.  In those languages names
are source-code abstractions only, and irrelevant to the compiler and
machine code.  C and Pascal define variables as boxes that can be
written to.  Not so in Python.

In Python most common objects are immutable. Meaning they can never
change or be overwritten.  They are bound to names.  This binding is
what makes names look like and act like traditional variables.

The secret to understanding the global keyword is to understand how
Python namespaces work.  The statement "a=5" does not assign a 5 to the
box called "a."  Rather it binds the name "a" to the "5" object, which
is immutable and called into existence by the interpreter
implementation.  Subsequently "a=6" disconnects a from the 5 object,
casting the 5 object loose to be reclaimed in some fashion that doesn't
matter at this point.  "a" is then rebound to a new object, 6.

When doing a look-up on a name, the interpreter first checks the local
scope's dictionary and if it does not find the name there there, goes to
the outer scope and so forth until you get to the module global
namespace.  So we don't need any special keywords to do Pascal-style
constants.  We just define them in the module and they work.  Usually we
name them in all caps so we have a bit of a convention as to where they
come from.  And yes we're talking about looking up strings in a
dictionary here.

When binding a name to an object, the interpreter always binds a name in
the local namespace, unless the global keyword has been used previously
and then it goes right to the global namespace.  As has been said
numerous times on this thread, how else would the interpreter do this?
There simply isn't any other way that makes sense. Certainly you haven't
made the case for it, seeing as you have some fundamental
misunderstandings about variables in Python.

You keep saying things like "writing to a variable" or "declared
variables" which just don't apply to Python because that's not how
Python variables work.  It may appear this way on the surface, but the
differences are subtle yet important.  Namespaces are written to, not
variables, some objects can be mutated. Names are bound to objects, but
variables are not declared, as a name can be bound to an object of any type.

Namespaces are powerful constructs that give Python much of its dynamic
nature and expressivity. Learn to use them!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Mark Lawrence]

On 12/09/2015 01:01, Michael Torrie wrote:

On 09/11/2015 03:50 PM, Skybuck Flying wrote:

Something which python does not seem to do currently ?!

So that's weird.

I will leave it at that for now.


Seems to me you have a completely mistaken understanding of how
variables work in Python.  This is one of the reasons why I have said in
the past, erroneously, that Python does not have variables.  It does of
course but not in the same way as C or Pascal.  In those languages names
are source-code abstractions only, and irrelevant to the compiler and
machine code.  C and Pascal define variables as boxes that can be
written to.  Not so in Python.

In Python most common objects are immutable. Meaning they can never
change or be overwritten.  They are bound to names.  This binding is
what makes names look like and act like traditional variables.

The secret to understanding the global keyword is to understand how
Python namespaces work.  The statement "a=5" does not assign a 5 to the
box called "a."  Rather it binds the name "a" to the "5" object, which
is immutable and called into existence by the interpreter
implementation.  Subsequently "a=6" disconnects a from the 5 object,
casting the 5 object loose to be reclaimed in some fashion that doesn't
matter at this point.  "a" is then rebound to a new object, 6.

When doing a look-up on a name, the interpreter first checks the local
scope's dictionary and if it does not find the name there there, goes to
the outer scope and so forth until you get to the module global
namespace.  So we don't need any special keywords to do Pascal-style
constants.  We just define them in the module and they work.  Usually we
name them in all caps so we have a bit of a convention as to where they
come from.  And yes we're talking about looking up strings in a
dictionary here.

When binding a name to an object, the interpreter always binds a name in
the local namespace, unless the global keyword has been used previously
and then it goes right to the global namespace.  As has been said
numerous times on this thread, how else would the interpreter do this?
There simply isn't any other way that makes sense. Certainly you haven't
made the case for it, seeing as you have some fundamental
misunderstandings about variables in Python.

You keep saying things like "writing to a variable" or "declared
variables" which just don't apply to Python because that's not how
Python variables work.  It may appear this way on the surface, but the
differences are subtle yet important.  Namespaces are written to, not
variables, some objects can be mutated. Names are bound to objects, but
variables are not declared, as a name can be bound to an object of any type.

Namespaces are powerful constructs that give Python much of its dynamic
nature and expressivity. Learn to use them!



My favourite analogy for Python names, the sticky note, here 
https://mail.python.org/pipermail/tutor/2006-October/049767.html


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

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[random832]

On Fri, Sep 11, 2015, at 20:01, Michael Torrie wrote:
> The secret to understanding the global keyword is to understand how
> Python namespaces work.  The statement "a=5" does not assign a 5 to the
> box called "a."  Rather it binds the name "a" to the "5" object, which
> is immutable and called into existence by the interpreter
> implementation.

In other words, it assigns a pointer to the "5" object [otherwise known
as "a 5"] to the box called "a". (And increments its reference count, if
you care about how the CPython garbage collector works)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Mark Lawrence]

On 12/09/2015 01:11, random...@fastmail.us wrote:

On Fri, Sep 11, 2015, at 20:01, Michael Torrie wrote:

The secret to understanding the global keyword is to understand how
Python namespaces work.  The statement "a=5" does not assign a 5 to the
box called "a."  Rather it binds the name "a" to the "5" object, which
is immutable and called into existence by the interpreter
implementation.


In other words, it assigns a pointer to the "5" object [otherwise known
as "a 5"] to the box called "a". (And increments its reference count, if
you care about how the CPython garbage collector works)



If everything in Python is an object, how can it assign a pointer? 
Especially how do Jython and IronPython assign pointers?


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

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Michael Torrie]

On 09/11/2015 06:11 PM, random...@fastmail.us wrote:
> On Fri, Sep 11, 2015, at 20:01, Michael Torrie wrote:
>> The secret to understanding the global keyword is to understand how
>> Python namespaces work.  The statement "a=5" does not assign a 5 to the
>> box called "a."  Rather it binds the name "a" to the "5" object, which
>> is immutable and called into existence by the interpreter
>> implementation.
> 
> In other words, it assigns a pointer to the "5" object [otherwise known
> as "a 5"] to the box called "a". (And increments its reference count, if
> you care about how the CPython garbage collector works)

Yes I suppose that works. It shows the difference between Pascal's "a :=
5" and Python's "a = 5".  So long as it's not just a pointer we're
talking about here; it's a counted reference. I think I prefer the word
"reference" to "pointer" in this case.  The word, pointer has certain
connotations that come from C.  Certainly in the implementation you
would probably use pointers.  But we don't really need a full physical
memory abstraction to understand names and how they are bound (made to
refer) to objects.  In fact it might be more useful to forget about the
underlying mechanisms in the interpreter.  And it's useful to think
about namespaces because then we can understand what happens when python
sees a variable in an expression. In any case, we're not overwriting any
values in Python assignments.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Mark Lawrence]

On 11/09/2015 06:15, Marko Rauhamaa wrote:

Chris Angelico :


Personally, I like to use tab characters for indentation. You can
choose how many pixels or ems or ens or spaces the actual visual shift
is, and if I disagree with your choice, it won't affect anything. As
long as tabs are used _exclusively_, Python won't be bothered by it
either.


Your preferred, novel usage of TABs, which runs counter to the age-old
programming convention, has won enough supporters to make TABs unusable.

No harm done. TABs have been banished. They were a bad idea in the first
place.

Marko



TABs might have been banished from some places, but certainly not 
Python.  Of course you have to be careful or you run into problems with 
this:-


TabError - Raised when indentation contains an inconsistent use of tabs 
and spaces.


https://docs.python.org/3/library/exceptions.html#TabError

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

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Mark Lawrence]

On 11/09/2015 09:42, Steven D'Aprano wrote:

On Fri, 11 Sep 2015 10:35 am, Ian Kelly wrote:


On Thu, Sep 10, 2015 at 4:25 PM,   wrote:

[...]

So the compiler knows the distiction between global and local already.


As we've said before, it doesn't. The compiler's current rules are
fairly simple:

1) If it's in the function's argument list, it's an argument (and
therefore local).
2) If it's explicitly declared global, then it's global.
3) If it's never assigned within the function, then it's global.


Almost. If it's never assigned within the function, then it is looked up
according to the non-local scoping rules:

- closures and enclosing functions (if any);
- globals;
- builtins;

in that order.



4) Otherwise, it's local.


"Otherwise" meaning "if it is assigned to", except that "del" counts as an
assignment. That is:

def spam():
 del x

makes x a local variable inside the function spam.


There's also a bunch of specialised and complicated rules for what happens
if you make a star import ("from module import *") inside a function, or
call eval or exec without specifying a namespace. Both of these things are
now illegal in Python 3.

And lastly, in Python 3 only, there is also a nonlocal declaration which
works like global except it applies only to closures and enclosing
functions.



Another proof about identation:
The parser can recognise identation with tabs and spaces.


You can use tabs *or* spaces.


In Python 3.

In Python 2, you can mix tabs *and* spaces, and Python will try to guess
what you mean. This causes more trouble than it is worth, and is removed in
Python 3.


[...]

I really doubt that you're going to gain any traction with this one,
because the decision that was made with Python 3 was to make the
compiler *more* rigid about not mixing tabs and spaces, not less.


Correct.

[...]

Who is responding or has responded?
Extreme Programmers, Python-Hardliner, Python-Evangelists, ... .
Presumably no core Python Programmers (wrting compiler and standard
library stuff)


Ad hominem.


For the record, I am the author of the statistics module in Python 3.4, and
Terry Reedy is the very active maintainer of IDLE. If I have missed anyone,
my apologies. So, yes, there are core developers here.

(Although not any of the senior core devs, as far as I know.)



IIRC Serhiy Storchaka pops in occasionally, as on the one genuine report 
from the RUE about the FSR.  Slight aside, I swear blind that Serhiy 
never sleeps as he always seems to be doing something on the bug tracker.


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

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Random832]

Mark Lawrence  writes:

> On 12/09/2015 01:11, random...@fastmail.us wrote:
> If everything in Python is an object, how can it assign a pointer?
> Especially how do Jython and IronPython assign pointers?

The Java and .NET runtimes also have pointers, they just don't [usually]
call them pointers, just like Python doesn't call them pointers (a match
made in... well, somewhere starting with an H, for sure).

Honestly, whether you want to call the thing a pointer or a reference,
you have to call it *something*, and I think "reference" is a worse fit
based on its connotations from C++. Whatever you call it, it's an arrow
on a diagram.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[random832]

On Fri, Sep 11, 2015, at 03:28, Antoon Pardon wrote:
> The error is also facilitated because C doesn't have booleans
> and so everything can be used as one.

Python does have booleans and everything can be used as one - the
logical conclusion is that being able to use everything as a boolean is
a positive feature that has nothing to do with lacking a "proper"
boolean type.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Ian Kelly]

On Fri, Sep 11, 2015 at 2:42 AM, Steven D'Aprano  wrote:
> On Fri, 11 Sep 2015 10:35 am, Ian Kelly wrote:
>
>> On Thu, Sep 10, 2015 at 4:25 PM,   wrote:
> [...]
>>> So the compiler knows the distiction between global and local already.
>>
>> As we've said before, it doesn't. The compiler's current rules are
>> fairly simple:
>>
>> 1) If it's in the function's argument list, it's an argument (and
>> therefore local).
>> 2) If it's explicitly declared global, then it's global.
>> 3) If it's never assigned within the function, then it's global.
>
> Almost. If it's never assigned within the function, then it is looked up
> according to the non-local scoping rules:
>
> - closures and enclosing functions (if any);
> - globals;
> - builtins;
>
> in that order.

I excluded non-locals intentionally, but if you want to be pedantic
about it, then that's still not quite right. Non-locals are indeed
identified by the compiler and compiled with the
LOAD_DEREF/STORE_DEREF opcodes (rather than the _GLOBAL and _FAST
variants used by globals and locals, respectively). The compiler
doesn't make any such distinction between globals and builtins
however, as that can only be determined at run-time.

> There's also a bunch of specialised and complicated rules for what happens
> if you make a star import ("from module import *") inside a function, or
> call eval or exec without specifying a namespace. Both of these things are
> now illegal in Python 3.

Huh?

>>> exec("x = 42")
>>> x
42
>>> exec("x = 43", None, None)
>>> x
43

That's in Python 3.4.0. Maybe I don't understand what you mean by
"without specifying a namespace".
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Chris Angelico]

On Sat, Sep 12, 2015 at 1:03 AM, Ian Kelly  wrote:
>> There's also a bunch of specialised and complicated rules for what happens
>> if you make a star import ("from module import *") inside a function, or
>> call eval or exec without specifying a namespace. Both of these things are
>> now illegal in Python 3.
>
> Huh?
>
 exec("x = 42")
 x
> 42
 exec("x = 43", None, None)
 x
> 43
>
> That's in Python 3.4.0. Maybe I don't understand what you mean by
> "without specifying a namespace".

*inside a function*

>>> def f():
...exec("x = 42")
...print(x)
...
>>> x = 231
>>> f()
231

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Ian Kelly]

On Fri, Sep 11, 2015 at 9:15 AM, Chris Angelico  wrote:
> On Sat, Sep 12, 2015 at 1:03 AM, Ian Kelly  wrote:
>>> There's also a bunch of specialised and complicated rules for what happens
>>> if you make a star import ("from module import *") inside a function, or
>>> call eval or exec without specifying a namespace. Both of these things are
>>> now illegal in Python 3.
>>
>> Huh?
>>
> exec("x = 42")
> x
>> 42
> exec("x = 43", None, None)
> x
>> 43
>>
>> That's in Python 3.4.0. Maybe I don't understand what you mean by
>> "without specifying a namespace".
>
> *inside a function*
>
 def f():
> ...exec("x = 42")
> ...print(x)
> ...
 x = 231
 f()
> 231

Ah, I didn't parse the "inside a function" as applying to that clause,
but even so, I don't see in what way that is "now illegal". For
example:

>>> x = 231
>>> def f():
...   exec("print(x); x = 42; print(x)")
...   print(x)
...
>>> f()
231
42
231

The exec still happily runs; it's just using its own private locals namespace.

Tangent: does the help for exec need to be updated? It currently reads:

The globals and locals are dictionaries, defaulting to the current
globals and locals.  If only globals is given, locals defaults to it.

Which would seem to indicate that if called from within a function
with no globals or locals, the locals from the function would be used.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Chris Angelico]

On Sat, Sep 12, 2015 at 1:27 AM, Ian Kelly  wrote:
> The exec still happily runs; it's just using its own private locals namespace.
>
> Tangent: does the help for exec need to be updated? It currently reads:
>
> The globals and locals are dictionaries, defaulting to the current
> globals and locals.  If only globals is given, locals defaults to it.
>
> Which would seem to indicate that if called from within a function
> with no globals or locals, the locals from the function would be used.

And that's the thing... I think. It's using locals(), which starts out
as a copy of the function's locals (in this example, empty), but
without assignment affecting anything. Which is more than a little
weird:

>>> def f():
... x = [1]
... exec("print(x); x[0] = 2; print(x); x = [3]; print(x)")
... print(x)
...
>>> f()
[1]
[2]
[3]
[2]

It's kinda like how globals can shadow builtins, I think. Maybe.
Except that you can't del the name inside exec to unshadow and go back
to the outer version of it.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Ian Kelly]

On Fri, Sep 11, 2015 at 9:44 AM, Chris Angelico  wrote:
> On Sat, Sep 12, 2015 at 1:27 AM, Ian Kelly  wrote:
>> The exec still happily runs; it's just using its own private locals 
>> namespace.
>>
>> Tangent: does the help for exec need to be updated? It currently reads:
>>
>> The globals and locals are dictionaries, defaulting to the current
>> globals and locals.  If only globals is given, locals defaults to it.
>>
>> Which would seem to indicate that if called from within a function
>> with no globals or locals, the locals from the function would be used.
>
> And that's the thing... I think. It's using locals(), which starts out
> as a copy of the function's locals (in this example, empty), but
> without assignment affecting anything. Which is more than a little
> weird:
>
 def f():
> ... x = [1]
> ... exec("print(x); x[0] = 2; print(x); x = [3]; print(x)")
> ... print(x)
> ...
 f()
> [1]
> [2]
> [3]
> [2]

Ah, that makes sense. It's writing into the dict that is created and
returned by locals(), but not actually updating the frame locals which
are the source of truth.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[random832]

On Fri, Sep 11, 2015, at 11:55, Chris Angelico wrote:
> On Sat, Sep 12, 2015 at 1:49 AM, Ian Kelly  wrote:
> > Ah, that makes sense. It's writing into the dict that is created and
> > returned by locals(), but not actually updating the frame locals which
> > are the source of truth.
> 
> Yeah... but it only makes sense to people who understand the
> implementation. It's certainly not a logical and sane behaviour that
> would be worth documenting and using.

What else would you document? Reading from them is a reasonable thing to
do, and works. Writing to them is a reasonable thing to want to do, but
won't work, so you need to document that it doesn't work.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Chris Angelico]

On Sat, Sep 12, 2015 at 1:49 AM, Ian Kelly  wrote:
>> And that's the thing... I think. It's using locals(), which starts out
>> as a copy of the function's locals (in this example, empty), but
>> without assignment affecting anything. Which is more than a little
>> weird:
>>
> def f():
>> ... x = [1]
>> ... exec("print(x); x[0] = 2; print(x); x = [3]; print(x)")
>> ... print(x)
>> ...
> f()
>> [1]
>> [2]
>> [3]
>> [2]
>
> Ah, that makes sense. It's writing into the dict that is created and
> returned by locals(), but not actually updating the frame locals which
> are the source of truth.

Yeah... but it only makes sense to people who understand the
implementation. It's certainly not a logical and sane behaviour that
would be worth documenting and using.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Antoon Pardon]

Op 09-09-15 om 19:55 schreef Steven D'Aprano:
> 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?

What is wrong with that?

-- 
Antoon Pardon


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Marko Rauhamaa]

Antoon Pardon :

> Op 09-09-15 om 19:55 schreef Steven D'Aprano:
>> 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?
>
> What is wrong with that?

C is an extremely strong language. However, I also think they made some
slightly regrettable choices, some of which later standards have
alleviated. One of my main issues with C has been the intentional
confusion between arrays and pointers. Also, the type notation is
clearly inferior to that of Pascal.

The greatest blessing C has bestowed upon programmers is the void
pointer. While C++ programmers (among others) have built a ridiculous
cathedral (templates) to capture the same universal notion, C
programmers just shrug their shoulders and store the reference in a void
pointer variable.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Steven D'Aprano]

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

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Steven D'Aprano]

On Thu, 10 Sep 2015 05:18 am, Chris Angelico wrote:

> On Thu, Sep 10, 2015 at 5:14 AM, Laura Creighton  wrote:
>> In a message of Thu, 10 Sep 2015 05:00:22 +1000, Chris Angelico writes:
>>>To get started, you need some other sort of kick.
>>
>> Having Brian Kernighan write a really nice book about you, helps a lot.
> 
> It kinda does. And of course, it also helps to have a time machine, so
> you can launch your language when there are less languages around.
> Today, you compete for attention with myriad languages that simply
> didn't exist when C was introduced to an unsuspecting world.

I don't think that's quite right. I think, if anything, there were more
languages in the 1970s than now, it's just that they tended to be
proprietary, maybe only running on a single vendor's machine. But even if
I'm mistaken, I think that there is near-universal agreement that the
single biggest factor in C's popularity and growth during the 1970s and 80s
is that it was tied so intimately to Unix, and Unix was taking over from
mainframes, VAX, etc.



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Michael Torrie]

On 09/10/2015 01:27 AM, Antoon Pardon wrote:
> Op 09-09-15 om 19:55 schreef Steven D'Aprano:
>> 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?
> 
> What is wrong with that?

Makes for a common error of putting an assignment in a conditional
expression like:

if (a=4) this_is_always_true();

GCC will give you a warning over that these days.  But many C
programmers still adopt a notation of

if (4 == a) do_something();

to protect them if they accidentally leave out one =.  If assignment was
not an expression, then the compiler would properly error out every time
you used a solitary = in the conditional of an if statement.

Python strikes a good compromise.  You can chain = in an assignment
statement, but you can't use them in a conditional expression.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[jkn]

On Thursday, 10 September 2015 13:18:39 UTC+1, Steven D'Aprano  wrote:
> On Thu, 10 Sep 2015 05:18 am, Chris Angelico wrote:
> 
> > On Thu, Sep 10, 2015 at 5:14 AM, Laura Creighton  wrote:
> >> In a message of Thu, 10 Sep 2015 05:00:22 +1000, Chris Angelico writes:
> >>>To get started, you need some other sort of kick.
> >>
> >> Having Brian Kernighan write a really nice book about you, helps a lot.
> > 
> > It kinda does. And of course, it also helps to have a time machine, so
> > you can launch your language when there are less languages around.
> > Today, you compete for attention with myriad languages that simply
> > didn't exist when C was introduced to an unsuspecting world.
> 
> I don't think that's quite right. I think, if anything, there were more
> languages in the 1970s than now, it's just that they tended to be
> proprietary, maybe only running on a single vendor's machine. But even if
> I'm mistaken, I think that there is near-universal agreement that the
> single biggest factor in C's popularity and growth during the 1970s and 80s
> is that it was tied so intimately to Unix, and Unix was taking over from
> mainframes, VAX, etc.
> 
> 
> 
> -- 
> Steven

In 'The Design and Evolution of C++', Bjarne Stroustrup writes about a 
principle that was applied to C with classes (an early embodiment of C++):

"C with Classes has to be a weed like C or Fortran because we cannot afford to
take care of a rose like Algol68 or Simula. If we deliver an implementation and
go away for a year, we want to find several systems running when we come back.
That will not happen if complicated maintenance is needed or if a simple port
to a new machine takes longer than a week". (pp. 37)

I think the 'C is a weed' observation one is a good one to explain the
proliferation. I say this as a good thing, and as a programmer in C, C++ and 
Python.

Jon N



-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[random832]

On Thu, Sep 10, 2015, at 11:59, Steven D'Aprano wrote:
> Although, I'm not sure that I agree with the idea that "everything is an
> expression". I think that's a category mistake, like asking for the speed
> of dark[1], or for a bucket of cold. Some things are functional by
> nature,
> and other things are imperative; some may be both, but I don't think that
> assignment is one. I think that assignment is imperative, not functional,
> and forcing it to return a value is artificial.

Why shouldn't imperative things be expressions? Why should all
expressions return a value?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Steven D'Aprano]

On Thu, 10 Sep 2015 04:59 am, random...@fastmail.us wrote:

> On Wed, Sep 9, 2015, at 13:55, Steven D'Aprano wrote:
>> 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?
> 
> Whoa, hold on. The problem with C assignment isn't that it's an
> expression, it's that it's spelled "=" and can be used in contexts where
> one would normally do an equality comparison.

Yes, that's what I'm referring to.

Although, I'm not sure that I agree with the idea that "everything is an
expression". I think that's a category mistake, like asking for the speed
of dark[1], or for a bucket of cold. Some things are functional by nature,
and other things are imperative; some may be both, but I don't think that
assignment is one. I think that assignment is imperative, not functional,
and forcing it to return a value is artificial.


> In some languages (Lisp/Scheme/etc come to mind), *everything* is an
> expression. But assignment is spelled with, generally, some variant of
> "set" [setq, set!, etc].

Yes, that at least avoids the possibility of mistaking = for == or similar.



[1] Obviously it's faster than light, since wherever the light arrives, it
finds the dark got there first.


-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Chris Angelico]

On Fri, Sep 11, 2015 at 2:31 AM,   wrote:
> On Thu, Sep 10, 2015, at 11:59, Steven D'Aprano wrote:
>> Although, I'm not sure that I agree with the idea that "everything is an
>> expression". I think that's a category mistake, like asking for the speed
>> of dark[1], or for a bucket of cold. Some things are functional by
>> nature,
>> and other things are imperative; some may be both, but I don't think that
>> assignment is one. I think that assignment is imperative, not functional,
>> and forcing it to return a value is artificial.
>
> Why shouldn't imperative things be expressions? Why should all
> expressions return a value?

I'm not sure what the point would be of having an expression that
doesn't return a value. The point of assignment-as-an-expression is
that you can do other things with the result:

while ((ch=getchar()) != EOF)

In Python, we have a couple of cases where that's done with the 'as' keyword:

with open(fn) as in_file:

except KeyError as e:

and there've been proposals now and then to have the same thing added
to if and while, which actually isn't hard:

while getchar() as ch:

but the trouble is that you can check for falsiness, but nothing else.
(In C, EOF is an integer outside the range 0..255, such that it's
distinct from any byte value. It's usually -1.) If assignment is an
expression, you can capture a value and keep going - something like
this:

stash = [None]
while (stash.__setitem__(0, getchar()) or stash[0]) != -1:
ch = stash[0]

It's ugly, but it does work - because the setitem call is an
expression. However, for this to succeed, the expression MUST yield a
value. Otherwise it doesn't make sense, and the difference between
expression and statement is a purely technical/theoretical one. (In
this case, the value of the "assignment" expression is always None,
which is less useful than C's policy of returning the value itself;
but at least I know what it's going to be, so I can use the "or
stash[0]" notation.)

Having assignment be a statement (and therefore illegal in a loop
condition) makes sense. Having it be an expression that yields a
useful or predictable value makes sense. Having it be an expression,
but not returning a value, doesn't.

(I'm not going to get into the argument here about whether assignment
SHOULD be a statement or an expression. There are plenty of languages
to choose from, so you can have it both ways if you like.)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Steven D'Aprano]

On Thu, 10 Sep 2015 04:26 am, Sven R. Kunze wrote:

> Just to understand it the way you want it to be understood: what do you
> mean by "technical excellence"?

That's one of those things that are difficult to define precisely. All I can
do is give some partial examples, and counter-examples.

Lisp embodies a form of mathematical elegance and simplicity that one might
call technical excellence. Forth does too, despite their completely
different syntax and computational model.

BASIC does not.

ML's type-checker displays technical excellence:

http://perl.plover.com/yak/typing/notes.html

Haskell, which inherits the same sort of type-checker, does too.

Inform 7's natural language syntax and inference engine displays technical
excellence. APL's mathematics syntax does not, as it doesn't even follow
the same rules that mathematicians expect. (APL, I'm lead to believe, is
evaluated purely from left-to-right -- or was it right to left? -- so that
1+2*3 gives 9 rather than 7 like mathematicians expect.)

Credit where credit is due: although I think that in the broader computing
ecosystem it does more harm than good, the efforts put into optimization by
C compilers show technical excellence. If there's a cycle that can be
shaved, good C compilers like gcc and clang will find it.

It's hard (impossible?) to think of a language that gets *everything* right,
because so much of that depends on subjective factors, but I think that
languages can display technical excellence in a particular subset of
features. It's not "all or nothing" -- a language can be excellent in one
area, and poor in another.


[...]
>> (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?)
>
> Do you mean https://medium.com/message/everything-is-broken-81e5f33a24e1 ?

Yes, that's the one, thanks.



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Steven D'Aprano]

On Fri, 11 Sep 2015 02:31 am, random...@fastmail.us wrote:

> On Thu, Sep 10, 2015, at 11:59, Steven D'Aprano wrote:
>> Although, I'm not sure that I agree with the idea that "everything is an
>> expression". I think that's a category mistake, like asking for the speed
>> of dark[1], or for a bucket of cold. Some things are functional by
>> nature,
>> and other things are imperative; some may be both, but I don't think that
>> assignment is one. I think that assignment is imperative, not functional,
>> and forcing it to return a value is artificial.
> 
> Why shouldn't imperative things be expressions?

Sometimes they might be. But in general, I think it is meaningless to expect
a imperative command to have a return result. The whole point of an
imperative command is that it operates by side-effect.

For example, what would `del x` return if it were an expression instead of a
statement? I can think of two reasonable alternatives, but both feel a bit
wrong to me.

(1) Return True if x was successfully unbound, False if it wasn't. Except
that raising an exception seems more Pythonic, in which case returning True
seems redundant. It will *always* return True, unless there's an exception.
So why bother? We only bother because there's no way to *not* return a
result if "everything is an expression".

(2) Return None, like functions do by default. But again, it only returns
None, not because None is a meaningful thing to return, but because we
don't actually have a way to say "it doesn't return anything".

Or os.abort. The docs for that say:

Help on built-in function abort in module posix:

abort(...)
abort() -> does not return!

Abort the interpreter immediately.  This 'dumps core' or otherwise fails
in the hardest way possible on the hosting operating system.


So, what would os.abort() return, if everything is an expression?

Obviously one can always find some arbitrary value for expressions to
return, in order to keep the invariant "all expressions return something".
But I dislike the arbitrariness of it. Some things aren't conceptually
functional expressions, they're imperative commands that (like Pascal
procedures, or Python statements) don't naturally have a return result.



> Why should all expressions return a value?

Because that's the definition of an expression in this context. An
expression is evaluated to either return a result, or raise an exception.



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Chris Angelico]

On Fri, Sep 11, 2015 at 4:13 AM, Steven D'Aprano  wrote:
> Sometimes they might be. But in general, I think it is meaningless to expect
> a imperative command to have a return result. The whole point of an
> imperative command is that it operates by side-effect.
>
> For example, what would `del x` return if it were an expression instead of a
> statement? I can think of two reasonable alternatives, but both feel a bit
> wrong to me.
>
> (1) Return True if x was successfully unbound, False if it wasn't. Except
> that raising an exception seems more Pythonic, in which case returning True
> seems redundant. It will *always* return True, unless there's an exception.
> So why bother? We only bother because there's no way to *not* return a
> result if "everything is an expression".
>
> (2) Return None, like functions do by default. But again, it only returns
> None, not because None is a meaningful thing to return, but because we
> don't actually have a way to say "it doesn't return anything".

Yes, or: (3) Return the old value that x contained, the way dict.pop()
does. That makes it a "destructive retrieval" rather than simply a
destruction operation.

> Or os.abort. The docs for that say:
>
> Help on built-in function abort in module posix:
>
> abort(...)
> abort() -> does not return!
>
> Abort the interpreter immediately.  This 'dumps core' or otherwise fails
> in the hardest way possible on the hosting operating system.
>
>
> So, what would os.abort() return, if everything is an expression?

Since this is in the os module, and is thus a thin wrapper around
lower-level operations, I could imagine it returning an error code
(the way the C-level exec functions do - if they succeed, they don't
return, but if they fail, they return an error number); in Python,
it'd be best to have it either abort the process (and thus not
return), or raise an exception (and thus not return).

But abort functions are a rarity. It's not a problem to have a rule
"all functions must return something" (as Python does), and then have
functions that never actually use the normal return path:

def raise_(exc): raise exc
raise_stopiteration = iter([]).__next__
raise_typeerror = lambda: ""()

Calling one of these functions is *syntactically* an expression, but
at run time, it'll never actually get as far as producing a value. If
it's at all possible for the operation to, based on run-time
information, NOT abort, then it absolutely has to be able to return.

> Because that's the definition of an expression in this context. An
> expression is evaluated to either return a result, or raise an exception.

I'd define it more simply: An expression always produces a result.
It's possible that, during the evaluation of an expression, an
exception will be raised; if that happens, evaluation stops. Doesn't
matter whether the expression itself caused that, or if an OS-level
signal did (eg triggering KeyboardInterrupt), or if the expression was
"yield 1" and an exception got thrown in. But yes, an expression is
something that generates a result; a statement isn't.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Ian Kelly]

On Thu, Sep 10, 2015 at 4:25 PM,   wrote:
> with following proofs uncommented:

None of these are "proofs".

> Each sample provided would work without global
> (or you get runtime failure while try to write a global).

What samples? It would be easier to follow your messages if you would
include quotes from previous messages as context.

> So the compiler knows the distiction between global and local already.

As we've said before, it doesn't. The compiler's current rules are
fairly simple:

1) If it's in the function's argument list, it's an argument (and
therefore local).
2) If it's explicitly declared global, then it's global.
3) If it's never assigned within the function, then it's global.
4) Otherwise, it's local.

If you take out step 2, then the compiler has no way of distinguishing
whether a variable that is assigned to is local or global.

> Another proof about identation:
> The parser can recognise identation with tabs and spaces.

You can use tabs *or* spaces. If you want to mix the two, then there
would need to be some official decision made about how many spaces
compose a tab, and then everybody who wants to use tabs would have to
configure their editors to conform to that decision, or risk breaking
their code. Some people like to indent two spaces. Some people like to
indent four spaces. On the other hand, the de facto standard for
terminal tab width is eight spaces. However, virtually nobody prefers
eight spaces of indentation. So the question is which standard are you
going to adopt, and which groups are you going to upset?

I really doubt that you're going to gain any traction with this one,
because the decision that was made with Python 3 was to make the
compiler *more* rigid about not mixing tabs and spaces, not less.

> It is correct that there have to be a decision for spaces or tabs.
> But sure not necessarily the exact same indentation to the right for each 
> block.
> Jus more same inserter to the right and the context is clear.

I don't understand what you're trying to say here.

> But all proposals are more or less fully denied - for more or less no reasons.

You've been given reasons. You seem unwilling to accept them.

> There is the big question:
>
> Who is responding or has responded?
> Extreme Programmers, Python-Hardliner, Python-Evangelists, ... .
> Presumably no core Python Programmers (wrting compiler and standard library 
> stuff)

Ad hominem.

> On Google groups you can currently read for this thread:
> 37 Authors. 152 posts. 443 views.
>
> That is not that much for views (probably mostly from the writer's itself)

This is not a Google Group. This is the comp.lang.python newsgroup,
which is mirrored bidirectionally to the python.org python-list
mailing list. Google Groups provides another portal to the newsgroup.
There is no way to measure how many users have been reading this
thread in the newsgroup or the mailing list.

> So, is this really the place where a PEP can be started?

No, this list is for general Python discussion. The place to present a
PEP is the python-dev mailing list. It is generally considered
advisable to post the idea to the python-ideas mailing list first, to
find support for the idea and to hone it before going to the trouble
of writing a PEP.

If you do get to the point of writing a PEP, you will also need to
have a clear picture of how you plan to actually implement the idea.
It's not enough to just propose that "the global keyword should be
optional". Precisely how would scopes be determined? How would you
ensure backward compatibility? These are questions that would need
answers before anything could be implemented.

> When has a proposal to be accepted? If ten-thousands say yes?
> Which ten-thousands? Who decides it?

That's up to the BDFL.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[tdev]

Some notes to the "global"-keyword and the other proposals.

It has been proposed to have these six enhancements

1. optional keyword "global"  
2. switch statement
3. less restrictive indentation 
4. universal scope 
5. goto label
6- "include" script statement


with following proofs uncommented:

Each sample provided would work without global 
(or you get runtime failure while try to write a global). 
So the compiler knows the distiction between global and local already. 
Otherwise you would have to write in every function this keyword 
But this is not the case.  You write it because you need write access.
And this is an over-regulation. So, NO need for an explicit global. 
Optional ok.


Another proof about identation:
The parser can recognise identation with tabs and spaces. 
Otherwise semcicolons or brackets would be needed.
It is correct that there have to be a decision for spaces or tabs.
But sure not necessarily the exact same indentation to the right for each block.
Jus more same inserter to the right and the context is clear.


Another proof is Python itself (from Tutorial):
"Python is an ... powerful programming language. It has ... and a simple but 
effective approach 
to object-oriented programming. Python's elegant syntax ... together with its 
interpreted nature, 
make it an ideal language for scripting ... .

The proposals are all made for structual programming enhancements 
This is nothing else than having structural programming, functional programming 
and OO
and many more features in parallel. Why that all?
For the same reason: 
For an another type of programmers - or say: nothing more than even more 
flexibility.

Read also here: https://en.wikipedia.org/wiki/History_of_Python
Especially sections: "incfluences from other languages"



But all proposals are more or less fully denied - for more or less no reasons.


The last statement against the proposals:
   
> "EVERYONE who suggests massive, sweeping changes says "hey, if you only
> make these changes, Python will actually become popular". It's almost
> mandatory."


Additionally, that proofs: that this is not a single meaning.
And also speaking from changes is wrong. 
Enhancements or extensions would be correct.



There is the big question:

Who is responding or has responded?  
Extreme Programmers, Python-Hardliner, Python-Evangelists, ... .
Presumably no core Python Programmers (wrting compiler and standard library 
stuff)

On Google groups you can currently read for this thread:
37 Authors. 152 posts. 443 views.

That is not that much for views (probably mostly from the writer's itself)

So, is this really the place where a PEP can be started?
When has a proposal to be accepted? If ten-thousands say yes?
Which ten-thousands? Who decides it?



Thanks.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[MRAB]

On 2015-09-11 01:35, Ian Kelly wrote:

On Thu, Sep 10, 2015 at 4:25 PM,   wrote:

[snip]

It is correct that there have to be a decision for spaces or tabs.
But sure not necessarily the exact same indentation to the right for each block.
Jus more same inserter to the right and the context is clear.


I don't understand what you're trying to say here.


[snip]
I don't understand either, but perhaps he means that as long as the
lines of a suite are indented more than their introductory line, the
meaning should be clear (although "sibling" lines of the introductory
line should still be indented the same as the introductory line, e.g.
"elif" lines should still be indented the same amount as their "if"
line).

It would look untidy though! :-)
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Chris Angelico]

On Fri, Sep 11, 2015 at 6:07 AM,   wrote:
> On Thu, Sep 10, 2015, at 12:48, Chris Angelico wrote:
>> Having assignment be a statement (and therefore illegal in a loop
>> condition) makes sense. Having it be an expression that yields a
>> useful or predictable value makes sense. Having it be an expression,
>> but not returning a value, doesn't.
>
> Why not? Having it not return a value (and thus be illegal in places
> that expect a value), but be legal in places like C's comma operator or
> Lisp's progn that do not use the value, would make logical sense. Your
> while loop could be written as something like "while (ch = getchar();
> ch): ..."
>
> The main purpose of this would be to prevent you from using it where a
> boolean is expected, which wouldn't be necessary if Python hadn't
> repeated C's mistake of spelling it "=".

I didn't say it doesn't make _technical_ sense to have an expression
without  value, but it doesn't make any _useful_ sense. In previous
posts I consciously avoided this wording, but I'm going to say it, and
clink my pun jar: There's no value in doing it that way.

In order to make this valueless expression useful, you have to first
have some sort of expression that consists of two subexpressions,
where one of them is ignored. (Like C's comma operator.) Why do it?
Why not simply have the expression yield a useful value - or else not
be an expression, such that you have two _statements_?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Emile van Sebille]

On 9/10/2015 3:25 PM, t...@freenet.de wrote:

> Who decides it?

The BDFL or his delegate. It's simplest that way.

Emile


--
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Marko Rauhamaa]

Chris Angelico :

> Personally, I like to use tab characters for indentation. You can
> choose how many pixels or ems or ens or spaces the actual visual shift
> is, and if I disagree with your choice, it won't affect anything. As
> long as tabs are used _exclusively_, Python won't be bothered by it
> either.

Your preferred, novel usage of TABs, which runs counter to the age-old
programming convention, has won enough supporters to make TABs unusable.

No harm done. TABs have been banished. They were a bad idea in the first
place.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Marko Rauhamaa]

Ian Kelly :

> Emacs users with that setup would probably want the Python compiler to
> interpret a tab as eight spaces.

Which it does:

   Tabs are replaced (from left to right) by one to eight spaces such
   that the total number of characters up to and including the
   replacement is a multiple of eight (this is intended to be the same
   rule as used by Unix).

   https://docs.python.org/3/reference/lexical_analysis.html#lin
   e-structure>

although that definition has been rendered insignificant in Python 3 by
the footnote:

   Indentation is rejected as inconsistent if a source file mixes tabs
   and spaces in a way that makes the meaning dependent on the worth of
   a tab in spaces; a TabError is raised in that case.

> On the other hand, the major benefit that is often touted for
> indentation using tab characters is that the reader can set their tab
> width and read the code with their preferred indentation (this fails
> however when using mixed tabs and spaces as in that Emacs scheme).
> Such users typically use one tab character as one level of indentation
> and would presumably prefer to have those tab characters interpreted
> as two or four spaces, not eight.

That "innovation" has destroyed the TAB character. It won't be missed,
though.

> If we're forced to choose a canonical tab width, both groups can't
> win. (Of course that Emacs indentation scheme already doesn't work for
> Python, but then the only possible benefit I can see to using it is a
> mild compression of the source code, an economy of disk space that
> really isn't necessary in this day and age.)

Emacs didn't invent that scheme. That's how TABs worked in my childhood
across operating systems.

However, TABs were always problematic for other reasons. If you added
a space to the beginning of every line to shift everything to the right,
TABs caused a misalignment.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Gene Heskett]

On Thursday 10 September 2015 20:33:03 Dennis Lee Bieber wrote:

> On Thu, 10 Sep 2015 12:04:05 -0700 (PDT), rurpy--- via Python-list
>
>  declaimed the following:
> >I also doubt there were more programming languages around in the
> >1970s than now, on the grounds that there were far fewer people
> >capable of writing a compiler or interpreter in those days, and
> >there were far fewer tools to help, or easily accessible knowledge
> >about how to do do it.
>
>   Yet there were enough assorted semi-specialized languages in use on
> military programs to induce the DoD to run the competition for a
> singular language -- which became Ada.

And which should be noted that it has been a rather spectacular failure 
in the commercial market.  Does that mean that those who can code in Ada 
are working only for the military's suppliers, and because they are a 
scarce commodity, writing their own paycheck? I don't know, other than 
no one is publically bragging about it.

> --
>   Wulfraed Dennis Lee Bieber AF6VN
> wlfr...@ix.netcom.comHTTP://wlfraed.home.netcom.com/


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Chris Angelico]

On Fri, Sep 11, 2015 at 3:15 PM, Marko Rauhamaa  wrote:
> Chris Angelico :
>
>> Personally, I like to use tab characters for indentation. You can
>> choose how many pixels or ems or ens or spaces the actual visual shift
>> is, and if I disagree with your choice, it won't affect anything. As
>> long as tabs are used _exclusively_, Python won't be bothered by it
>> either.
>
> Your preferred, novel usage of TABs, which runs counter to the age-old
> programming convention, has won enough supporters to make TABs unusable.
>
> No harm done. TABs have been banished. They were a bad idea in the first
> place.

I don't understand. How does that usage run counter to the old
conventions? A tab character, a press of the tab key, was a signal to
move to the next logical column - regardless of the exact width of a
column. It's also completely compatible with the stricter rule "a tab
is equivalent to eight spaces".

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Chris Angelico]

On Fri, Sep 11, 2015 at 2:34 PM, Marko Rauhamaa  wrote:
> etc. The TAB *key* is a command that makes emacs indent with a mix of
> spaces and TABs.

I don't care how you key them in. If your tab key moves you to the
next position, that's good. If you convert a sequence of N spaces into
a tab character, though, that's bad, because then your file ends up
with a mix, and an inconsistent one. To make emacs safe for use with
Python code, you'll need to reconfigure it so the tab key inserts
either a tab character or spaces, but never switches between them.

Personally, I like to use tab characters for indentation. You can
choose how many pixels or ems or ens or spaces the actual visual shift
is, and if I disagree with your choice, it won't affect anything. As
long as tabs are used _exclusively_, Python won't be bothered by it
either.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Marko Rauhamaa]

Ian Kelly :

> You can use tabs *or* spaces. If you want to mix the two, then there
> would need to be some official decision made about how many spaces
> compose a tab, and then everybody who wants to use tabs would have to
> configure their editors to conform to that decision, or risk breaking
> their code. Some people like to indent two spaces. Some people like to
> indent four spaces. On the other hand, the de facto standard for
> terminal tab width is eight spaces. However, virtually nobody prefers
> eight spaces of indentation. So the question is which standard are you
> going to adopt, and which groups are you going to upset?

Indentation preferences and the interpretation of TABs are two separate
things.

For example, in the default emacs configuration, the C indentation
levels go like this:

   SPC SPC
   SPC SPC SPC SPC
   SPC SPC SPC SPC SPC SPC
   TAB
   TAB SPC SPC

etc. The TAB *key* is a command that makes emacs indent with a mix of
spaces and TABs.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Ian Kelly]

On Thu, Sep 10, 2015 at 10:34 PM, Marko Rauhamaa  wrote:
> Ian Kelly :
>
>> You can use tabs *or* spaces. If you want to mix the two, then there
>> would need to be some official decision made about how many spaces
>> compose a tab, and then everybody who wants to use tabs would have to
>> configure their editors to conform to that decision, or risk breaking
>> their code. Some people like to indent two spaces. Some people like to
>> indent four spaces. On the other hand, the de facto standard for
>> terminal tab width is eight spaces. However, virtually nobody prefers
>> eight spaces of indentation. So the question is which standard are you
>> going to adopt, and which groups are you going to upset?
>
> Indentation preferences and the interpretation of TABs are two separate
> things.
>
> For example, in the default emacs configuration, the C indentation
> levels go like this:
>
>SPC SPC
>SPC SPC SPC SPC
>SPC SPC SPC SPC SPC SPC
>TAB
>TAB SPC SPC
>
> etc. The TAB *key* is a command that makes emacs indent with a mix of
> spaces and TABs.

That's all true but is tangential to my point. Emacs users with that
setup would probably want the Python compiler to interpret a tab as
eight spaces. On the other hand, the major benefit that is often
touted for indentation using tab characters is that the reader can set
their tab width and read the code with their preferred indentation
(this fails however when using mixed tabs and spaces as in that Emacs
scheme). Such users typically use one tab character as one level of
indentation and would presumably prefer to have those tab characters
interpreted as two or four spaces, not eight.

If we're forced to choose a canonical tab width, both groups can't
win. (Of course that Emacs indentation scheme already doesn't work for
Python, but then the only possible benefit I can see to using it is a
mild compression of the source code, an economy of disk space that
really isn't necessary in this day and age.)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[alister]

On Fri, 11 Sep 2015 01:59:27 +1000, Steven D'Aprano wrote:
> 
> Although, I'm not sure that I agree with the idea that "everything is an
> expression". I think that's a category mistake, like asking for the
> speed of dark[1], or for a bucket of cold. Some things are functional by
> nature, and other things are imperative; some may be both, but I don't
> think that assignment is one. I think that assignment is imperative, not
> functional, and forcing it to return a value is artificial.
> 
> 
> [1] Obviously it's faster than light, since wherever the light arrives,
> it finds the dark got there first.

Incorrect light is simply the absence of dark

https://astro.uni-bonn.de/~dfischer/dark_sucker_2.html

http://tristan.ethereal.net/humor/dark-suckers.html




-- 
Neutrinos have bad breadth.
-- 
https://mail.python.org/mailman/listinfo/python-list