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

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

Closures in leu of pointers?

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

Contents

  Closures in leu of pointers? cts.private.yahoo@gmail.com - 2013-06-29 02:34 -0700
    Re: Closures in leu of pointers? Fábio Santos <fabiosantosart@gmail.com> - 2013-06-29 10:42 +0100
    Re: Closures in leu of pointers? Peter Otten <__peter__@web.de> - 2013-06-29 12:01 +0200
      Re: Closures in leu of pointers? cts.private.yahoo@gmail.com - 2013-06-29 04:21 -0700
        Re: Closures in leu of pointers? cts.private.yahoo@gmail.com - 2013-06-29 04:44 -0700
          Re: Closures in leu of pointers? Peter Otten <__peter__@web.de> - 2013-06-29 14:12 +0200
            Re: Closures in leu of pointers? cts.private.yahoo@gmail.com - 2013-06-29 05:26 -0700
              Re: Closures in leu of pointers? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-06-29 15:37 +0100
                Re: Closures in leu of pointers? cts.private.yahoo@gmail.com - 2013-06-29 07:48 -0700
          Re: Closures in leu of pointers? Michael Torrie <torriem@gmail.com> - 2013-06-29 07:56 -0600
          Re: Closures in leu of pointers? Michael Torrie <torriem@gmail.com> - 2013-06-29 12:36 -0600
        Re: Closures in leu of pointers? Michael Torrie <torriem@gmail.com> - 2013-06-29 08:02 -0600
        Re: Closures in leu of pointers? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-06-29 19:02 +0200
          Re: Closures in leu of pointers? rusi <rustompmody@gmail.com> - 2013-06-29 10:33 -0700
            Re: Closures in leu of pointers? cts.private.yahoo@gmail.com - 2013-06-29 11:37 -0700
              Re: Closures in leu of pointers? Michael Torrie <torriem@gmail.com> - 2013-06-29 12:58 -0600
              Re: Closures in leu of pointers? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-29 18:59 +0000
          Re: Closures in leu of pointers? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-29 18:51 +0000
            Re: Closures in leu of pointers? Michael Torrie <torriem@gmail.com> - 2013-06-29 13:04 -0600
            Re: Closures in leu of pointers? rusi <rustompmody@gmail.com> - 2013-06-29 12:11 -0700
        Re: Closures in leu of pointers? Michael Torrie <torriem@gmail.com> - 2013-06-29 12:35 -0600
          Re: Closures in leu of pointers? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-29 19:19 +0000
            Re: Closures in leu of pointers? Tim Chase <tim@thechases.com> - 2013-06-29 14:42 -0500
              Re: Closures in leu of pointers? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-30 01:41 +0000
            Re: Closures in leu of pointers? Joshua Landau <joshua.landau.ws@gmail.com> - 2013-06-29 21:02 +0100
            Re: Closures in leu of pointers? Michael Torrie <torriem@gmail.com> - 2013-06-29 16:02 -0600
        Re: Closures in leu of pointers? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-29 18:45 +0000
          Re: Closures in leu of pointers? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-29 19:00 +0000
          Re: Closures in leu of pointers? cts.private.yahoo@gmail.com - 2013-06-29 12:20 -0700
            Re: Closures in leu of pointers? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-29 19:33 +0000
              Re: Closures in leu of pointers? cts.private.yahoo@gmail.com - 2013-06-29 12:34 -0700
              Re: Closures in leu of pointers? Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-29 13:47 -0600
              Re: Closures in leu of pointers? Terry Reedy <tjreedy@udel.edu> - 2013-06-29 16:53 -0400
                Re: Closures in leu of pointers? rusi <rustompmody@gmail.com> - 2013-06-30 01:56 -0700
                  Re: Closures in leu of pointers? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-30 11:22 +0000
                    Re: Closures in leu of pointers? rusi <rustompmody@gmail.com> - 2013-06-30 04:42 -0700
              Re: Closures in leu of pointers? Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-29 15:21 -0600
                Re: Closures in leu of pointers? cts.private.yahoo@gmail.com - 2013-06-29 14:30 -0700
              Re: Closures in leu of pointers? Terry Reedy <tjreedy@udel.edu> - 2013-06-30 00:32 -0400
              Re: Closures in leu of pointers? Chris Angelico <rosuav@gmail.com> - 2013-06-30 15:08 +1000
                Re: Closures in leu of pointers? rusi <rustompmody@gmail.com> - 2013-06-30 00:36 -0700
              Re: Closures in leu of pointers? Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-29 23:46 -0600
                Re: Closures in leu of pointers? alex23 <wuwei23@gmail.com> - 2013-07-01 14:57 +1000
                Re: Closures in leu of pointers? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-07-01 07:36 +0000
              Re: Closures in leu of pointers? Chris Angelico <rosuav@gmail.com> - 2013-06-30 15:59 +1000
              Re: Closures in leu of pointers? Terry Reedy <tjreedy@udel.edu> - 2013-06-30 02:11 -0400
              Re: Closures in leu of pointers? Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-30 00:24 -0600
            Re: Closures in leu of pointers? Michael Torrie <torriem@gmail.com> - 2013-06-29 16:03 -0600
        Re: Closures in leu of pointers? Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-29 13:23 -0600
        Re: Closures in leu of pointers? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-06-30 12:07 +0200
        Re: Closures in leu of pointers? Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-30 11:13 -0600
        Re: Closures in leu of pointers? Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-30 11:18 -0600

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

