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

#49480

On Sunday, June 30, 2013 10:38:01 AM UTC+5:30, Chris Angelico wrote:
> On Sun, Jun 30, 2013 at 2:32 PM, Terry Reedy  wrote:
> > 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.

Getting scoping right has been -- history-wise -- exceptionally difficult.

Lisp started with dynamic scoping -- the word and the consequences of that hardly being conceivable in 1960.  It took 25 years to correct half that error in scheme and common-lisp viz. dynamic to static scoping.  The other half still persists in common lisp though not scheme
http://en.wikipedia.org/wiki/Lisp-1_vs._Lisp-2#The_function_namespace.

Its taken another 25 years to get the mistake out of the most ubiquitous lisp -- Emacs-lisp
https://en.wikipedia.org/wiki/Emacs_Lisp#From_dynamic_to_lexical_scoping

I believe perl started with 'local' and later added 'my', repeating the same mistake.

Even python needed to modify the LEGB rule (was it 2.2??) for similar reasons,
got comprehension scoping wrong by having variables leak out -- corrected from 2 -> 3, and still gets it wrong from one element to the next.

And finally, the founders of lambda-calculus -- Church, Curry, Rosser -- screwed up (I believe) in the initial definitions of free and bound variables.

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

#49474

On Sat, Jun 29, 2013 at 10:32 PM, Terry Reedy <tjreedy@udel.edu> wrote:
> On 6/29/2013 5:21 PM, Ian Kelly wrote:
>> 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.

In general I agree, although when reading code I would definitely
prefer if the locals were declared.

On a related note, I think that generator functions should in some way
be explicitly marked as such in the declaration, rather than needing
to scan the entire function body for a yield statement to determine
whether it's a generator or not.

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

#49523

On 30/06/2013 3:46 PM, Ian Kelly wrote:
> In general I agree, although when reading code I would definitely
> prefer if the locals were declared.

If you import the code into the interpreter as an adjunct to reading it
you can see the locals with:

 >>> somefunc.func_code.co_varnames # 2.x
 >>> somefunc.__code__.co_varnames  # 3.x

> On a related note, I think that generator functions should in some way
> be explicitly marked as such in the declaration, rather than needing
> to scan the entire function body for a yield statement to determine
> whether it's a generator or not.

 >>> inspect.isgenerator(somefunc)

However, a dedicated code reader built around the inspect module could
be a handy tool.

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

#49526

On Sat, 29 Jun 2013 23:46:12 -0600, Ian Kelly wrote:

> On a related note, I think that generator functions should in some way
> be explicitly marked as such in the declaration, rather than needing to
> scan the entire function body for a yield statement to determine whether
> it's a generator or not.

