Re: coding style - where to declare variables

[Steven D'Aprano]

On Mon, 23 Jul 2018 14:39:56 +0300, Marko Rauhamaa wrote:

> Steven D'Aprano :
> 
>> Lambda calculus has the concept of a binding operator, which is
>> effectively an assignment operator: it takes a variable and a value and
>> binds the value to the variable, changing a free variable to a bound
>> variable. In other words, it assigns the value to the variable, just
>> like assignment does.
> 
> In traditional Lambda Calculus semantics, there are no values at all.

It is more common to say "pure lambda calculus" rather than 
"traditional", and it is not correct to say there are no values at all. 
Rather, all values are functions (and all functions are values).

http://scienceblogs.com/goodmath/2006/08/29/a-lambda-calculus-rerun-1/

and:

"As this suggests, functions are just ordinary values, and can
be the results of functions or passed as arguments to functions
(even to themselves!).  Thus, in the lambda calculus, functions are
first-class values.  Lambda terms serve both as functions and data."

http://www.cs.cornell.edu/courses/cs6110/2013sp/lectures/lec02-sp13.pdf

And from the same notes:

"So, what is a value?  In the pure lambda calculus, any abstraction
is a value.  Remember, an abstraction λx:e is a function; in the
pure lambda calculus, the only values are functions. In an applied
lambda calculus with integers and arithmetic operations, values
also include integers.  Intuitively, a value is an expression
that can not be reduced/executed/simplified any further."



[...]
> The lambda calculus comment is just an aside. The main point is that you
> shouldn't lead people to believe that Python has variables that are any
> different than, say, Pascal's variables (even if you, for whatever
> reason, want to call them "names"). They are memory slots that hold
> values until you assign new values to them.

Nevertheless, they are still different.

My computer has an ethernet slot and a USB slot, and while they are both 
slots that hold a cable and transmit information in and out of the 
computer, they are nevertheless different. The differences are just as 
important as the similarities.


> It *is* true that Python has a more limited data model than Pascal (all
> of Python's values are objects in the heap and only accessible through
> pointers).

Calling it "more limited" is an inaccurate and pejorative way of putting 
it. Rather, I would say it is a more minimalist, *elegant* data model:

* a single kind of variable (objects in the heap where the interpreter
  manages the lifetime of objects for you)

as opposed to Pascal's more complex and more difficult model:

* two kinds of variables:

  - first-class variables that the compiler manages for you 
(allocating and deallocating them on the stack)

  - second-class variables that the programmer has to manage
manually (declaring pointers, allocating memory by hand,
tracking the lifetime of the memory block yourself,
deallocating it when you are done, and carefully avoiding
accessing the pointed-to memory block after deallocation).