#49439

On 06/29/2013 11:02 AM, Antoon Pardon wrote:
> Op 29-06-13 16:02, Michael Torrie schreef:
>>
>> The real problem here is that you don't understand how python variables
>> work.  And in fact, python does not have variables.  It has names that
>> bind to objects.
> 
> I don't understand why members of this list keep saying this. Sure the
> variables in python behave differently than those in C and algol  But 
> they behave similarly as those in smalltalk and lisp and I haven't seen
> anyone claim that smalltalk and lisp don't have variables.
> 
> We might as well say that C doesn't have variables, it has names
> pointing to memory locations or value containers or something
> like that.

Sure but a memory location that contains say an int in C *is* a
variable, with or without a name.   You can change the int stored in
that memory address at will, as part of your normal course.  Python's
basic data types are immutable.  At best we could say they are read-only
variables.

So no, saying Python doesn't have variables is not the same as saying C
doesn't have variables but only memory locations.  They are different
concepts entirely, though on the surface they look similar.

> 
> AFAICS there is no reason why "variable" wouldn't be appropiate
> for python names as opposed to C names.

Sure I see your point, but then again, calling them variables is what
led to the OP's issue in the first place.  So yes they look like
variables, and for the most part act like them, except when they don't.
 Hence the confusion and why I bring up the difference between python's
name binding mechanism and how a variable works. It's exactly the
concept that was tripping up the OP.

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

#49450

On Sat, 29 Jun 2013 12:35:54 -0600, Michael Torrie wrote:

> Python's
> basic data types are immutable.  At best we could say they are read-only
> variables.

Python's basic data types are not necessarily immutable. Lists and dicts 
are not immutable. Being a high-level language, the idea of "primitives" 
like int, double, float, etc from C doesn't really apply. A Python dict 
is not made up from Python ints. Both int and dict are equally "basic".

More importantly, you are conflating the idea of a variable (a name) and 
the value of that variable (a value). Whether a variable is a named 
memory location or a name binding in a namespace, it's still a name. Ints 
are not names, whether they are low-level C ints or Python int objects. 
Comparing the immutability of an int object (value) with the ability to 
write to a name ("read-only variable" == constant) confuses the value and 
the name, which is exactly what we're trying to get away from.


> So no, saying Python doesn't have variables is not the same as saying C
> doesn't have variables but only memory locations.  They are different
> concepts entirely, though on the surface they look similar.

Antoon is suggesting that instead of defining:

"A variable is a named memory location, like in C"

and therefore concluding that Python doesn't have variables, we could 
define:

"A variable is a name in a namespace bound to a value, like in Lisp"

and therefore conclude that Python does have variables, but C doesn't.

