[ python-Feature Requests-950644 ] Allow any lvalue for function definitions

SourceForge.net noreply at sourceforge.net
Mon Jun 28 13:43:47 EDT 2004


Feature Requests item #950644, was opened at 2004-05-08 21:52
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=950644&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Albert Torpey (dtorp)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Allow any lvalue for function definitions

Initial Comment:
A definition like:

    def M(x):  return 2*x

is the same as:

    M = lambda x: 2*x

With the latter form, I can use any lvalue:

    A[0] = lambda x: 2*x
    B.f = lambda x: 2*x

But with the first form, you're locked into just using a 
plain variable name.  If this were fixed, it wouldn't 
break anything else but would be useful for making 
method definitons outside of a class definition:

This came up when I was experimenting with David 
MacQuigg's ideas for prototype OO.  I want to write 
something like:

    Account = Object.clone()
    Account.balance = 0
    def Account.deposit(self, v):
        self.balance += v

Unfortunately, the latter has to be written:

    def Account.deposit(self, v):
        self.balance += v
    Account.deposit = deposit



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2004-06-28 13:43

Message:
Logged In: YES 
user_id=6380

This is the kind of thing that needs a lot of thought going into 
it to decide whether it is a net improvement to the language. 
Right now my gut feeling is that it's not worth the complexity, 
and more likely to be used towards unnecessary obfuscation. 
The redability gain is minimal if not negative IMO.

Also, I've sometimes typed "def self.foo(args):" instead 
of "def foo(self, args):" suggesting that there's more than 
one intuitive way of interpreting the proposed syntax. 
Another minus point.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-06-24 13:08

Message:
Logged In: YES 
user_id=80475

Guido, are you open to this?  If so, I would be happy to
draft a patch.

I wouldn't expect it to become mainstream, but it would open
the door to working with namespaces more directly. AFAICT,
there is no downside to allowing this capability.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-05-21 01:57

Message:
Logged In: YES 
user_id=80475

I think this should be made possible.  It allows for alternate 
coding styles wihout harming anything else.

The Lua programming language has something similar.  It is 
a lightweight, non-OO language that revolves around making 
the best possible use of namespaces.  Direct assignments 
into a namespace come up in several contexts throughout 
the language and are key to Lua's flexibility (using one 
concept to meet all needs).

My only concern is that "def" and "class" statements also 
have the side effect of binding the __name__ attribute.  We 
would have to come up with a lambda style placeholder for 
the attribute.


----------------------------------------------------------------------

Comment By: Michael Chermside (mcherm)
Date: 2004-05-19 20:56

Message:
Logged In: YES 
user_id=99874

I'm highly dubious of this. I see little advantage to doing
the definition and storing the value in a single line,
mostly because I rarely want to do such a thing. Your
example may be convincing in Prothon or some relative, but
in Python the sensible way to do it is a normal method. I'd
suggest that if you want this idea to go anywhere that you
try posting this to c.l.py and seeing if you can drum up
interest and support there.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=950644&group_id=5470



More information about the Python-bugs-list mailing list