At least more modern languages with both value-types and reference-types 
(such as Java, C#, Objective C, Swift) manage to elevate their reference-
type variables to first-class citizenship.


> Also, unlike Pascal, variables can hold (pointers to) values
> of any type. IOW, Python has the data model of Lisp.
> 
> Lisp talks about binding and rebinding variables as well:
> 
>https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node79.html>
> 
> which might be Lambda Calculus legacy, but at least they are not shy to
> talk about variables and assignment.




-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Re: coding style - where to declare variables

[Chris Angelico]

On Mon, Jul 23, 2018 at 9:39 PM, Steven D'Aprano
 wrote:
> [1] The CPython interpreter uses pointers; the Jython interpreter uses
> whatever kind of memory indirection the JVM provides; when I emulate a
> Python interpreter using pencil and paper, there's not a pointer in sight
> but a lot of copying of values and crossing them out. ("Copy on access"
> perhaps?) A Python interpreter emulated by a Turing machine would use
> dots on a long paper tape, and an analog computer emulating Python would
> use I-have-no-idea. Clockwork? Hydraulics?

I've been known to implement a linked list using a deck of cards, with
tetrapod "one teaspoon of sugar" packets for the Next markers, and
pens for externally-accessible references (the head of the list, the
current node, etc). This therefore proves that a pointer IS a teaspoon
of sugar, and vice versa.

Would you like your tea with one pointer or two?

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

Re: coding style - where to declare variables

[Steven D'Aprano]

On Mon, 23 Jul 2018 09:22:55 +0300, Marko Rauhamaa wrote:

> Dennis Lee Bieber :
[...]
>>  In my world, Java and Python are the ones that are not "common".
> 
> Yes, "boxed" is a Java term. However, the programming pattern of using
> dynamic memory and pointers is ubiquitous and ancient:

Not that ancient -- the first version(s) of Fortran didn't have dynamic 
memory allocation or pointers. (Admittedly, Lisp did follow not long 
afterwards.) But it is certainly not ubiquitous: many languages don't 
have pointers at all.


> FILE *f = fopen("xyz", "r");
> 
> where f holds a pointer, fopen() returns a pointer, and "xyz" and "r"
> evaluate to pointer values.
> 
> In Python, every expression evaluates to a pointer and every variable
> holds a pointer.

Within the semantics of the Python language, there are no pointer values, 
no way to get a pointer to a memory location or a pointer to an object. 
No expression in Python evaluates to a pointer, no variables hold 
pointers in Python. The Python language is defined in terms of objects: 
expressions evaluate to objects, and variables are names bound to objects.

If you don't believe me, believe the interpreter:

# Marko expects a pointer, but unfortunately he gets an int
py> type(1 + 2) 


Marko is making a similar category error as those who insist that Python 
uses "call by reference" or "call by value" for parameter passing. He 
mistakes an irrelevant implementation detail used by *some* but not all 
Python interpreters[1] for entities which exist in the Python computation 
model. As Fredrick puts it:

"Joe, I think our son might be lost in the woods"
"Don't worry, I have his social security number"

http://effbot.org/zone/call-by-object.htm

(The *pointer to an object* used in the implementation is not the same as 
the object itself.)

Evaluating 1 + 2 gives the value (an object) 3, not a pointer to the 
value 3. Pointers are not merely "not first-class citizens" of Python, 
they aren't citizens at all: there is nothing we can do in pure Python to 
get hold of pointers, manipulate pointers, or dereference pointers.

https://en.wikipedia.org/wiki/First-class_citizen

Pointers are merely one convenient, useful mechanism to implement 
Python's model of computation in an efficient manner on a digital 
computer. They are not part of the computation model, and pointers are 
not values available to the Python programmer[2].







[1] The CPython interpreter uses pointers; the Jython interpreter uses 
whatever kind of memory indirection the JVM provides; when I emulate a 
Python interpreter using pencil and paper, there's not a pointer in sight 
but a lot of copying of values and crossing them out. ("Copy on access" 
perhaps?) A Python interpreter emulated by a Turing machine would use 
dots on a long paper tape, and an analog computer emulating Python would 
use I-have-no-idea. Clockwork? Hydraulics?

https://en.wikipedia.org/wiki/MONIAC
https://makezine.com/2012/01/24/early-russian-hydraulic-computer/


[2] Except by dropping into ctypes or some other interface to the 
implementation, and even then the pointers have to be converted to and 
from int objects as they cross the boundary between the Python realm and 
the implementation realm.




-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Re: coding style - where to declare variables

[Marko Rauhamaa]

Steven D'Aprano :

> Lambda calculus has the concept of a binding operator, which is
> effectively an assignment operator: it takes a variable and a value
> and binds the value to the variable, changing a free variable to a
> bound variable. In other words, it assigns the value to the variable,
> just like assignment does.

In traditional Lambda Calculus semantics, there are no values at all.
There are only well-formatted formulas and syntactic transformation
rules. You could view it as a macro preprocessing system where you keep
transforming the formula until no transformation rule applies.

Yes, λ can be viewed as a binding operator although classically, it is
simply a dead symbol just like '(', '.' and 'z'.

> Especially in this case. Anyone who understands lambda calculus is
> unlikely to be confused by Python using the same terms to mean
> something *almost identical* to what they mean in lambda calculus.
> (The only difference I can see is that lambda calculus treats
> variables as abstract mathematical entities, while Python and other
> programming languages vivify them and give them a concrete
> implementation.)
>
> If one in ten thousand programmers are even aware of the existence of
> lambda calculus, I would be surprised. To give up using perfectly
> good, accurate terminology in favour of worse, less accurate
> terminology in order to avoid unlikely and transient confusion among a
> minuscule subset of programmers seems a poor tradeoff to me.

The lambda calculus comment is just an aside. The main point is that
you shouldn't lead people to believe that Python has variables that are
any different than, say, Pascal's variables (even if you, for whatever
reason, want to call them "names"). They are memory slots that hold
values until you assign new values to them.

It *is* true that Python has a more limited data model than Pascal (all
of Python's values are objects in the heap and only accessible through
pointers). Also, unlike Pascal, variables can hold (pointers to) values
of any type. IOW, Python has the data model of Lisp.

Lisp talks about binding and rebinding variables as well:

   https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node79.html>

which might be Lambda Calculus legacy, but at least they are not shy to
talk about variables and assignment.


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

Re: coding style - where to declare variables

[Steven D'Aprano]

On Mon, 23 Jul 2018 11:49:37 +0300, Marko Rauhamaa wrote:

> People new to Python are unnecessarily confused by talking about names
> and binding when it's really just ordinary variables and assignment.

It really isn't, not to those people who expect ordinary variables and 
assignment to be the same as that of C, C++, C#, Objective C, Swift, 
Pascal, Java, Go etc.

There are at least two common models for the association between symbolic 
names and values in programming: 

1. variables are named boxes at a statically-allocated, fixed 
   location in memory, usually on the stack ("value types");

2. variables are names that refer to dynamically-allocated
   objects in the heap, often movable ("reference types").

It is absolutely true that both are "variables" of a kind, and that "name 
binding" is abstract enough to refer to both models. But in *practice*, 
the influence of Algol, C and BASIC especially is so great that many 
people think of variables and assignment exclusively in the first sense. 
Since Python uses the second sense, having a distinct name to contrast 
the two is desirable, and "name binding" seems to fit that need.

I no longer believe that we should actively avoid the word "variable" 
when referring to Python. I think that's an extreme position which isn't 
justified. But "name binding" is an accurate technical term and not that 
hard to understand (on a scale of 0 to "monad", it's about 1) and I think 
it is elitist to claim that "people new to Python"[1] will necessarily be 
confused and we therefore ought to avoid the term.

There are lots of confusing terms and concepts in Python. People learn 
them. Name binding is no different.






[1] What, all of them? Even those with a comp sci PhD and 40 years 
programming experience in two dozen different languages?


-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Re: coding style - where to declare variables

[Ben Bacarisse]

Mark Lawrence  writes:

> On 22/07/18 14:51, Abdur-Rahmaan Janhangeer wrote:
>> except local vars
>>
>> Abdur-Rahmaan Janhangeer
>> https://github.com/Abdur-rahmaanJ
>> Mauritius
>>
>
> Python doesn't have variables, it has names.

I think we should cut beginners (and probably everyone) some slack about
this.  I don't know if work is underway to purge the term from the
Python documentation, but until that is done people can be forgiven for
thinking that the term is acceptable.

For example, https://docs.python.org/3/tutorial/classes.html says

  "The global statement can be used to indicate that particular
  variables live in the global scope and should be rebound there; the
  nonlocal statement indicates that particular variables live in an
  enclosing scope and should be rebound there."

and https://www.python.org/dev/peps/pep-0526/ is titled "Syntax for
Variable Annotations".  It describes:

  "This PEP aims at adding syntax to Python for annotating the types of
  variables (including class variables and instance variables), instead
  of expressing them through comments"

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

Re: coding style - where to declare variables

[Steven D'Aprano]

On Mon, 23 Jul 2018 20:24:30 +1200, Gregory Ewing wrote:

> Steven D'Aprano wrote:
>> So let me see if I understand your argument...
>> 
>> - we should stop using the term "binding", because it means
>>   nothing different from assignment;
>> - binding (a.k.a. "assignment") comes from lambda calculus;
>> - which has no assignment (a.k.a. "binding").
> 
> No, that's not what Marko is saying at all. He's pointing out that the
> term "binding" means something completely different in lambda calculus.

Well done in reading Marko's intent. Unfortunately, I'm not as good as 
inferring meaning as you seem to be, consequently I had to judge by what 
he wrote, not what he meant.

When a writer fails to communicate their intent, that's usually the 
failure of the writer, not the reader. We aren't mind-readers and writers 
should not blame the reader when they fail to communicate their intended 
meaning.


> The terms "bound variable" and "free variable" in lambda calculus mean
> what in Python we would call a "local variable" vs. a "non-local
> variable".

Actually, no, they are called "bound variable" and "free variable" in 
Python too.

https://docs.python.org/3/reference/executionmodel.html

See also: http://effbot.org/zone/closure.htm

Alas, I don't think Fredrik Lundh got it *quite* right. I think that 
globals (and builtins) in Python are "open free variables", as opposed to 
nonlocals which are closed. And sadly, the Python glossary currently 
doesn't define free variables nor bound variables, or even name binding.


> They have nothing to do with assignment at all.

That's not quite correct either.

Lambda calculus has the concept of a binding operator, which is 
effectively an assignment operator: it takes a variable and a value and 
binds the value to the variable, changing a free variable to a bound 
variable. In other words, it assigns the value to the variable, just like 
assignment does.

In Python terms, = is a binary binding operator: it takes a left hand 
operand, the variable (a name, for the sake of simplicity) and a right 
hand operand (a value) and binds the value to the name.

 
> Marko is asking us to stop using the word "binding" to refer to
> assignment because of the potential confusion with this other meaning.

Marko has some idiosyncratic beliefs about Python (and apparently other 
languages as well) that are difficult to justify.

Especially in this case. Anyone who understands lambda calculus is 
unlikely to be confused by Python using the same terms to mean something 
*almost identical* to what they mean in lambda calculus. (The only 
difference I can see is that lambda calculus treats variables as abstract 
mathematical entities, while Python and other programming languages 
vivify them and give them a concrete implementation.)

If one in ten thousand programmers are even aware of the existence of 
lambda calculus, I would be surprised. To give up using perfectly good, 
accurate terminology in favour of worse, less accurate terminology in 
order to avoid unlikely and transient confusion among a minuscule subset 
of programmers seems a poor tradeoff to me.



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Re: coding style - where to declare variables

[Frank Millman]

"Marko Rauhamaa"  wrote in message news:87zhyitjz2@elektro.pacujo.net...


People new to Python are unnecessarily confused by talking about names
and binding when it's really just ordinary variables and assignment. It
seems to be mostly some sort of marketing lingo that seeks to create an
air of mystique around Python.



I don't think that is a fair comment.

I am not qualified to enter the debate itself, but as an 'outsider' I can 
offer two thoughts -


1. It seems that, whatever terminology we come up with, some other language 
will use similar terminology, but with a subtly different meaning. Newcomers 
to Python coming from that other language often get confused because they 
make certain assumptions, based on their other experience, which turn out to 
be unfounded in Python.


2. My 'aha' moment came early on when I read somewhere that Python objects 
have 3 attributes - a type, a value, and a unique id. One thing that they do 
*not* have is a name. Once I understood that, a lot of things became 
clearer.


Frank Millman


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

Re: coding style - where to declare variables

[Marko Rauhamaa]

Ben Finney :
> Gregory Ewing  writes:
>
>> Marko is asking us to stop using the word "binding" to refer to
>> assignment because of the potential confusion with this other meaning.
>
> That's about as reasonable as my request that we stop using the term
> “variable” for what is, in Python, an un-typed reference to an object.
>
> I expect both of these requests to meet with little satisfaction.

I'm actually not asking, only wishing.

People new to Python are unnecessarily confused by talking about names
and binding when it's really just ordinary variables and assignment. It
seems to be mostly some sort of marketing lingo that seeks to create an
air of mystique around Python.


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

Re: coding style - where to declare variables

[Ben Finney]

Gregory Ewing  writes:

> Marko is asking us to stop using the word "binding" to refer to
> assignment because of the potential confusion with this other meaning.

That's about as reasonable as my request that we stop using the term
“variable” for what is, in Python, an un-typed reference to an object.

I expect both of these requests to meet with little satisfaction.

-- 
 \ “We are all agreed that your theory is crazy. The question that |
  `\  divides us is whether it is crazy enough to have a chance of |
_o__)being correct.” —Niels Bohr (to Wolfgang Pauli), 1958 |
Ben Finney

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

Re: coding style - where to declare variables

[Gregory Ewing]

Steven D'Aprano wrote:

So let me see if I understand your argument...

- we should stop using the term "binding", because it means 
  nothing different from assignment;

- binding (a.k.a. "assignment") comes from lambda calculus;
- which has no assignment (a.k.a. "binding").


No, that's not what Marko is saying at all. He's pointing
out that the term "binding" means something completely
different in lambda calculus.

The terms "bound variable" and "free variable" in lambda
calculus mean what in Python we would call a "local
variable" vs. a "non-local variable". They have nothing
to do with assignment at all.

Marko is asking us to stop using the word "binding" to
refer to assignment because of the potential confusion
with this other meaning.

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

Re: coding style - where to declare variables

[Marko Rauhamaa]

Dennis Lee Bieber :
> On Mon, 23 Jul 2018 00:08:00 +0300, Marko Rauhamaa 
> declaimed the following:
>
>>I Java terms, all Python values are boxed. That's a very usual pattern
>>in virtually all programming languages (apart from FORTRAN).
>
>   FORTRAN, C, COBOL, BASIC, Pascal, ALGOL, BCPL, REXX, VMS DCL, probably
> R, Matlab, APL.
>
>   I never encountered the term "boxed" until trying to read some of the
> O'Reilly books on Java.
>
>   In my world, Java and Python are the ones that are not "common".

Yes, "boxed" is a Java term. However, the programming pattern of using
dynamic memory and pointers is ubiquitous and ancient:

FILE *f = fopen("xyz", "r");

where f holds a pointer, fopen() returns a pointer, and "xyz" and "r"
evaluate to pointer values.

In Python, every expression evaluates to a pointer and every variable
holds a pointer.


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

Re: coding style - where to declare variables

[Abdur-Rahmaan Janhangeer]

variables here refers to the user experience of a var

np, just a link to the thread/s would mark the end of it

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ
Mauritius
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: coding style - where to declare variables

[Mark Lawrence]

On 22/07/18 14:51, Abdur-Rahmaan Janhangeer wrote:

except local vars

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ
Mauritius



Python doesn't have variables, it has names.  Please can we avoid a long 
meaningless thread on this subject as it's been discussed a trillion 
times before.


--
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: coding style - where to declare variables

[Steven D'Aprano]

On Sun, 22 Jul 2018 17:50:06 -0400, Dennis Lee Bieber wrote:

> On Mon, 23 Jul 2018 00:08:00 +0300, Marko Rauhamaa 
> declaimed the following:
> 
>>I Java terms, all Python values are boxed. That's a very usual pattern
>>in virtually all programming languages (apart from FORTRAN).
>>
>>
>   FORTRAN, C, COBOL, BASIC, Pascal, ALGOL, BCPL, REXX, VMS DCL, 
> probably R, Matlab, APL.
> 
>   I never encountered the term "boxed" until trying to read some of 
> the O'Reilly books on Java.
> 
>   In my world, Java and Python are the ones that are not "common".

Indeed. Its not just older languages from the 60s and 70s with value-type 
variables. Newer languages intended as systems languages, like Rust and 
Go, do the same.



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Re: coding style - where to declare variables

[Steven D'Aprano]

On Mon, 23 Jul 2018 00:08:00 +0300, Marko Rauhamaa wrote:

> Would you call it binding in this case:
> 
>X[0]["z"] = getit()
>X[3]["q"] = X[0]["z"]
>X[0]["z"].changeit()

It is a binding, but it is not a *name* binding. Since we are talking 
about name bindings, and comparing/contrasting them to variable 
assignment in classical languages, I don't think that binding to slots in 
hash tables or arrays is relevant except to muddy the waters and make 
things more complicated than they need be.


> I think what you are talking about is more usually called "referencing."

I don't think so. Its certainly not a term I've ever heard in this 
context before.


>> With a language with more ‘classical’ variable, the assignment of Y = X
>> would normal make a copy of that object, so the value Y does not get
>> changed by X.changeit().
> 
> I Java terms, all Python values are boxed. 

Correct. 

Java mixes two different models of variable assignment: it uses classical 
C- and Pascal-like variable assignment for primitive values, and Lisp- 
and Smalltalk-like name binding for boxed values (objects), leading to 
two distinct sets of behaviour. That makes Java a good lesson in why it 
is useful to distinguish between two models of name binding.

Java is not the only language with the distinction between "value 
types" (primitive values usually stored on the stack) and "reference 
types" (usually objects stored in the heap). C# and other .Net languages 
often make that distinction:

http://net-informations.com/faq/general/valuetype-referencetype.htm

Swift is another such language.

Other languages which use primarily or exclusively value-types (i.e. the 
"variables are a named box at a fixed memory location" model) include 
Algol, Pascal, Modula-3, C, C++, C#, Objective C, D, Swift, COBOL, Forth, 
Ada, PL/I, Rust and many others.



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Re: coding style - where to declare variables

[Steven D'Aprano]

On Sun, 22 Jul 2018 22:50:52 +0300, Marko Rauhamaa wrote:

> I wish people stopped talking about "name binding" and "rebinding,"
> which are simply posh synonyms for variable assignment. Properly, the
> term "binding" comes from lambda calculus, whose semantics is defined
> using "bound" and "free" variables. Lambda calculus doesn't have
> assignment.

So let me see if I understand your argument...

- we should stop using the term "binding", because it means 
  nothing different from assignment;
- binding (a.k.a. "assignment") comes from lambda calculus;
- which has no assignment (a.k.a. "binding").

Which leads us to the conclusion that lambda calculus both has and 
doesn't have binding a.k.a. assignment at the same time. Perhaps it is a 
quantum phenomenon.

Are you happy with the contradiction inherent in your statements, or 
would you prefer to reword your argument?




-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Re: coding style - where to declare variables

[Marko Rauhamaa]

Richard Damon :

>> On Jul 22, 2018, at 3:50 PM, Marko Rauhamaa  wrote:
>> I wish people stopped talking about "name binding" and "rebinding,"
>> which are simply posh synonyms for variable assignment. Properly, the
>> term "binding" comes from lambda calculus, whose semantics is defined
>> using "bound" and "free" variables. Lambda calculus doesn't have
>> assignment.
>
> Marko, I think the term binding makes sense in python due to how names
> work. In python and the following code:
>
> X = getit()
> Y = X
> X.changeit()
>
> In python, presuming getit() returns some form of object (so it has a
> changeit() member) then X and Y are bound to the same object, and
> changeit() will thus also affect the object that we see at Y.

Would you call it binding in this case:

   X[0]["z"] = getit()
   X[3]["q"] = X[0]["z"]
   X[0]["z"].changeit()

I think what you are talking about is more usually called "referencing."

> With a language with more ‘classical’ variable, the assignment of Y =
> X would normal make a copy of that object, so the value Y does not get
> changed by X.changeit().

I Java terms, all Python values are boxed. That's a very usual pattern
in virtually all programming languages (apart from FORTRAN).


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

Re: coding style - where to declare variables

[Chris Angelico]

On Mon, Jul 23, 2018 at 6:14 AM, Marko Rauhamaa  wrote:
> While FORTRAN or C couldn't operate on functions like this, an assembly
> language program could easily. Simply compose a CPU instruction sequence
> on the fly, mark it executable and use the "CALL" opcode to transfer
> control to your constructed function.

... right up until the point where you realize that this is a massive
security vulnerability, so you get a segmentation fault (or
"protection fault" under Windows) for trying to execute a
non-executable segment.

> In the same vein, you could understand the "def" statement as a runtime
> compiler that takes the function body, compiles it into machine language
> and assigns the start address to the given variable. In fact, that would
> be a perfectly working way to implement "def." Whether it would be a
> smart thing to do is a different question. Key is, though, that "def"
> always creates a new *data* object that can be called as *executable
> code*.

Here's a simpler way to describe it:

The 'def' statement creates a function and assigns it to the name given.

Tada! No need to talk about compilers and addresses and stuff, which
are utterly irrelevant in Python.

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

Re: coding style - where to declare variables

[Marko Rauhamaa]

Bart :
> If you did need one of those others to be variable, then you just assign
> it to a variable the rare times you need to do that. For example:
>
>   def fn1(): pass
>   def fn2(): pass
>
>   fn = fn1 if cond else fn2
>
> fn1, fn2 will always be functions. fn will always be a variable, but one
> that can change between referring to fn1, fn2 or anything else.

In high-level programming languages, functions are ordinary values. You
can perform similar operations on functions as on integers or strings.
You can give me two functions, and I can use those two to create a
third function:

   def compose(f1, f2):
   def composition(x):
   return f1(f2(x))
   return composition

Here "compose", "composition", "f1" and "f2" are variables:

 * "compose" gets assigned when the first, outer "def" statement is
   executed,

 * "f1" and "f2" get assigned when the function held by "compose" is
   called,

 * "composition" gets assigned when the inner "def" statement is
   executed.


While FORTRAN or C couldn't operate on functions like this, an assembly
language program could easily. Simply compose a CPU instruction sequence
on the fly, mark it executable and use the "CALL" opcode to transfer
control to your constructed function.

In the same vein, you could understand the "def" statement as a runtime
compiler that takes the function body, compiles it into machine language
and assigns the start address to the given variable. In fact, that would
be a perfectly working way to implement "def." Whether it would be a
smart thing to do is a different question. Key is, though, that "def"
always creates a new *data* object that can be called as *executable
code*.


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

Re: coding style - where to declare variables

[Richard Damon]

> On Jul 22, 2018, at 3:50 PM, Marko Rauhamaa  wrote:
> I wish people stopped talking about "name binding" and "rebinding,"
> which are simply posh synonyms for variable assignment. Properly, the
> term "binding" comes from lambda calculus, whose semantics is defined
> using "bound" and "free" variables. Lambda calculus doesn't have
> assignment.
> 
> More about variable binding here:  https://en.wikipedia.org/wiki/Free_variables_and_bound_variables>
> 
> 
> Marko

Marko, I think the term binding makes sense in python due to how names work.
In python and the following code:

X = getit()
Y = X
X.changeit()

In python, presuming getit() returns some form of object (so it has a 
changeit() member) then X and Y are bound to the same object, and changeit() 
will thus also affect the object that we see at Y.
With a language with more ‘classical’ variable, the assignment of Y = X would 
normal make a copy of that object, so the value Y does not get changed by 
X.changeit().
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: coding style - where to declare variables

[Marko Rauhamaa]

r...@zedat.fu-berlin.de (Stefan Ram):
>>Rebinding names is near-universal in programming, but usually names
>>that are intended to be rebound, such as variables.
>
>   To someone like me who has grown up with a LISP 1
>   this is completely natural.
>
> |>( SETQ A ( LAMBDA () 'ALPHA ))
> |(LAMBDA () 'ALPHA)

"Setq" is the dirty little secret of LISP.

Scheme marks its shameful primitives with an exclamation mark. Thus, its
assignment primitive is "set!".

I wish people stopped talking about "name binding" and "rebinding,"
which are simply posh synonyms for variable assignment. Properly, the
term "binding" comes from lambda calculus, whose semantics is defined
using "bound" and "free" variables. Lambda calculus doesn't have
assignment.

More about variable binding here: https://en.wikipedia.org/wiki/Free_variables_and_bound_variables>


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

Re: coding style - where to declare variables

[Peter J. Holzer]

On 2018-07-22 09:36:13 -0400, Richard Damon wrote:
> > On Jul 22, 2018, at 8:48 AM, Sharan Basappa  
> > wrote:
> > 
> > In other programming languages (e.g. C, C++), as a good practice,
> > variables are declared right at the start of the program,

There is no "start of the program" in C or C++. I assume that "start of
the function" was meant since "start of the compilation unit" would mean
that all variables are global (at least within the compilation unit)
which hopefully nobody considers a good practice.

> > irrespective of where it is normally used. What is the practice in
> > Python?
> > 
> > I see that, most of the code, declare variables where it is used and
> > not at the start of the program.
> 
> I would disagree that it is universally considered good practice to
> declare everything at the front. (There is much disagreement on this,
> but most consider declare at first use to be preferred, where
> possible).


> Last century, C code required this to make things easier on the
> compiler,

Nope. The language description in the German translation of K&R I (1984)
already shows declarations at the beginning of each block, not just each
function. The main text doesn't seem to mention this and all examples
declare variables at the start of each function, so it is possible that
this feature was added between the release of the original (1978) and
the German translation. But in any case block scope existed by 1984,
well before the turn of the century.

So the authors of C considered block scoped variables desirable
from the beginning or at least added them quite early. I would therefore
assume that they considered declaring variables in a block as good
practice.

C++ introduced the possibility to declare variables at any point in a
block, not just the beginning. C copied this in C99. Again I would argue
that Stroustrup introduced the feature because he considered declaring
variables for the smallest possible scope as good practice, and that the
C committee copied it because they agreed.

hp

-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: coding style - where to declare variables

[Abdur-Rahmaan Janhangeer]

except local vars

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ
Mauritius
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: coding style - where to declare variables

[Chris Angelico]

On Sun, Jul 22, 2018 at 10:48 PM, Sharan Basappa
 wrote:
> In other programming languages (e.g. C, C++), as a good practice, variables 
> are declared right at the start of the program, irrespective of where it is 
> normally used. What is the practice in Python?
>
> I see that, most of the code, declare variables where it is used and not at 
> the start of the program.

Common practice in Python is to never declare your variables, since
Python doesn't have variable declarations.

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

Re: coding style - where to declare variables

[Richard Damon]

> On Jul 22, 2018, at 8:48 AM, Sharan Basappa  wrote:
> 
> In other programming languages (e.g. C, C++), as a good practice, variables 
> are declared right at the start of the program, irrespective of where it is 
> normally used. What is the practice in Python?
> 
> I see that, most of the code, declare variables where it is used and not at 
> the start of the program.

I would disagree that it is universally considered good practice to declare 
everything at the front. (There is much disagreement on this, but most consider 
declare at first use to be preferred, where possible).

Last century, C code required this to make things easier on the compiler, and 
some code bases and examples go back that far, so they use that method out of 
inertia.  
-- 
https://mail.python.org/mailman/listinfo/python-list