It's not that the two definitions are "different concepts entirely", but 
that they are two subtly different forms of the same concept, a mapping 
between names and values.

If they were entirely different concepts, like a list and an int, you 
wouldn't have people confusing them. Nobody ever asks why Python doesn't 
let you sort an int, or take the square of a list...


-- 
Steven

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

#49457

On 2013-06-29 19:19, Steven D'Aprano wrote:
> Nobody ever asks why Python doesn't let you sort an int, or take
> the square of a list...

just to be ornery, you can sort an int:

>>> i = 314159265
>>> ''.join(sorted(str(i)))
'112345569'

And I suppose, depending on how you define it, you can square a list:

>>> lst = list('abcd')
>>> import itertools
>>> list(itertools.product(lst, lst))
[('a', 'a'), ('a', 'b'), ('a', 'c'), ('a', 'd'), ('b', 'a'), ('b',
'b'), ('b', 'c'), ('b', 'd'), ('c', 'a'), ('c', 'b'), ('c', 'c'),
('c', 'd'), ('d', 'a'), ('d', 'b'), ('d', 'c'), ('d', 'd')]

Or, if you want to do it frequently, Python graciously even allows
you to do things like

>>> class MultiList(list):
...     def __pow__(self, power):
...             return list(itertools.product(*([self] * power)))
... 
>>> lst = MultiList("abcd")
>>> lst ** 2
[('a', 'a'), ('a', 'b'), ('a', 'c'), ('a', 'd'), ('b', 'a'), ('b',
'b'), ('b', 'c'), ('b', 'd'), ('c', 'a'), ('c', 'b'), ('c', 'c'),
('c', 'd'), ('d', 'a'), ('d', 'b'), ('d', 'c'), ('d', 'd')]


:-)

-tkc

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

#49471

On Sat, 29 Jun 2013 14:42:58 -0500, Tim Chase wrote:

> On 2013-06-29 19:19, Steven D'Aprano wrote:
>> Nobody ever asks why Python doesn't let you sort an int, or take the
>> square of a list...
> 
> just to be ornery, you can sort an int:
> 
>>>> i = 314159265
>>>> ''.join(sorted(str(i)))
> '112345569'
> 
> And I suppose, depending on how you define it, you can square a list:


Yeah, but my point is that nobody ever *asks* how to do it, because they 
don't confuse the two concepts. Those who have some need for sorting the 
digits of an int-as-string work out how to solve the problem without 
asking.

And you'll note I didn't say that nobody confuses an int and a string. 
That was no accident :-)


-- 
Steven

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

#49460

On 29 June 2013 20:42, Tim Chase <tim@thechases.com> wrote:
> On 2013-06-29 19:19, Steven D'Aprano wrote:
>> Nobody ever asks why Python doesn't let you sort an int, or take
>> the square of a list...
>
> just to be ornery, you can sort an int:
>
>>>> i = 314159265
>>>> ''.join(sorted(str(i)))
> '112345569'

To be yet more ornery, you are merely sorting the string
representation of an int.

You can sort an int, though:

    [1].sort()

You may say "No! You are sorting a *list*!" However, is it not fair to
say that with:

    [1, 2, 3, 4, 5].sort()

you are sorting integers? That is just a common english idiom. Hence,
"[1].sort()" sorts an int.

> And I suppose, depending on how you define it, you can square a list:

>From Wikipedia, "a square is the result of multiplying a number, or
other expression, by itself. In other words, squaring is
exponentiation to the power 2."

This means that the only logical definitions would be "list*list" and "list**2".

However, it can be done!

    class PowList(list):
        def __pow__(self, other): pass

    PowList([1, 2, 3])**2

// Because being a pedant is more fun when you're doing it competitively //

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

#49467

On 06/29/2013 01:19 PM, Steven D'Aprano wrote:
> Python's basic data types are not necessarily immutable. Lists and dicts 
> are not immutable. Being a high-level language, the idea of "primitives" 
> like int, double, float, etc from C doesn't really apply. A Python dict 
> is not made up from Python ints. Both int and dict are equally "basic".

