Re: Syntax for one-line "nonymous" functions in "declaration style"
On mer., Apr 3, 2019 at 6:00 PM, python-list-requ...@python.org wrote: On Wed, Apr 3, 2019 at 3:55 AM Alexey Muranov wrote: I clarified what i meant by an assignment, and i believe it to be a usual meaning. 1. `def` is not an assignment, there is no left-hand side or right-hand side. I was talking about the normal assignment by which anyone can bind any value to any variable. Actually, a 'def' statement DOES perform assignment. It does a bit more than that, but it definitely is assignment. You can easily check the CPython disassembly: A command that performs an assignment among other things is not an assignment command itself. Alexey. -- https://mail.python.org/mailman/listinfo/python-list
Re: Syntax for one-line "nonymous" functions in "declaration style"
On Wed, Apr 3, 2019 at 3:55 AM Alexey Muranov wrote:
> I clarified what i meant by an assignment, and i believe it to be a
> usual meaning.
>
> 1. `def` is not an assignment, there is no left-hand side or
> right-hand side. I was talking about the normal assignment by which
> anyone can bind any value to any variable.
Actually, a 'def' statement DOES perform assignment. It does a bit
more than that, but it definitely is assignment. You can easily check
the CPython disassembly:
>>> import dis
>>> def f():
... def g(x): return x * 3 + 1
...
>>> dis.dis(f)
2 0 LOAD_CONST 1 (", line 2>)
2 LOAD_CONST 2 ('f..g')
4 MAKE_FUNCTION0
6 STORE_FAST 0 (g)
8 LOAD_CONST 0 (None)
10 RETURN_VALUE
[disassembly of g() omitted as it's irrelevant]
At run time, the statement "def g(x): ..." means "grab this code
object and this name, make a function, *and assign it to the name g*".
Your other points, I agree on.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Syntax for one-line "nonymous" functions in "declaration style"
On mar., Apr 2, 2019 at 6:00 PM, python-list-requ...@python.org wrote: On Tue, Apr 2, 2019 at 1:43 AM Alexey Muranov wrote: > On Mon, Apr 1, 2019 at 3:52 PM Alexey Muranov gmail.com> > wrote: > > > > I only see a superficial analogy with `super()`, but perhaps it is > > because you did not give much details of you suggestion. > > No, it's because the analogy was not meant to be anything more than > superficial. Both are constructs of syntactic magic that aid > readability at > a high level but potentially obscure the details of execution (in > relatively unimportant ways) when examined at a low level. Since i understand that the "super() magic" is just evaluation in a predefined environment, it does not look so very magic. It's the reason why this doesn't work: superduper = super class A: def f(self): return 42 class B(A): def f(self): return superduper().f() B().f() Traceback (most recent call last): File "", line 1, in File "", line 3, in f RuntimeError: super(): __class__ cell not found But this does: class C(A): def f(self): return superduper().f() not super C().f() 42 I don't know, seems magical to me. Moreover, without this "magic", `super()` would have just produced an error. So this magic did not change behaviour of something that worked before, it made "magically" work something that did not work before (but i am still not excited about it). I'm curious how you feel about this example then (from the CPython 3.7.2 REPL; results from different Python implementations or from scripts that comprise a single compilation unit may vary)? 372 is 372 True b = 372; b is 372 True b = 372 b is 372 False > Maybe it was from my talk of implementing this by replacing the > assignment > with an equivalent def statement in the AST. Bear in mind that the def > statement is already just a particular kind of assignment: it creates > a > function and assigns it to a name. The only difference between the > original > assignment and the def statement that replaces it is in the __name__ > attribute of the function object that gets created. The proposal just > makes > the direct lambda assignment and the def "assignment" to be fully > equivalent. `def` is not an assignment, it is more than that. def is an assignment where the target is constrained to a single variable and the expression is constrained to a newly created function object (optionally "decorated" first with one or more composed function calls). The only ways in which: @decorate def foo(blah): return stuff is more than: foo = decorate(lambda blah: stuff) are: 1) the former syntactically allows statements inside the function body, not just expressions; 2) the former syntactically allows annotations on the function; and 3) the former syntactically sets a function name and the latter doesn't. In other words, all of the differences ultimately boil down to syntax. Sorry, i do not feel like continuing this discussion for much longer, or we need to concentrate on some specific statement on which we disagree. I clarified what i meant by an assignment, and i believe it to be a usual meaning. 1. `def` is not an assignment, there is no left-hand side or right-hand side. I was talking about the normal assignment by which anyone can bind any value to any variable. 2. If i execute an assignment statement foo = ... and instead of evaluating the right-hand side and assigning the value to "foo" variable Python does something else, i consider the assignment operation ( = ) broken, as it does not do assignment (and only assignment). I've said more on this in previous messages. 3. About the examples with `372 is 372`, Python gives no garanties about the id's of numerical objects, and about id's of many other types of immutable objects. The user is not supposed to rely on their equality or inequality. Anytime Python's interpreter encounter two immutable objects that it finds identical, it is free to allocate a single object for both, this does not change the guaranteed semantics of the program. The '__name__' attribute of an object, as well as most (or all) other attributes, is a part of object's value/contents, no analogies with the id's. I am sorry, but except maybe for one or two more very specific questions, I am probably not going to continue. Alexey. -- https://mail.python.org/mailman/listinfo/python-list
Re: Syntax for one-line "nonymous" functions in "declaration style"
On Tue, Apr 2, 2019 at 1:43 AM Alexey Muranov wrote: > > > On Mon, Apr 1, 2019 at 3:52 PM Alexey Muranov > gmail.com> > > wrote: > > > > > > I only see a superficial analogy with `super()`, but perhaps it is > > > because you did not give much details of you suggestion. > > > > No, it's because the analogy was not meant to be anything more than > > superficial. Both are constructs of syntactic magic that aid > > readability at > > a high level but potentially obscure the details of execution (in > > relatively unimportant ways) when examined at a low level. > > Since i understand that the "super() magic" is just evaluation in a > predefined environment, it does not look so very magic. It's the reason why this doesn't work: superduper = super class A: def f(self): return 42 class B(A): def f(self): return superduper().f() >>> B().f() Traceback (most recent call last): File "", line 1, in File "", line 3, in f RuntimeError: super(): __class__ cell not found But this does: class C(A): def f(self): return superduper().f() not super >>> C().f() 42 I don't know, seems magical to me. > Moreover, without this "magic", `super()` would have just produced an > error. So this magic did not change behaviour of something that worked > before, it made "magically" work something that did not work before > (but i am still not excited about it). I'm curious how you feel about this example then (from the CPython 3.7.2 REPL; results from different Python implementations or from scripts that comprise a single compilation unit may vary)? >>> 372 is 372 True >>> b = 372; b is 372 True >>> b = 372 >>> b is 372 False > > Maybe it was from my talk of implementing this by replacing the > > assignment > > with an equivalent def statement in the AST. Bear in mind that the def > > statement is already just a particular kind of assignment: it creates > > a > > function and assigns it to a name. The only difference between the > > original > > assignment and the def statement that replaces it is in the __name__ > > attribute of the function object that gets created. The proposal just > > makes > > the direct lambda assignment and the def "assignment" to be fully > > equivalent. > > `def` is not an assignment, it is more than that. def is an assignment where the target is constrained to a single variable and the expression is constrained to a newly created function object (optionally "decorated" first with one or more composed function calls). The only ways in which: @decorate def foo(blah): return stuff is more than: foo = decorate(lambda blah: stuff) are: 1) the former syntactically allows statements inside the function body, not just expressions; 2) the former syntactically allows annotations on the function; and 3) the former syntactically sets a function name and the latter doesn't. In other words, all of the differences ultimately boil down to syntax. -- https://mail.python.org/mailman/listinfo/python-list
Re: Syntax for one-line "nonymous" functions in "declaration style"
On Mon, Apr 1, 2019 at 3:52 PM Alexey Muranov gmail.com> wrote: > > I only see a superficial analogy with `super()`, but perhaps it is > because you did not give much details of you suggestion. No, it's because the analogy was not meant to be anything more than superficial. Both are constructs of syntactic magic that aid readability at a high level but potentially obscure the details of execution (in relatively unimportant ways) when examined at a low level. Since i understand that the "super() magic" is just evaluation in a predefined environment, it does not look so very magic. I do not know if Python can already manipulate blocks of code and environments as first-class objects, but in any case this does not look to be too far from the its normal behaviour/semantics. Moreover, without this "magic", `super()` would have just produced an error. So this magic did not change behaviour of something that worked before, it made "magically" work something that did not work before (but i am still not excited about it). On the contrary, i have no idea of how in the current semantics executing an assignment can mutate the assigned value. > On the other hand, i do use assignment in Python, and you seem to > propose to get rid of assignment or to break it. I thought the proposal was clear and succinct. "When [lambda expressions] are directly assigned to a variable, Python would use the variable name as the function name." That's all. I don't know where you got the idea I was proposing "to get rid of assignment". I suppose we use the term "assignment operation" differently. By assignment i mean evaluating the expressions in the right-hand side and assigning (binding?) the value to the variable or location described in the left-hand side. I believed this was the usual meaning of "assignment"... The behaviour you describe cannot happen during assignment in this sense. Maybe it was from my talk of implementing this by replacing the assignment with an equivalent def statement in the AST. Bear in mind that the def statement is already just a particular kind of assignment: it creates a function and assigns it to a name. The only difference between the original assignment and the def statement that replaces it is in the __name__ attribute of the function object that gets created. The proposal just makes the direct lambda assignment and the def "assignment" to be fully equivalent. `def` is not an assignment, it is more than that. Alexey. -- https://mail.python.org/mailman/listinfo/python-list
Re: Syntax for one-line "nonymous" functions in "declaration style"
On Tue, Apr 2, 2019 at 6:04 PM Ian Kelly wrote: > > Note that > > > > foo.bar = baz > > > > and > > > > foo[bar] = baz > > I wrote "directly assigned to a variable", not to an attribute or an item. > These are not part of the suggestion. So what's the advantage over just using def? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Syntax for one-line "nonymous" functions in "declaration style"
On Mon, Apr 1, 2019 at 3:52 PM Alexey Muranov
wrote:
>
> I only see a superficial analogy with `super()`, but perhaps it is
> because you did not give much details of you suggestion.
No, it's because the analogy was not meant to be anything more than
superficial. Both are constructs of syntactic magic that aid readability at
a high level but potentially obscure the details of execution (in
relatively unimportant ways) when examined at a low level.
> On the other hand, i do use assignment in Python, and you seem to
> propose to get rid of assignment or to break it.
I thought the proposal was clear and succinct. "When [lambda expressions]
are directly assigned to a variable, Python would use the variable name as
the function name." That's all. I don't know where you got the idea I was
proposing "to get rid of assignment".
Maybe it was from my talk of implementing this by replacing the assignment
with an equivalent def statement in the AST. Bear in mind that the def
statement is already just a particular kind of assignment: it creates a
function and assigns it to a name. The only difference between the original
assignment and the def statement that replaces it is in the __name__
attribute of the function object that gets created. The proposal just makes
the direct lambda assignment and the def "assignment" to be fully
equivalent.
> Note that
>
> foo.bar = baz
>
> and
>
> foo[bar] = baz
I wrote "directly assigned to a variable", not to an attribute or an item.
These are not part of the suggestion.
> Do you propose to desugar it into a method/function call and to get rid
> of assignments in the language completely? Will the user be able to
> override this method? Something like:
>
> setvar("foo", bar) # desugaring of foo = bar
No, this is entirely unrelated to what I suggested.
> I am so perplexed by the proposed behaviour of `f = lambda...`, that i
> need to ask the followng: am i right to expact that
I'm not going to address what these would do because I haven't developed
the idea to this level of detail, nor do I intend to. It was just an idea
put forth to address the complaint that lambda functions assigned to
variables don't get properly named, as well as the obstacle that the
proposed "f(x) = ..." syntax not only explicitly refuses to address this,
but potentially makes the problem worse by making lambda assignment more
attractive without doing anything to actually name them. I have no
expectation of writing a PEP for it.
> I suppose in any case that
>
> return lambda x:
>
> and
>
> result = lambda x:
> return result
>
> would not return the same result, which is not what i want.
Correct, the first would return a function with the name "" (as it
does now), while the second would return a function with the name "result".
Whether or not that is more useful than "" in this case is up to
the reader.
> I tried to imagine what semantics of the language could cause your
> proposed behaviour of `f = lambda...` and couldn't think of anything
> short of breaking the language.
I'm fairly sure the language would continue to function just fine. It
creates a gotcha to be sure, but it's far from being the only one, or even
the biggest one that has to do with lambdas (that award surely goes to the
behavior of lambda closures created in a loop, which comes up on this list
with some regularity).
--
https://mail.python.org/mailman/listinfo/python-list
Re: Syntax for one-line "nonymous" functions in "declaration style"
On lun., avril 1, 2019 at 6:00 PM, python-list-requ...@python.org wrote:
On Sun, Mar 31, 2019 at 1:09 PM Alexey Muranov
wrote:
On dim., Mar 31, 2019 at 6:00 PM, python-list-requ...@python.org
wrote:
> On Sat, Mar 30, 2019, 5:32 AM Alexey Muranov
>
> wrote:
>
>>
>> On ven., Mar 29, 2019 at 4:51 PM, python-list-requ...@python.org
>> wrote:
>> >
>> > There could perhaps be a special case for lambda expressions
such
>> > that,
>> > when they are directly assigned to a variable, Python would
use
>> the
>> > variable name as the function name. I expect this could be
>> > accomplished by
>> > a straightforward transformation of the AST, perhaps even by
just
>> > replacing
>> > the assignment with a def statement.
>>
>> If this will happen, that is, if in Python assigning a
>> lambda-defined
>> function to a variable will mutate the function's attributes, or
>> else,
>> if is some "random" syntactically-determined cases
>>
>> f = ...
>>
>> will stop being the same as evaluating the right-hand side and
>> assigning the result to "f" variable, it will be a fairly good
extra
>> reason for me to go away from Python.
>>
>
> Is there a particular reason you don't like this? It's not too
> different
> from the syntactic magic Python already employs to support the
> 0-argument
> form of super().
I do not want any magic in a programming language i use, especially
if
it breaks simple rules.
I do not like 0-argument `super()` either, but at least I do not
have
to use it.
Well, you wouldn't have to use my suggestion either, since it only
applies
to assignments of the form "f = lambda x: blah". As has already been
stated, the preferred way to do this is with a def statement. So just
use a
def statement for this, and it wouldn't affect you (unless you
*really*
want the function's name to be "" for some reason).
I only see a superficial analogy with `super()`, but perhaps it is
because you did not give much details of you suggestion.
Not only i do not have to use `super()` (i do not have to use Python
either), but the magic behaviour of `super` is explained by special
implicit environments in which some blocks of code are executed.
Though this looks somewhat hackish, it gives me no clue of how your
idea of mutating objects during assignment is supposed to work.
On the other hand, i do use assignment in Python, and you seem to
propose to get rid of assignment or to break it.
Note that
foo.bar = baz
and
foo[bar] = baz
are not assignments but method calls, but
foo = bar
it an assignment (if i understand the current model correctly).
Do you propose to desugar it into a method/function call and to get rid
of assignments in the language completely? Will the user be able to
override this method? Something like:
setvar("foo", bar) # desugaring of foo = bar
Would the assignment operation remain in the language under a different
name? Maybe,
foo <- bar
?
I am so perplexed by the proposed behaviour of `f = lambda...`, that i
need to ask the followng: am i right to expact that
1.
f = lambda x: x,
g = lambda x: x*x
2.
(f, g) = (lambda x: x, lambda x: x*x)
3.
(f, g) = _ = (lambda x: x, lambda x: x*x)
4.
f = (lambda x: x)(lambda x: x)
g = (lambda x: x)(lambda x: x*x)
Will all have the same net effect?
I suppose in any case that
return lambda x:
and
result = lambda x:
return result
would not return the same result, which is not what i want.
I tried to imagine what semantics of the language could cause your
proposed behaviour of `f = lambda...` and couldn't think of anything
short of breaking the language.
That said, that's also the reason why this probably wouldn't happen.
Why go
to the trouble of fixing people's lambda assignments for them when the
preferred fix would be for them to do it themselves by replacing them
with
def statements?
It is not fixing, it is breaking.
Alexey.
--
https://mail.python.org/mailman/listinfo/python-list
RE: Syntax for one-line "nonymous" functions in "declaration style"
Re: ">> Neither i like how a function magically turns into a generator if the >> keyword `yield` appears somewhere within its definition. > I agree, there should have been a required syntactic element on the "def" > line as well to signal it immediately to the reader. It won't stop me from > using them, though." One way to save people looking at the code from having to look through a function for a yield statement to see if it is a generator would be to add a """doc string""" immediately after the function def, saying that it is a generator and describing what it does. I realize I'm calling on the programmer to address this issue by adding doc strings. Nonetheless adding doc strings is a good habit to get in to. --- Joseph S. -Original Message- From: Ian Kelly Sent: Sunday, March 31, 2019 3:45 PM To: Python Subject: Re: Syntax for one-line "nonymous" functions in "declaration style" On Sun, Mar 31, 2019 at 1:09 PM Alexey Muranov wrote: > > On dim., Mar 31, 2019 at 6:00 PM, python-list-requ...@python.org wrote: > > On Sat, Mar 30, 2019, 5:32 AM Alexey Muranov > > > > wrote: > > > >> > >> On ven., Mar 29, 2019 at 4:51 PM, python-list-requ...@python.org > >> wrote: > >> > > >> > There could perhaps be a special case for lambda expressions > >> such > that, > when they are directly assigned to a variable, > >> Python would use the > variable name as the function name. I > >> expect this could be > accomplished by > a straightforward > >> transformation of the AST, perhaps even by just > replacing > > >> the assignment with a def statement. > >> > >> If this will happen, that is, if in Python assigning a > >> lambda-defined function to a variable will mutate the function's > >> attributes, or else, if is some "random" syntactically-determined > >> cases > >> > >> f = ... > >> > >> will stop being the same as evaluating the right-hand side and > >> assigning the result to "f" variable, it will be a fairly good > >> extra reason for me to go away from Python. > >> > > > > Is there a particular reason you don't like this? It's not too > > different from the syntactic magic Python already employs to support > > the 0-argument form of super(). > > I do not want any magic in a programming language i use, especially if > it breaks simple rules. > > I do not like 0-argument `super()` either, but at least I do not have > to use it. Well, you wouldn't have to use my suggestion either, since it only applies to assignments of the form "f = lambda x: blah". As has already been stated, the preferred way to do this is with a def statement. So just use a def statement for this, and it wouldn't affect you (unless you *really* want the function's name to be "" for some reason). That said, that's also the reason why this probably wouldn't happen. Why go to the trouble of fixing people's lambda assignments for them when the preferred fix would be for them to do it themselves by replacing them with def statements? > Neither i like how a function magically turns into a generator if the > keyword `yield` appears somewhere within its definition. I agree, there should have been a required syntactic element on the "def" line as well to signal it immediately to the reader. It won't stop me from using them, though. -- https://mail.python.org/mailman/listinfo/python-list
Re: Syntax for one-line "nonymous" functions in "declaration style"
On Sun, Mar 31, 2019 at 1:09 PM Alexey Muranov wrote: > > On dim., Mar 31, 2019 at 6:00 PM, python-list-requ...@python.org wrote: > > On Sat, Mar 30, 2019, 5:32 AM Alexey Muranov > > > > wrote: > > > >> > >> On ven., Mar 29, 2019 at 4:51 PM, python-list-requ...@python.org > >> wrote: > >> > > >> > There could perhaps be a special case for lambda expressions such > >> > that, > >> > when they are directly assigned to a variable, Python would use > >> the > >> > variable name as the function name. I expect this could be > >> > accomplished by > >> > a straightforward transformation of the AST, perhaps even by just > >> > replacing > >> > the assignment with a def statement. > >> > >> If this will happen, that is, if in Python assigning a > >> lambda-defined > >> function to a variable will mutate the function's attributes, or > >> else, > >> if is some "random" syntactically-determined cases > >> > >> f = ... > >> > >> will stop being the same as evaluating the right-hand side and > >> assigning the result to "f" variable, it will be a fairly good extra > >> reason for me to go away from Python. > >> > > > > Is there a particular reason you don't like this? It's not too > > different > > from the syntactic magic Python already employs to support the > > 0-argument > > form of super(). > > I do not want any magic in a programming language i use, especially if > it breaks simple rules. > > I do not like 0-argument `super()` either, but at least I do not have > to use it. Well, you wouldn't have to use my suggestion either, since it only applies to assignments of the form "f = lambda x: blah". As has already been stated, the preferred way to do this is with a def statement. So just use a def statement for this, and it wouldn't affect you (unless you *really* want the function's name to be "" for some reason). That said, that's also the reason why this probably wouldn't happen. Why go to the trouble of fixing people's lambda assignments for them when the preferred fix would be for them to do it themselves by replacing them with def statements? > Neither i like how a function magically turns into a generator if the > keyword `yield` appears somewhere within its definition. I agree, there should have been a required syntactic element on the "def" line as well to signal it immediately to the reader. It won't stop me from using them, though. -- https://mail.python.org/mailman/listinfo/python-list
Re: Syntax for one-line "nonymous" functions in "declaration style"
On dim., Mar 31, 2019 at 6:00 PM, python-list-requ...@python.org wrote: On Sat, Mar 30, 2019, 5:32 AM Alexey Muranov wrote: On ven., Mar 29, 2019 at 4:51 PM, python-list-requ...@python.org wrote: > > There could perhaps be a special case for lambda expressions such > that, > when they are directly assigned to a variable, Python would use the > variable name as the function name. I expect this could be > accomplished by > a straightforward transformation of the AST, perhaps even by just > replacing > the assignment with a def statement. If this will happen, that is, if in Python assigning a lambda-defined function to a variable will mutate the function's attributes, or else, if is some "random" syntactically-determined cases f = ... will stop being the same as evaluating the right-hand side and assigning the result to "f" variable, it will be a fairly good extra reason for me to go away from Python. Is there a particular reason you don't like this? It's not too different from the syntactic magic Python already employs to support the 0-argument form of super(). I do not want any magic in a programming language i use, especially if it breaks simple rules. I do not like 0-argument `super()` either, but at least I do not have to use it. I am suspicious of `__class__` too. But here only identifiers are hacked, not the assignment operator. (I suppose the hack can be unhacked by using your own meta-class with a custom `__prepare__`.) Neither i like how a function magically turns into a generator if the keyword `yield` appears somewhere within its definition. Those are the things i don't like the most in Python. Alexey. -- https://mail.python.org/mailman/listinfo/python-list
Re: Syntax for one-line "nonymous" functions in "declaration style"
On Sat, Mar 30, 2019, 5:32 AM Alexey Muranov wrote: > > On ven., Mar 29, 2019 at 4:51 PM, python-list-requ...@python.org wrote: > > > > There could perhaps be a special case for lambda expressions such > > that, > > when they are directly assigned to a variable, Python would use the > > variable name as the function name. I expect this could be > > accomplished by > > a straightforward transformation of the AST, perhaps even by just > > replacing > > the assignment with a def statement. > > If this will happen, that is, if in Python assigning a lambda-defined > function to a variable will mutate the function's attributes, or else, > if is some "random" syntactically-determined cases > > f = ... > > will stop being the same as evaluating the right-hand side and > assigning the result to "f" variable, it will be a fairly good extra > reason for me to go away from Python. > Is there a particular reason you don't like this? It's not too different from the syntactic magic Python already employs to support the 0-argument form of super(). -- https://mail.python.org/mailman/listinfo/python-list
Re: Syntax for one-line "nonymous" functions in "declaration style"
On ven., Mar 29, 2019 at 4:51 PM, python-list-requ...@python.org wrote: On Thu, Mar 28, 2019 at 2:30 PM Alexey Muranov wrote: On jeu., mars 28, 2019 at 8:57 PM, Terry Reedy wrote: > Throwing the name away is foolish. Testing functions is another > situation in which function names are needed for proper report. My idea however was to have it as an exact synonyme of an assignment of a lambda. Assignment is an assignment, it should not modify the attributs of the value that is being assigned. There could perhaps be a special case for lambda expressions such that, when they are directly assigned to a variable, Python would use the variable name as the function name. I expect this could be accomplished by a straightforward transformation of the AST, perhaps even by just replacing the assignment with a def statement. If this will happen, that is, if in Python assigning a lambda-defined function to a variable will mutate the function's attributes, or else, if is some "random" syntactically-determined cases f = ... will stop being the same as evaluating the right-hand side and assigning the result to "f" variable, it will be a fairly good extra reason for me to go away from Python. Since this could just as easily be applied to lambda though, I'm afraid it doesn't offer much of a case for the "f(x)" syntactic sugar. I did not get this. My initial idea was exactly about introducing a syntactic sugar for better readability. I've already understood that the use cases contradict PEP 8 recommendations. Alexey. -- https://mail.python.org/mailman/listinfo/python-list
Re: Syntax for one-line "nonymous" functions in "declaration style"
On 27/03/19 09:21, Alexey Muranov wrote: > Whey you need a simple function in Python, there is a choice between a > normal function declaration and an assignment of a anonymous function > (defined by a lambda-expression) to a variable: > > def f(x): return x*x > > or > > f = lambda x: x*x > > It would be however more convenient to be able to write instead just > > f(x) = x*x I have mixed feelings about this. I think anonymous functions only have a place as arguments to a function. So f(x) = x * x, doesn't look like an anonymous function but just an other way to have a named fuction. (as others have already pointed out) If we really want an alternative for the lambda expresion, I would go for the following. f = x -> x*x (or maybe we could have the λ instead of lambda) If we want haskell like patterns for defining functions I would go for the following: fac(0) -> 1 fac(n) -> n * fac(n - 1) Which seems incompatible with the proposal for an alternative lambda. -- Antoon Pardon. -- https://mail.python.org/mailman/listinfo/python-list
Re: Syntax for one-line "nonymous" functions in "declaration style"
On 3/28/2019 12:29 PM, Alexey Muranov wrote:
On jeu., Mar 28, 2019 at 5:00 PM, python-list-requ...@python.org wrote:
So my opinion is that lambda expressions should only be used within
larger expressions and never directly bound.
It would be however more convenient to be able to write instead just
f(x) = x*x
Given my view above, this is, standing alone, strictly an abbreviation
of the equivalent def statement. I am presuming that a proper
implementation would result in f.__name__ == 'f'.
No, after some thought, i think it should be an abbreviation of "f =
lambda x: x*x", f.__name__ would still be ''.
Throwing the name away is foolish. Testing functions is another
situation in which function names are needed for proper report. I wrote
and use a test function something like the following, simplified and
adapted for use with unittest:
def ftest(func, io_pairs):
errors = []
for input, expected in io_pairs:
actual = func(input)
if actual != expected:
errors.append(
f"Func: {func.__name__}, input: {input}, "
f"expected: {expected}, actual: {actual}.")
return errors if errors else None
(Then "self.assertNone(ftest(func, io_pairs))" will test all pairs and
list at least part of the error list.)
If all the names were '', not very useful. (The workaround
would be to require the caller to know a name and pass it separately,
without mis-typing.)
for unittest, a
But i see your point about never assigning lambdas directly, it makes
sense. But sometimes i do assign short lambdas directly to variable.
Is the convenience and (very low) frequency of applicability worth the
inconvenience of confusing the meaning of '=' and complicating the
implementation?
I do not see any conflicts with the existing syntax.
It heavily conflicts with existing syntax. The current meaning of
target_expression = object_expression
is
1. Evaluate object_expression in the existing namespace to an object,
prior to any new bindings and independent of the target_expression.
2. Evaluate target_expression in the existing namespace to one or more
targets.
3. Bind object to target or iterate target to bind to multiple targets.
I do not thick so. In "x = 42" the variable x is not evaluated.
All examples of the proposed syntax i can think of are currently
illegal, so i suppose there is no conflicts. (I would appreciate a
counterexample, if any.)
You are talking about syntax conflicts, I am talking about semantic
conflict, which is important for human understanding.
Thanks for the reference to PEP 8, this is indeed an argument against.
The situation in which assigning lambda expressions is more tempting is
when assigning to attributes or dicts.
def double(x): return x*x
C.double = double
d['double'] = double
versus
C.double = lambda x: x*x
d['double'] = lambda x: x*x
For attributes, "def C.double(x): return x*x" has been proposed but not
accepted.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Syntax for one-line "nonymous" functions in "declaration style"
On Fri, Mar 29, 2019 at 7:29 AM Alexey Muranov wrote: > My idea however was to have it as an exact synonyme of an assignment of > a lambda. Assignment is an assignment, it should not modify the > attributs of the value that is being assigned. Assigning lambda functions to names generally shouldn't be done. Just use def. You're asking for another way to do a bad thing that has a better alternative. There have periodically been proposals for the opposite, which would take care of some of the alternatives: def op["double"](x): return x * x This kind of proposal has its own issues, but I think it has a much better chance of being accepted than a way of creating and assigning lambda functions. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Syntax for one-line "nonymous" functions in "declaration style"
On Thu, Mar 28, 2019 at 2:30 PM Alexey Muranov wrote: > > On jeu., mars 28, 2019 at 8:57 PM, Terry Reedy wrote: > > Throwing the name away is foolish. Testing functions is another > > situation in which function names are needed for proper report. > > My idea however was to have it as an exact synonyme of an assignment of > a lambda. Assignment is an assignment, it should not modify the > attributs of the value that is being assigned. There could perhaps be a special case for lambda expressions such that, when they are directly assigned to a variable, Python would use the variable name as the function name. I expect this could be accomplished by a straightforward transformation of the AST, perhaps even by just replacing the assignment with a def statement. Since this could just as easily be applied to lambda though, I'm afraid it doesn't offer much of a case for the "f(x)" syntactic sugar. -- https://mail.python.org/mailman/listinfo/python-list
Re: Syntax for one-line "nonymous" functions in "declaration style"
On jeu., mars 28, 2019 at 5:00 PM, python-list-requ...@python.org wrote: So documentation of that syntax would 100% be required Regarding documentation, i believe there would be 3 line to add: () = is a syntactic sugar for = lambda : Alexey. -- https://mail.python.org/mailman/listinfo/python-list
Re: Syntax for one-line "nonymous" functions in "declaration style"
On jeu., mars 28, 2019 at 8:57 PM, Terry Reedy wrote: On 3/28/2019 12:29 PM, Alexey Muranov wrote: On jeu., Mar 28, 2019 at 5:00 PM, python-list-requ...@python.org wrote: So my opinion is that lambda expressions should only be used within larger expressions and never directly bound. It would be however more convenient to be able to write instead just f(x) = x*x Given my view above, this is, standing alone, strictly an abbreviation of the equivalent def statement. I am presuming that a proper implementation would result in f.__name__ == 'f'. No, after some thought, i think it should be an abbreviation of "f = lambda x: x*x", f.__name__ would still be ''. Throwing the name away is foolish. Testing functions is another situation in which function names are needed for proper report. My idea however was to have it as an exact synonyme of an assignment of a lambda. Assignment is an assignment, it should not modify the attributs of the value that is being assigned. But i see your point about never assigning lambdas directly, it makes sense. But sometimes i do assign short lambdas directly to variable. Is the convenience and (very low) frequency of applicability worth the inconvenience of confusing the meaning of '=' and complicating the implementation? I do not see any conflicts with the existing syntax. It heavily conflicts with existing syntax. The current meaning of target_expression = object_expression is 1. Evaluate object_expression in the existing namespace to an object, prior to any new bindings and independent of the target_expression. 2. Evaluate target_expression in the existing namespace to one or more targets. 3. Bind object to target or iterate target to bind to multiple targets. I do not thick so. In "x = 42" the variable x is not evaluated. All examples of the proposed syntax i can think of are currently illegal, so i suppose there is no conflicts. (I would appreciate a counterexample, if any.) You are talking about syntax conflicts, I am talking about semantic conflict, which is important for human understanding. Thanks for the reference to PEP 8, this is indeed an argument against. The situation in which assigning lambda expressions is more tempting is when assigning to attributes or dicts. def double(x): return x*x C.double = double d['double'] = double versus C.double = lambda x: x*x d['double'] = lambda x: x*x These are some of examples i had in mind as well: C.double(x) = x*x d['double'](x) = x*x Alexey. -- https://mail.python.org/mailman/listinfo/python-list
Re: Syntax for one-line "nonymous" functions in "declaration style"
On jeu., mars 28, 2019 at 8:57 PM, Terry Reedy wrote: But i see your point about never assigning lambdas directly, it makes sense. But sometimes i do assign short lambdas directly to variable. Is the convenience and (very low) frequency of applicability worth the inconvenience of confusing the meaning of '=' and complicating the implementation? I do not see any conflicts with the existing syntax. It heavily conflicts with existing syntax. The current meaning of target_expression = object_expression is 1. Evaluate object_expression in the existing namespace to an object, prior to any new bindings and independent of the target_expression. 2. Evaluate target_expression in the existing namespace to one or more targets. 3. Bind object to target or iterate target to bind to multiple targets. I do not thick so. In "x = 42" the variable x is not evaluated. All examples of the proposed syntax i can think of are currently illegal, so i suppose there is no conflicts. (I would appreciate a counterexample, if any.) You are talking about syntax conflicts, I am talking about semantic conflict, which is important for human understanding. I believe there is no semantic conflict either, or could you be more specific? Alexey. -- https://mail.python.org/mailman/listinfo/python-list
Re: Syntax for one-line "nonymous" functions in "declaration style"
On jeu., mars 28, 2019 at 5:00 PM, python-list-requ...@python.org wrote: On 2019-03-27 10:42 a.m., Paul Moore wrote: On Wed, 27 Mar 2019 at 12:27, Alexey Muranov wrote: On mer., mars 27, 2019 at 10:10 AM, Paul Moore wrote: On Wed, 27 Mar 2019 at 08:25, Alexey Muranov wrote: Whey you need a simple function in Python, there is a choice between a normal function declaration and an assignment of a anonymous function (defined by a lambda-expression) to a variable: def f(x): return x*x or f = lambda x: x*x It would be however more convenient to be able to write instead just f(x) = x*x Why? Is saving a few characters really that helpful? So much so that it's worth adding a *third* method of defining functions, which would need documenting, adding to training materials, etc, etc? Because i think i would prefer to write it this way. That's not likely to be sufficient reason for changing a language that's used by literally millions of people. (Almost no new documentation or tutorials would be needed IMHO.) Documentation would be needed to explain how the new construct worked, for people who either wanted to use it or encountered it in other people's code. While it may be obvious to you how it works, it likely won't be to others, and there will probably be edge cases you haven't considered that others will find and ask about. For what it's worth, if I encountered "f(x) = x * x" in code, my first thought would be that Python somehow added a way to return an assignable reference from a function, rather than this being an anonymous function declaration. So documentation of that syntax would 100% be required Alex The thing to the right of the assignment symbol represents a value (an object), but the thing to the left does not represent a value, it represents a place for a value. What would an "assignable reference" mean? Say, variable "x" holds an "assignable reference", what can be done next? Alexey. -- https://mail.python.org/mailman/listinfo/python-list
Re: Syntax for one-line "nonymous" functions in "declaration style"
On Wed, Mar 27, 2019 at 3:13 AM Paul Moore wrote: > > On Wed, 27 Mar 2019 at 08:25, Alexey Muranov wrote: > > > > Whey you need a simple function in Python, there is a choice between a > > normal function declaration and an assignment of a anonymous function > > (defined by a lambda-expression) to a variable: > > > > def f(x): return x*x > > > > or > > > > f = lambda x: x*x > > > > It would be however more convenient to be able to write instead just > > > > f(x) = x*x > > Why? Is saving a few characters really that helpful? So much so that > it's worth adding a *third* method of defining functions, which would > need documenting, adding to training materials, etc, etc? Well, it does seem a bit silly to have more ways of formatting strings than of defining functions. We have four of the former, so clearly we need to address this by adding two more of the latter. -- https://mail.python.org/mailman/listinfo/python-list
Re: Syntax for one-line "nonymous" functions in "declaration style"
On jeu., Mar 28, 2019 at 5:00 PM, python-list-requ...@python.org wrote: So my opinion is that lambda expressions should only be used within larger expressions and never directly bound. It would be however more convenient to be able to write instead just f(x) = x*x Given my view above, this is, standing alone, strictly an abbreviation of the equivalent def statement. I am presuming that a proper implementation would result in f.__name__ == 'f'. No, after some thought, i think it should be an abbreviation of "f = lambda x: x*x", f.__name__ would still be ''. But i see your point about never assigning lambdas directly, it makes sense. But sometimes i do assign short lambdas directly to variable. Is the convenience and (very low) frequency of applicability worth the inconvenience of confusing the meaning of '=' and complicating the implementation? I do not see any conflicts with the existing syntax. It heavily conflicts with existing syntax. The current meaning of target_expression = object_expression is 1. Evaluate object_expression in the existing namespace to an object, prior to any new bindings and independent of the target_expression. 2. Evaluate target_expression in the existing namespace to one or more targets. 3. Bind object to target or iterate target to bind to multiple targets. I do not thick so. In "x = 42" the variable x is not evaluated. All examples of the proposed syntax i can think of are currently illegal, so i suppose there is no conflicts. (I would appreciate a counterexample, if any.) Thanks for the reference to PEP 8, this is indeed an argument against. Alexey. -- https://mail.python.org/mailman/listinfo/python-list
Re: Syntax for one-line "nonymous" functions in "declaration style"
On 27/03/19 22:25, Terry Reedy wrote: > ... > > Before 3.8, I would stop here and say no to the proposal. But we now > have assignment expressions in addition to assignment statements. > > >>> int(s:='42'+'742') > 42742 > >>> s > '42742' > > To me, function assignment expressions, as a enhanced replacement for > lambda expressions, is more inviting than function assignment > statements as an abbreviation for function definition statements. > > In other words, replace > > map(lambda x: x*x, range(10)) > > with > > map(square(x):=x*x, range(10)) > > or, if one does not want a specific name, > > map(_(x):=x*x, range(10)) > > Many people dislike lambda expressions, to the point that Guido > considered leaving them out of 3.x. So this replacement might get > more traction. It would make assignment expressions much more useful. I think map is not a good example, since I would just replace them with Since we are talking python 3.8 why not just use a generator here: (x*x for x in range(10)) instead of map? -- https://mail.python.org/mailman/listinfo/python-list
Re: Syntax for one-line "nonymous" functions in "declaration style"
Alexey Muranov writes: > It would be however more convenient to be able to write instead just > >f(x) = x*x That's not an anonymous function then, is it? You want to assign a name to that function, and (to be useful in development tools, such as a stack trace) the function needs to know its own name. The way to do that is, as you point out, the ‘def’ statement: def f(x): return (x * x) What does that prevent you from doing? It will need to be pretty significant improvement to be considered as a change to language syntax. > Have this idea been discussed before? Too many times to count :-) -- \ “Theology is the effort to explain the unknowable in terms of | `\ the not worth knowing.” —Henry L. Mencken | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Syntax for one-line "nonymous" functions in "declaration style"
On 3/27/2019 4:21 AM, Alexey Muranov wrote:
Whey you need a simple function in Python, there is a choice between a
normal function declaration and an assignment of a anonymous function
(defined by a lambda-expression) to a variable:
def f(x): return x*x
or
f = lambda x: x*x
PEP 8 properly recommends against this the latter as functionally it has
no advantage and the disadvantage that f.__name__ becomes the generic
'' instead of the specific 'f'. This is not useful for code
that expects specific names. Tracebacks are one example. Here is
another intended to list callable objects and their types.
def call_clas(container):
for item in vars(container).values():
if hasattr(item, '__call__'):
yield item.__name__, item.__class__
def print_cc(container):
for name, clas in call_clas(container):
print(f'{name:30s}{clas}')
# Examples.
print_cc(int)
from idlelib import pyshell
print_cc(pyshell)
Multiple output lines of ' function' defeat the
purpose.
So my opinion is that lambda expressions should only be used within
larger expressions and never directly bound.
It would be however more convenient to be able to write instead just
f(x) = x*x
Given my view above, this is, standing alone, strictly an abbreviation
of the equivalent def statement. I am presuming that a proper
implementation would result in f.__name__ == 'f'.
Is the convenience and (very low) frequency of applicability worth the
inconvenience of confusing the meaning of '=' and complicating the
implementation?
I do not see any conflicts with the existing syntax.
It heavily conflicts with existing syntax. The current meaning of
target_expression = object_expression
is
1. Evaluate object_expression in the existing namespace to an object,
prior to any new bindings and independent of the target_expression.
2. Evaluate target_expression in the existing namespace to one or more
targets.
3. Bind object to target or iterate target to bind to multiple targets.
Part of step 2 is making calls, because calls cannot be targets. This
is why 'f(a+b)[c] = d' can work. Note that 'a+b' makes calls to
a.__add__ or b.__radd__ or both.
In the proposal, the treatment of the object expression would depend on
the target expression and the alternative would be to quote it as code;
compile the code in a manner that depends on the target expression to
mark local names versus global names; and finally make a function
instance, presumably taking __name__ from the target.
This would have the advantage over lambda assignment of getting the name
right, but I don't think one should be doing lambda assignment anyway.
There is a good reason to have a separate syntax.
Before 3.8, I would stop here and say no to the proposal. But we now
have assignment expressions in addition to assignment statements.
>>> int(s:='42'+'742')
42742
>>> s
'42742'
To me, function assignment expressions, as a enhanced replacement for
lambda expressions, is more inviting than function assignment statements
as an abbreviation for function definition statements.
In other words, replace
map(lambda x: x*x, range(10))
with
map(square(x):=x*x, range(10))
or, if one does not want a specific name,
map(_(x):=x*x, range(10))
Many people dislike lambda expressions, to the point that Guido
considered leaving them out of 3.x. So this replacement might get more
traction. It would make assignment expressions much more useful.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: Syntax for one-line "nonymous" functions in "declaration style"
On mer., Mar 27, 2019 at 5:00 PM, python-list-requ...@python.org wrote: On 27/03/19 09:21, Alexey Muranov wrote: Whey you need a simple function in Python, there is a choice between a normal function declaration and an assignment of a anonymous function (defined by a lambda-expression) to a variable: def f(x): return x*x or f = lambda x: x*x It would be however more convenient to be able to write instead just f(x) = x*x (like in Haskell and such). Have this idea been discussed before? I do not see any conflicts with the existing syntax. The following would also work: I don't know. Something like the following is already legal: f(x)[n] = x * n And it does something completly different. Thanks for pointing out this example, but so far i do not see any issue with this. Of course assignment (to an identifier) is a completely different type of operation than in-place mutation (of an object) with __setitem__, etc. In <...> [<...>] = <...> the part to the left of "[<...>]=" is an expression that is to be evaluated, and only its value matters. Here "[]=" can be viewed as a method call, which is distinguished by the context from "[]" method call (__getitem__). In = <...> the is not evaluated. I still think that ()...() = <...> is unambiguous. The following seems possible too: a[m][n](x)(y) = m*x + n*y It would be the same as a[m][n] = lambda x: lambda y: m*x + n*y Here a[m] is evaluated, and on the result the method "[]=" (__setitem__) is called. Basically, "()...()=" seems to technically fit all contexts where "=" fits... Alexey. -- https://mail.python.org/mailman/listinfo/python-list
Re: Syntax for one-line "nonymous" functions in "declaration style"
On 2019-03-27 10:42 a.m., Paul Moore wrote: > On Wed, 27 Mar 2019 at 12:27, Alexey Muranov wrote: >> On mer., mars 27, 2019 at 10:10 AM, Paul Moore >> wrote: >>> On Wed, 27 Mar 2019 at 08:25, Alexey Muranov >>> wrote: Whey you need a simple function in Python, there is a choice between a normal function declaration and an assignment of a anonymous function (defined by a lambda-expression) to a variable: def f(x): return x*x or f = lambda x: x*x It would be however more convenient to be able to write instead just f(x) = x*x >>> Why? Is saving a few characters really that helpful? So much so that >>> it's worth adding a *third* method of defining functions, which would >>> need documenting, adding to training materials, etc, etc? >> Because i think i would prefer to write it this way. > That's not likely to be sufficient reason for changing a language > that's used by literally millions of people. > >> (Almost no new documentation or tutorials would be needed IMHO.) > Documentation would be needed to explain how the new construct worked, > for people who either wanted to use it or encountered it in other > people's code. While it may be obvious to you how it works, it likely > won't be to others, and there will probably be edge cases you haven't > considered that others will find and ask about. For what it's worth, if I encountered "f(x) = x * x" in code, my first thought would be that Python somehow added a way to return an assignable reference from a function, rather than this being an anonymous function declaration. So documentation of that syntax would 100% be required Alex -- https://mail.python.org/mailman/listinfo/python-list
Re: Syntax for one-line "nonymous" functions in "declaration style"
On 27/03/2019 16:15, Bev in TX wrote: On Mar 27, 2019, at 10:41 AM, Antoon Pardon wrote: I don't know. Something like the following is already legal: f(x)[n] = x * n And it does something completly different. Where would I find information on what this does in the documentation? Nowhere in particular, it's a consequence of putting things together. The part that Antoon isn't mentioning is that he's presuming the function f(x) returns a list or something similar that we can then index. You're more likely to see that sort of code written as: a = f(x) a[n] = x *n which makes it look a lot less magical. -- Rhodri James *-* Kynesim Ltd -- https://mail.python.org/mailman/listinfo/python-list
Re: Syntax for one-line "nonymous" functions in "declaration style"
> On Mar 27, 2019, at 10:41 AM, Antoon Pardon wrote: > > I don't know. Something like the following is already legal: > > f(x)[n] = x * n > > And it does something completly different. Where would I find information on what this does in the documentation? Bev in TX -- https://mail.python.org/mailman/listinfo/python-list
Re: Syntax for one-line "nonymous" functions in "declaration style"
On 27/03/19 09:21, Alexey Muranov wrote: > Whey you need a simple function in Python, there is a choice between a > normal function declaration and an assignment of a anonymous function > (defined by a lambda-expression) to a variable: > > def f(x): return x*x > > or > > f = lambda x: x*x > > It would be however more convenient to be able to write instead just > > f(x) = x*x > > (like in Haskell and such). > > Have this idea been discussed before? > > I do not see any conflicts with the existing syntax. The following > would also work: I don't know. Something like the following is already legal: f(x)[n] = x * n And it does something completly different. -- Antoon Pardon. -- https://mail.python.org/mailman/listinfo/python-list
Re: Syntax for one-line "nonymous" functions in "declaration style"
On Wed, 27 Mar 2019 at 12:27, Alexey Muranov wrote: > > On mer., mars 27, 2019 at 10:10 AM, Paul Moore > wrote: > > On Wed, 27 Mar 2019 at 08:25, Alexey Muranov > > wrote: > >> > >> Whey you need a simple function in Python, there is a choice > >> between a > >> normal function declaration and an assignment of a anonymous > >> function > >> (defined by a lambda-expression) to a variable: > >> > >> def f(x): return x*x > >> > >> or > >> > >> f = lambda x: x*x > >> > >> It would be however more convenient to be able to write instead just > >> > >> f(x) = x*x > > > > Why? Is saving a few characters really that helpful? So much so that > > it's worth adding a *third* method of defining functions, which would > > need documenting, adding to training materials, etc, etc? > > Because i think i would prefer to write it this way. That's not likely to be sufficient reason for changing a language that's used by literally millions of people. > (Almost no new documentation or tutorials would be needed IMHO.) Documentation would be needed to explain how the new construct worked, for people who either wanted to use it or encountered it in other people's code. While it may be obvious to you how it works, it likely won't be to others, and there will probably be edge cases you haven't considered that others will find and ask about. Your interest in improving the language is great, but there are a great many practical considerations in any change, and if you actually want your idea to progress, you'll need to be prepared to address those. Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: Syntax for one-line "nonymous" functions in "declaration style"
On mer., mars 27, 2019 at 10:10 AM, Paul Moore wrote: On Wed, 27 Mar 2019 at 08:25, Alexey Muranov wrote: Whey you need a simple function in Python, there is a choice between a normal function declaration and an assignment of a anonymous function (defined by a lambda-expression) to a variable: def f(x): return x*x or f = lambda x: x*x It would be however more convenient to be able to write instead just f(x) = x*x Why? Is saving a few characters really that helpful? So much so that it's worth adding a *third* method of defining functions, which would need documenting, adding to training materials, etc, etc? Because i think i would prefer to write it this way. (Almost no new documentation or tutorials would be needed IMHO.) Alexey. -- https://mail.python.org/mailman/listinfo/python-list
Re: Syntax for one-line "nonymous" functions in "declaration style"
On Wed, 27 Mar 2019 at 08:25, Alexey Muranov wrote: > > Whey you need a simple function in Python, there is a choice between a > normal function declaration and an assignment of a anonymous function > (defined by a lambda-expression) to a variable: > > def f(x): return x*x > > or > > f = lambda x: x*x > > It would be however more convenient to be able to write instead just > > f(x) = x*x Why? Is saving a few characters really that helpful? So much so that it's worth adding a *third* method of defining functions, which would need documenting, adding to training materials, etc, etc? -1 on this. Paul -- https://mail.python.org/mailman/listinfo/python-list