That was considered when generators were introduced in Python 2.2. 
Guido's rationale for preferring to keep "def" for both generator 
functions and normal functions is given in the PEP:


    Issue:  Introduce another new keyword (say, "gen" or "generator") in
    place of "def", or otherwise alter the syntax, to distinguish
    generator-functions from non-generator functions.

    Con:  In practice (how you think about them), generators *are*
    functions, but with the twist that they're resumable.  The mechanics
    of how they're set up is a comparatively minor technical issue, and
    introducing a new keyword would unhelpfully overemphasize the
    mechanics of how generators get started (a vital but tiny part of a
    generator's life).

    Pro:  In reality (how you think about them), generator-functions are
    actually factory functions that produce generator-iterators as if by
    magic.  In this respect they're radically different from non-generator
    functions, acting more like a constructor than a function, so reusing
    "def" is at best confusing.  A "yield" statement buried in the body is
    not enough warning that the semantics are so different.

    BDFL:  "def" it stays.  No argument on either side is totally
    convincing, so I have consulted my language designer's intuition.  It
    tells me that the syntax proposed in the PEP is exactly right - not
    too hot, not too cold.  But, like the Oracle at Delphi in Greek
    mythology, it doesn't tell me why, so I don't have a rebuttal for the
    arguments against the PEP syntax.  The best I can come up with (apart
    from agreeing with the rebuttals ... already made) is "FUD".  If this
    had been part of the language from day one, I very much doubt it
    would have made Andrew Kuchling's "Python Warts" page.


http://www.python.org/dev/peps/pep-0255/


5+ versions later, I think that Guido has been shown to be correct. Even 
if you believe that generator functions would have been better with 
different syntax, there is no evidence that re-using def is actively 
harmful.



-- 
Steven

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

#49475

On Sun, Jun 30, 2013 at 3:46 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On a related note, I think that generator functions should in some way
> be explicitly marked as such in the declaration, rather than needing
> to scan the entire function body for a yield statement to determine
> whether it's a generator or not.

Most functions are:

def func(args):
    body
    return result

Generators are:

class func(args): # okay, you can't shortcut it like that, give it an
__init__ method
    def do_stuff(self):
        body
        yield results one by one

I don't know that anything would be gained by having a different
function declaration statement/attribute, but maybe this is something
that would benefit from a code comment (which, as far as I'm
concerned, is as much a part of the function signature as the coded
parts are).

ChrisA

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

#49477

On 6/30/2013 1:46 AM, Ian Kelly wrote:

> On a related note, I think that generator functions should in some way
> be explicitly marked as such in the declaration, rather than needing
> to scan the entire function body for a yield statement to determine
> whether it's a generator or not.

I agree that one should not have to scan. The doc string, which should 
be present should start 'Return a generator that yields ...' or even 
'Generate ...'. Of course, then non-generator functions should not start 
the same way. The first option should be non-ambiguous.

-- 
Terry Jan Reedy

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

#49478

On Sun, Jun 30, 2013 at 12:11 AM, Terry Reedy <tjreedy@udel.edu> wrote:
> On 6/30/2013 1:46 AM, Ian Kelly wrote:
>
>> On a related note, I think that generator functions should in some way
>> be explicitly marked as such in the declaration, rather than needing
>> to scan the entire function body for a yield statement to determine
>> whether it's a generator or not.
>
>
> I agree that one should not have to scan. The doc string, which should be
> present should start 'Return a generator that yields ...' or even 'Generate
> ...'. Of course, then non-generator functions should not start the same way.
> The first option should be non-ambiguous.

I don't deny that properly written comments help, but consider that
Python already enforces proper indentation for the sake of
readability.  I don't think it would be a great harm if the syntax
enforced easily readable generator

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

#49468

On 06/29/2013 01:20 PM, cts.private.yahoo@gmail.com wrote:
> 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...

The technical thing you are trying to accomplish, is, as far as I know,
not easily doable in Python, except if you use a mutable object like a list.

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

I presume you're answering the question of "what is it you're trying to
do."  Can't be sure.  But chances are good.

Far be it from me to tell you how wrong you are.   I'm still not even
sure what you're trying to do ultimately.

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

#49452

On Sat, Jun 29, 2013 at 11:02 AM, Antoon Pardon
<antoon.pardon@rece.vub.ac.be> 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.

Perhaps because that is the terminology used by the language documentation:

http://docs.python.org/3/reference/executionmodel.html#naming-and-binding

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

#49483

Op 29-06-13 21:23, Ian Kelly schreef:
> On Sat, Jun 29, 2013 at 11:02 AM, Antoon Pardon
> <antoon.pardon@rece.vub.ac.be>  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.
>
> Perhaps because that is the terminology used by the language documentation:
>
> http://docs.python.org/3/reference/executionmodel.html#naming-and-binding

I don't think this reference is as strong as you think it is. Here is
a paragraph somewhat lower:

] If a name is bound in a block, it is a local variable of that block,
] unless declared as nonlocal. If a name is bound at the module level, ] 
it is a global variable. (The variables of the module code block are ] 
local and global.) If a variable is used in a code block but not
] defined there, it is a free variable.

So the language documentation mentions these names as being variables.

-- 
Antoon Pardon

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

#49497

On Sun, Jun 30, 2013 at 4:07 AM, Antoon Pardon
<antoon.pardon@rece.vub.ac.be> wrote:
> I don't think this reference is as strong as you think it is. Here is
> a paragraph somewhat lower:
>
> ] If a name is bound in a block, it is a local variable of that block,
> ] unless declared as nonlocal. If a name is bound at the module level, ] it
> is a global variable. (The variables of the module code block are ] local
> and global.) If a variable is used in a code block but not
> ] defined there, it is a free variable.
>
> So the language documentation mentions these names as being variables.

It seems to refer to "local" and "global" variables as a short hand
for talking about specific types of name binding, which is the
dominant nomenclature of the documentation.  You asked why people talk
about Python binding names instead of assigning variables, and I think
the reference material is a clear source for that, even if it does
also use the word "variable".  There is also the section on assignment
statements, where it again refers to names being bound, not variables
being assigned:

http://docs.python.org/3/reference/simple_stmts.html#assignment-statements

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

#49498

On Sun, Jun 30, 2013 at 11:13 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Sun, Jun 30, 2013 at 4:07 AM, Antoon Pardon
> <antoon.pardon@rece.vub.ac.be> wrote:
>> I don't think this reference is as strong as you think it is. Here is
>> a paragraph somewhat lower:
>>
>> ] If a name is bound in a block, it is a local variable of that block,
>> ] unless declared as nonlocal. If a name is bound at the module level, ] it
>> is a global variable. (The variables of the module code block are ] local
>> and global.) If a variable is used in a code block but not
>> ] defined there, it is a free variable.
>>
>> So the language documentation mentions these names as being variables.
>
> It seems to refer to "local" and "global" variables as a short hand
> for talking about specific types of name binding, which is the
> dominant nomenclature of the documentation.  You asked why people talk
> about Python binding names instead of assigning variables, and I think
> the reference material is a clear source for that, even if it does
> also use the word "variable".  There is also the section on assignment
> statements, where it again refers to names being bound, not variables
> being assigned:
>
> http://docs.python.org/3/reference/simple_stmts.html#assignment-statements

Actually, looking back at your earlier post, I think I misunderstood
your question.  You weren't asking "why do people talk about binding
names instead of assigning variables in Python", but more strongly
"why do people claim there are no variables in Python"?  If the latter
is a common claim, then I haven't really taken notice of it, but I'll
take your word that you have.  I don't agree with that -- saying that
Python has no variables is just an argument of semantics.

[toc] | [prev] | [standalone]

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

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

csiph-web