Indeed.  Sorry for not being more clear.  I was referring primarily to
numeric objects and strings.

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

#49442

On Sat, 29 Jun 2013 04:21:46 -0700, cts.private.yahoo wrote:

> Thank you.  You reminded me of the (weak) workaround of using arrays 

I think you mean lists, rather than arrays. Python does have an array 
type, but it is much more restricted.

If you want an indirect reference to a value, the simplest ways are via a 
object such as a list, dict or mutable object with named attributes. 
That's not really a "weak workaround". In C you would dereference a 
pointer, in Python you "dereference" a list:

ptr = &obj; 
value = *ptr;

becomes:

ptr[0] = obj
value = ptr[0]


although don't push the analogy too far, Python lists aren't pointers in 
the C sense.

What Python doesn't have -- and it doesn't seem to me that it could have, 
without support from the interpreter, is a simple way to indirectly refer 
to another *name*, rather than another object.


> and
> confirmed my suspicion that I although I can read the variable, I won't
> be able to write to it.  I still don't understand why not, though...

In Python 2, you simply can't because the interpreter doesn't support it.

 
> As for python 3 ... "nonlocal"?  I see I'm not alone in picking
> obnoxious names ...

Huh?

You have "global" for global names. Python require declarations for local 
names, but if it did it would probably use "local". What name would you 
pick to declare names nonlocal other than "nonlocal"?


-- 
Steven

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

#49446

On Sat, 29 Jun 2013 18:45:30 +0000, Steven D'Aprano wrote:

> Python require declarations for local names, but if it did it would
> probably use "local".

Oops, I meant *doesn't* require declarations. Sorry for the error.


-- 
Steven

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

#49451

exactly that.  Without wanting to analyze it in too much depth now, I would want a local keyword to allow me to know I was protecting my variables, and a way to specify other scopes, without so much implied scoping in non-intuitive ways...

Now everybody is gonna tell me how wrong I am, but you asked what I want, and that's what keeps aggrevating me with python.

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

#49455

On Sat, 29 Jun 2013 12:20:45 -0700, cts.private.yahoo wrote:

> exactly that.  

Exactly what? Who are you replying to? Your post has no context.


> Without wanting to analyze it in too much depth now, I
> would want a local keyword to allow me to know I was protecting my
> variables, and a way to specify other scopes, without so much implied
> scoping in non-intuitive ways...

Huh? What language are you programming in? Python doesn't have implied 
scoping in non-intuitive ways.

Python does have a way to specify other scopes: global to enable writing 
to the global scope, and in Python 3, nonlocal to specify writing to a 
nonlocal scope.

And what on earth does "protecting my variables" mean? If it means what I 
think it means, Python gives it to you for free: you cannot overwrite a 
variable outside of the local scope without declaring it first. What more 
"protection" do you want?


> Now everybody is gonna tell me how wrong I am, but you asked what I
> want, and that's what keeps aggrevating me with python.

If you want <language X>, you know where to find it.

Perhaps you will find it less aggravating to worry more about the 
concrete problem you want to solve, than the metaproblem of how to 
program Perl using Python syntax.



-- 
Steven

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

#49456

Touchy aren't we ...

:)

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

#49459

On Sat, Jun 29, 2013 at 1:33 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Sat, 29 Jun 2013 12:20:45 -0700, cts.private.yahoo wrote:
>> Without wanting to analyze it in too much depth now, I
>> would want a local keyword to allow me to know I was protecting my
>> variables, and a way to specify other scopes, without so much implied
>> scoping in non-intuitive ways...
>
> Huh? What language are you programming in? Python doesn't have implied
> scoping in non-intuitive ways.

def f(x):
    def g(y):
        print(x)
        x = y

Within g, the variable x is implicitly local, which is non-intuitive
since without the assignment it would not be.

That said, while I think a local keyword would not be unwelcome, I
would not want it to be required.  Otherwise we end up with the
scoping rules of Lua, where everything is global unless explicitly
marked as local.

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

#49463

On 6/29/2013 3:47 PM, Ian Kelly wrote:
> On Sat, Jun 29, 2013 at 1:33 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> On Sat, 29 Jun 2013 12:20:45 -0700, cts.private.yahoo wrote:

>> Huh? What language are you programming in? Python doesn't have implied
>> scoping in non-intuitive ways.
>
> def f(x):
>      def g(y):
>          print(x)
>          x = y
>
> Within g, the variable x is implicitly local,

The assignment looks pretty explicit to me ;-|. But to each his own on 
'plicitness.

> which is non-intuitive
> since without the assignment it would not be.

I think the problem people have is this. Python is *not* an interpreted 
language in the traditional sense: read a line, interpret and execute 
it. It is compiled, and the compilation of functions is a two pass 
affair. The first pass classifies all names. The second pass generates 
code based on the classification of the first pass. This is not part of 
the grammar, but implied (required) by the semantic description.

If, in the general case, the compiler requires two passes to understand 
a function body, then *so do people*#. This requirement is what trips up 
people who are either not used to the idea of two-pass compilation or do 
not cognize that the language requires it.

# The alternative for either program or people is a 1-pass + 
backtracking process where all understandings are kept provisional until 
the end of the body and revised as required. 2 passes are simpler.

That said, writing deceptive but functionin code is usually bad style. 
Writing code that looks functional but is buggy is worse.

-- 
Terry Jan Reedy

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

#49481

On Sunday, June 30, 2013 2:23:35 AM UTC+5:30, Terry Reedy wrote:
> 
> 
> 
> If, in the general case, the compiler requires two passes to understand 
> a function body, then *so do people*#. This requirement is what trips up 
> people who are either not used to the idea of two-pass compilation or do 
> not cognize that the language requires it.
> 
> # The alternative for either program or people is a 1-pass + 
> backtracking process where all understandings are kept provisional until 
> the end of the body and revised as required. 2 passes are simpler.


Well languages like C have half a dozen such passes!

They are called, preprocessing, compiling, assembling, linking, dynamic linking etc.

And then we have that a variable at one stage becomes a constant at another, eg a macro.

All of which adds up to making scoping/variables an arcane craft.

Now having such passes is one thing. Defining the language in terms of them quite another...

> (Python) is compiled, and the compilation of functions is a two pass 
> affair. The first pass classifies all names. The second pass generates 
> code based on the classification of the first pass. This is not part of 
> the grammar, but implied (required) by the semantic description.


So if understanding a language in terms of machine states -- a so called operational definition -- is unsatisfactory, understanding it in terms of the machine-states of the implementation is doubly so  -- we may call it a meta-operational definition.

Now, thanks to Joel Spolsky we know that abstractions in general will leak including our primary abstractions viz programming languages.  So, no completely banning operational understanding is generally impossible.

However when it is avoidable it should be avoided.

I documented the hell that teachers have teaching operational/meta-operational langauges like C 25 years ago http://www.the-magus.in/Publications/chor.pdf
And I would wish that python at least tries not to repeat C's mistakes!

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

#49486

On Sun, 30 Jun 2013 01:56:25 -0700, rusi wrote:

[...]
> All of which adds up to making scoping/variables an arcane craft.
> 
> Now having such passes is one thing. Defining the language in terms of
> them quite another...

I don't believe that Python's behaviour is defined in terms of the number 
of passes. It is defined in terms of a condition "if you assign to a 
name, it is local unless declared global". Parsing the function twice 
just happens to be the simplest way for the compiler to implement that 
rule, but it's not strictly necessary. A skilled human reader, for 
example, may read the function once, and re-interprete what's already 
seen on the basis of what they've just seen. For a human reader, such 
backtracking is probably easier than a two-pass process explicitly 
memorizing which variables are local and which are global. 



-- 
Steven

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

#49487

On Sunday, June 30, 2013 4:52:24 PM UTC+5:30, Steven D'Aprano wrote:
> On Sun, 30 Jun 2013 01:56:25 -0700, rusi wrote:
> > Now having such passes is one thing. Defining the language in terms of
> > them quite another...
> 
> 
> I don't believe that Python's behaviour is defined in terms of the number 
> of passes. It is defined in terms of a condition "if you assign to a 

Yeah sure, I dont believe that python is nearly as bad as C where for example one commonly has to run the preprocessor standalone to debug f---ed up macros.

I was responding to Terry's

> This is not part of the grammar, but implied (required) by the semantic 
> description.

Now in the case of C one would not be able to give a non-operational semantics even with a battalion of denotational semantics PhDs. Python is clearly not so bad, though in some cases the praxis of a certain aspect may be better dealt with operationally than the language spec even if that is non-operational.

A clear case of this is that of mutable default parameters.  Understanding that the def statement is an imperative statement in python and the consequences of that understanding, solves that issue.  However the cost implicit in this is that the semantics has been operationalized.

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

#49465

On Sat, Jun 29, 2013 at 2:53 PM, Terry Reedy <tjreedy@udel.edu> wrote:
> # The alternative for either program or people is a 1-pass + backtracking
> process where all understandings are kept provisional until the end of the
> body and revised as required. 2 passes are simpler.

Or simply an explicit declaration of scope at the beginning of the
function definition.

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

#49466

No, actually, it's okay that it's local by default, after all.  TCL's got that capability of explicitly specifying the scope (up n or something like that?).  That's okay for tcl, not sure if it would seem so elegant for python.  But you can't tell me that the scenarios that I presented in the beginning of this thread are intuitive.  I'm going to have a very hard time ever accepting a language that lets me read a variable but when I try to write to it, it suddenly doesn't want to have to do with it anymore ... but hey, like somebody said - everybody's got their own sense of 'plictedness.

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

#49472

On 6/29/2013 5:21 PM, Ian Kelly wrote:
> On Sat, Jun 29, 2013 at 2:53 PM, Terry Reedy <tjreedy@udel.edu> wrote:
>> # The alternative for either program or people is a 1-pass + backtracking
>> process where all understandings are kept provisional until the end of the
>> body and revised as required. 2 passes are simpler.
>
> Or simply an explicit declaration of scope at the beginning of the
> function definition.

One of the reasons I switched to Python was to not have to do that, or 
hardly ever. For valid code, an new declaration is hardly needed. 
Parameters are locals. If the first use of another name binds it (and 
that includes import, class, and def), it is local. If the first use of 
does not bind it, it had better not be local (because if it is, there 
well be an exception). If there are branches, each should be consistent 
with the others. One should only need two readings to understand and fix 
unbound local errors.

-- 
Terry Jan Reedy

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

#49473

On Sun, Jun 30, 2013 at 2:32 PM, Terry Reedy <tjreedy@udel.edu> wrote:
> On 6/29/2013 5:21 PM, Ian Kelly wrote:
>>
>> On Sat, Jun 29, 2013 at 2:53 PM, Terry Reedy <tjreedy@udel.edu> wrote:
>>>
>>> # The alternative for either program or people is a 1-pass + backtracking
>>> process where all understandings are kept provisional until the end of
>>> the
>>> body and revised as required. 2 passes are simpler.
>>
>>
>> Or simply an explicit declaration of scope at the beginning of the
>> function definition.
>
>
> One of the reasons I switched to Python was to not have to do that, or
> hardly ever. For valid code, an new declaration is hardly needed. Parameters
> are locals. If the first use of another name binds it (and that includes
> import, class, and def), it is local. If the first use of does not bind it,
> it had better not be local (because if it is, there well be an exception).
> If there are branches, each should be consistent with the others. One should
> only need two readings to understand and fix unbound local errors.

This is strictly a matter of opinion, and one on which mine differs
from yours. I think explicit declarations are better than implicit
"you've assigned to this name" local creations; the declarations help
to catch typos. Also, I like the consistency of C-style declarations -
where-ever you declare something, it's valid from there "in", and not
"out". Without declarations, there's a magical scope boundary at a
function definition that's different from the non-boundary at a loop,
for instance.

But that's just my opinion. and as Teresa says, I'm only one, and
possibly I'm wrong.

ChrisA

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

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

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

csiph-web