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

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

Where to suggest improvements in the official Python documentation?

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

Contents

  Where to suggest improvements in the official Python documentation? Aseem Bansal <asmbansal2@gmail.com> - 2013-08-03 10:53 -0700
    Re: Where to suggest improvements in the official Python documentation? Joel Goldstick <joel.goldstick@gmail.com> - 2013-08-03 14:23 -0400
    Re: Where to suggest improvements in the official Python documentation? Terry Reedy <tjreedy@udel.edu> - 2013-08-03 16:43 -0400
      Re: Where to suggest improvements in the official Python documentation? Aseem Bansal <asmbansal2@gmail.com> - 2013-08-04 09:30 -0700
        Re: Where to suggest improvements in the official Python documentation? Joel Goldstick <joel.goldstick@gmail.com> - 2013-08-04 14:34 -0400
          Re: Where to suggest improvements in the official Python documentation? Aseem Bansal <asmbansal2@gmail.com> - 2013-08-20 07:22 -0700
            Re: Where to suggest improvements in the official Python documentation? Joel Goldstick <joel.goldstick@gmail.com> - 2013-08-20 10:57 -0400
        Functional Programming and python rusi <rustompmody@gmail.com> - 2013-09-22 19:21 -0700
          Re: Functional Programming and python Vito De Tullio <vito.detullio@gmail.com> - 2013-09-23 20:24 +0200
            Re: Functional Programming and python Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2013-09-24 10:06 +0300
            Re: Functional Programming and python rusi <rustompmody@gmail.com> - 2013-09-24 00:08 -0700
              Re: Functional Programming and python Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2013-09-24 10:42 +0300
                Re: Functional Programming and python rusi <rustompmody@gmail.com> - 2013-09-24 05:14 -0700
                  Re: Functional Programming and python Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2013-09-24 17:51 +0300
                    Re: Functional Programming and python rusi <rustompmody@gmail.com> - 2013-09-24 08:07 -0700
                      Re: Functional Programming and python Chris Angelico <rosuav@gmail.com> - 2013-09-25 01:26 +1000
                        Re: Functional Programming and python rusi <rustompmody@gmail.com> - 2013-09-24 10:25 -0700
          Re: Functional Programming and python Franck Ditter <nobody@nowhere.org> - 2013-09-30 19:04 +0200
            Re: Functional Programming and python Chris Angelico <rosuav@gmail.com> - 2013-10-01 03:17 +1000
            Re: Functional Programming and python Neil Cerutti <neilc@norwich.edu> - 2013-09-30 18:36 +0000
              Re: Functional Programming and python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-01 00:14 +0000
                Re: Functional Programming and python Neil Cerutti <neilc@norwich.edu> - 2013-10-01 13:59 +0000
            Re: Functional Programming and python Piet van Oostrum <piet@vanoostrum.org> - 2013-09-30 14:55 -0400
              Re: Functional Programming and python Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-09-30 22:37 +0200
                Re: Functional Programming and python Piet van Oostrum <piet@vanoostrum.org> - 2013-10-01 13:31 -0400
            Re: Functional Programming and python Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-09-30 20:29 +0200
            Re: Functional Programming and python Tim Chase <python.list@tim.thechases.com> - 2013-09-30 16:02 -0500
            Re: Functional Programming and python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-01 00:41 +0000
            Re: Functional Programming and python alex23 <wuwei23@gmail.com> - 2013-10-01 11:03 +1000
            Re: Functional Programming and python Terry Reedy <tjreedy@udel.edu> - 2013-09-30 21:03 -0400
              Re: Functional Programming and python rusi <rustompmody@gmail.com> - 2013-09-30 18:36 -0700
                Re: Functional Programming and python Chris Angelico <rosuav@gmail.com> - 2013-10-01 17:28 +1000

Page 1 of 2  [1] 2  Next page →

#51874 — Where to suggest improvements in the official Python documentation?

I have a suggestion about the Python tutorial for improvement. Specifically about in Python tutorial 4.7.5 lambda forms.
http://docs.python.org/3/tutorial/controlflow.html#lambda-forms

It is not very clear from the tutorial what lambda forms are for someone who doesn't know functional programming. I think placing a link of "functional Programming HOWTO" of Python documentation can take out much confusion for Python newbies.

I would like to suggest this because as I newbiw I had much confusion 2 months back before I could figure out its proper use. Where do I suggest this improvement?

[toc] | [next] | [standalone]

#51876

On Sat, Aug 3, 2013 at 1:53 PM, Aseem Bansal <asmbansal2@gmail.com> wrote:
> I have a suggestion about the Python tutorial for improvement. Specifically about in Python tutorial 4.7.5 lambda forms.
> http://docs.python.org/3/tutorial/controlflow.html#lambda-forms
>
> It is not very clear from the tutorial what lambda forms are for someone who doesn't know functional programming. I think placing a link of "functional Programming HOWTO" of Python documentation can take out much confusion for Python newbies.
>
> I would like to suggest this because as I newbiw I had much confusion 2 months back before I could figure out its proper use. Where do I suggest this improvement?
> --
> http://mail.python.org/mailman/listinfo/python-list

http://docs.python.org/2/bugs.html

-- 
Joel Goldstick
http://joelgoldstick.com

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

#51887

On 8/3/2013 2:23 PM, Joel Goldstick wrote:
> On Sat, Aug 3, 2013 at 1:53 PM, Aseem Bansal <asmbansal2@gmail.com>
> wrote:
>> I have a suggestion about the Python tutorial for improvement.
>> Specifically about in Python tutorial 4.7.5 lambda forms.
>> http://docs.python.org/3/tutorial/controlflow.html#lambda-forms
>>
>> It is not very clear from the tutorial what lambda forms are for

They are mostly for passing a one-use function as an argument to another 
function. The tutorial should say that and give an example.

http://bugs.python.org/issue18646

>> someone who doesn't know functional programming. I think placing a
>> link of "functional Programming HOWTO" of Python documentation can
>> take out much confusion for Python newbies.

That document is not about lambda. The word 'lambda' does not appear 
until near the end, and some of the current examples violate PEP 8.

>> I would like to suggest this because as I newbiw I had much
>> confusion 2 months back before I could figure out its proper use.
>> Where do I suggest this improvement? --

> http://docs.python.org/2/bugs.html

-- 
Terry Jan Reedy

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

#51930

@ Terry Jan Reedy

If there is an issue in place for improving the lambda forms then that's good. I wanted a link about functional programming because it is mentioned as if it were a household word.

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

#51936

On Sun, Aug 4, 2013 at 12:30 PM, Aseem Bansal <asmbansal2@gmail.com> wrote:
> @ Terry Jan Reedy
>
> If there is an issue in place for improving the lambda forms then that's good. I wanted a link about functional programming because it is mentioned as if it were a household word.

It depends on your household I suppose!

Have you tried google?

I am having a hard time understanding what your specific question is.
Do you have one?
> --
> http://mail.python.org/mailman/listinfo/python-list



-- 
Joel Goldstick
http://joelgoldstick.com

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

#52734

@Joel Goldstick
> Joel Goldstick
> 
> http://joelgoldstick.com

My specific question was that the Python documentation's tutorial isn't clear when it comes to lambda forms. I just wanted something to be done so it becomes clear for future readers who are not familiar with functional paradigm. I wanted to make a suggestion about adding a link to functional programming to add some clarity.

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

#52735

On Tue, Aug 20, 2013 at 10:22 AM, Aseem Bansal <asmbansal2@gmail.com> wrote:
> @Joel Goldstick
>> Joel Goldstick
>>
>> http://joelgoldstick.com
>
> My specific question was that the Python documentation's tutorial isn't clear when it comes to lambda forms. I just wanted something to be done so it becomes clear for future readers who are not familiar with functional paradigm. I wanted to make a suggestion about adding a link to functional programming to add some clarity.

In my first post above I provided the link for bug reports for python
(including documentation).  This is a volunteer list which is not
officially part of the python.org site.  You might try going to that
link to learn how to submit change requests.
> --
> http://mail.python.org/mailman/listinfo/python-list



-- 
Joel Goldstick
http://joelgoldstick.com

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

#54611 — Functional Programming and python

Combining your two questions -- Recently:
What minimum should a person know before saying "I know Python"

And earlier this
On Sunday, August 4, 2013 10:00:35 PM UTC+5:30, Aseem Bansal wrote:
> If there is an issue in place for improving the lambda forms then that's 
> good. I wanted a link about functional programming because it is mentioned as 
> if it were a household word.

Python is not a functional programming language; however it supports most of FP better than traditional languages like C/Java.
eg with iterators/generators + itertools + functools you can do most of what lazy lists give in haskell

Some discussion here: http://stackoverflow.com/questions/1017621/why-isnt-python-very-good-for-functional-programming

[Not everything said there is correct; eg python supports currying better than haskell which is surprising considering that Haskell's surname is Curry!]

So if I may break your question into two: 
1. Why should a programmer of a non-FP language know FP?
2. What in FP should a (any|all) programmer know?

I touched upon these in two blog-posts:
1. http://blog.languager.org/2013/06/functional-programming-invades.html
2. http://blog.languager.org/2012/10/functional-programming-lost-booty.html

Also most programmers without an FP background have a poor appreciation of the centrality of recursion in CS; see
http://blog.languager.org/2012/05/recursion-pervasive-in-cs.html

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

#54658 — Re: Functional Programming and python

rusi wrote:

> [Not everything said there is correct; eg python supports currying better
> [than haskell which is surprising considering that Haskell's surname is
> [Curry!]

AFAIK python does not support currying at all (if not via some decorators or 
something like that).

Instead every function in haskell implicitly support currying... so... how 
does "no support" is better than "full support"?


-- 
By ZeD

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

#54678 — Re: Functional Programming and python

Vito De Tullio writes:

> rusi wrote:
> 
> > [Not everything said there is correct; eg python supports currying
> > better [than haskell which is surprising considering that
> > Haskell's surname is [Curry!]
> 
> AFAIK python does not support currying at all (if not via some
> decorators or something like that).

I suppose rusi means functools.partial:

  >>> from functools import partial
  >>> trip = lambda x,y,z: (x,y,z)
  >>> partial(trip,'a','b')('c')
  ('a', 'b', 'c')

It also supports keyword arguments.

> Instead every function in haskell implicitly support currying...
> so... how does "no support" is better than "full support"?

Yes. I'm satisfied that Python does, but what can be seen as a
shortcoming in Haskell? Just curious.

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

#54679 — Re: Functional Programming and python

On Monday, September 23, 2013 11:54:53 PM UTC+5:30, Vito De Tullio wrote:
> rusi wrote:
> 
> > [Not everything said there is correct; eg python supports currying better
> > [than haskell which is surprising considering that Haskell's surname is
> > [Curry!]
> 
> 
> AFAIK python does not support currying at all (if not via some decorators or 
> something like that).
> 
> 
> Instead every function in haskell implicitly support currying... so... how 
> does "no support" is better than "full support"?

Without resorting to lambdas/new-functions:
 With functools.partial one can freeze any subset of a function(callable's) 
 parameters.
 
 In Haskell one can only freeze the first parameter or at most with a right section the second

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

#54681 — Re: Functional Programming and python

rusi writes:

> Without resorting to lambdas/new-functions:
>  With functools.partial one can freeze any subset of a
>  function(callable's) parameters.
>
>  In Haskell one can only freeze the first parameter or at most with
>  a right section the second

You have an f of type A -> B -> C -> D -> E in Haskell, you can freeze
the first three parameters by calling it with three arguments. These
are equivalent:

f a b c d
(f a b c) d
(f a b) c d
(f a) b c d

So it's any initial sequence of arguments, not just the first.

And I thought such types were preferred over A * B * C * D -> E in
Haskell, so you tend to get this for free. Not sure of the syntax here
- it's been long since I did anything at all with Haskell.

A difference seems to be that in Python, a call can refer to named
parameters. This gives functools.partial some power over Haskell.

Another difference is that the value of functools.partial is always a
function that needs to be called with the remaining arguments, even if
there are none. Both the creation and the evaluation of the curried
functions just happens in Haskell.

(I also think that the word "currying" used to refer to what Haskell
does and it's an extension to use it to mean any partial evaluation.)

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

#54692 — Re: Functional Programming and python

On Tuesday, September 24, 2013 1:12:51 PM UTC+5:30, Jussi Piitulainen wrote:
> rusi writes:
> 
> > Without resorting to lambdas/new-functions:
> >  With functools.partial one can freeze any subset of a
> >  function(callable's) parameters.
> >
> 
> >  In Haskell one can only freeze the first parameter or at most with
> >  a right section the second
> 
> You have an f of type A -> B -> C -> D -> E in Haskell, you can freeze
> the first three parameters by calling it with three arguments. These
> are equivalent:
> 
> f a b c d
> (f a b c) d
> (f a b) c d
> (f a) b c d
> 
> So it's any initial sequence of arguments, not just the first.

Agreed. I missed that.

However as n increases there are n initial sequences (Haskell) whereas there are 2^n possible subsets (Python) (2^n - 1 if we remove the fully saturated case). So I would argue that Python syntax gives more flexibility in this direction than Haskell.  Add the further feature of **args and its even more

> 
> (I also think that the word "currying" used to refer to what Haskell
> does and it's an extension to use it to mean any partial evaluation.)

Hmm… Seems this is a contentious issue
http://en.wikipedia.org/wiki/Currying#Contrast_with_partial_function_application

which links to this LtU post that I find neat:

---------------
If I have a function f:(x,y)->z, I can't apply it to only one of its arguments. I can curry it, turning it into a function g:x->(y->z) ... and I can apply g to only one of the original arguments. But turning f into g and applying g to some x are technically different things.

I suspect the confusion arises because originally currying was a technique to model multiple-argument functions in a single-argument framework and was a meta-operation. In ML-like languages, the functions are typically already curried, so the only operation you see being done is partial application.
---------------
from http://lambda-the-ultimate.org/node/2266

-------------
Anyways thanks for that Ive added it to my 'lost-booty' list
http://blog.languager.org/2012/10/functional-programming-lost-booty.html#curry

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

#54701 — Re: Functional Programming and python

rusi writes:
> On Tuesday, September 24, 2013 1:12:51 PM UTC+5:30, Jussi Piitulainen wrote:
> > rusi writes:
> > 
> > > Without resorting to lambdas/new-functions:
> > >  With functools.partial one can freeze any subset of a
> > >  function(callable's) parameters.
> > 
> > >  In Haskell one can only freeze the first parameter or at most
> > >  with a right section the second
> > 
> > You have an f of type A -> B -> C -> D -> E in Haskell, you can
> > freeze the first three parameters by calling it with three
> > arguments. These are equivalent:
> > 
> > f a b c d
> > (f a b c) d
> > (f a b) c d
> > (f a) b c d
> > 
> > So it's any initial sequence of arguments, not just the first.
> 
> Agreed. I missed that.

Ok.

> However as n increases there are n initial sequences (Haskell)
> whereas there are 2^n possible subsets (Python) (2^n - 1 if we
> remove the fully saturated case). So I would argue that Python
> syntax gives more flexibility in this direction than Haskell.

Strictly speaking and in principle, yes. I'm not sure how important
this is in practice: the positional parameter list should be short
anyway, Haskell does have the special mechanism for the second, and
there is always the fully general mechanism (lambda) in both languages
(and in another language I use that has neither built-in currying nor
keyword parameters :).

I agree that the ability to identify arguments by name gives a useful
amount of quite practical power, and I see that functools.partial uses
it nicely. So, no real disagreement on this from me.

Would the type system get in the way of providing some analogous
function in Haskell? I don't know.

> Add the further feature of **args and its even more
>
> > (I also think that the word "currying" used to refer to what
> > Haskell does and it's an extension to use it to mean any partial
> > evaluation.)
> 
> Hmm[] Seems this is a contentious issue
> http://en.wikipedia.org/wiki/Currying#Contrast_with_partial_function_application
> 
> which links to this LtU post that I find neat:

[snip]

Thanks. I don't think I have anything useful to add, though.

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

#54705 — Re: Functional Programming and python

On Tuesday, September 24, 2013 8:21:19 PM UTC+5:30, Jussi Piitulainen wrote:
> Would the type system get in the way of providing some analogous
> function in Haskell? I don't know.

Yes.
The haskell curry
curry f x y = f (x,y)
is really only curry2
curry3 would be
curry3 f x y z = f (x,y,z)
and so on upwards

Vanilla Haskell makes it real hard to put all these under one type umbrella

By comparison python's partial is quite effortless.

And this is an old conundrum in programming language design:

In C printf is easy to write and NOT put into the language but into external libraries
In Pascal, writeln cannot be outside the language because as a user defined function, its type would not fit the type system.

And so printf can be made to crash quite easily; not so writeln!

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

#54706 — Re: Functional Programming and python

On Wed, Sep 25, 2013 at 1:07 AM, rusi <rustompmody@gmail.com> wrote:
> And this is an old conundrum in programming language design:
>
> In C printf is easy to write and NOT put into the language but into external libraries
> In Pascal, writeln cannot be outside the language because as a user defined function, its type would not fit the type system.
>
> And so printf can be made to crash quite easily; not so writeln!

I assume you're talking about mismatching percent-markers and
arguments, there. That's because of a limitation in C's variadic
function support, ameliorated somewhat by gcc's warnings system, and
completely solved by other languages in which (s)printf can still be
an external function, but with reliable type checking. It's not
whether it's part of the language or not that does that.

ChrisA

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

#54712 — Re: Functional Programming and python

On Tuesday, September 24, 2013 8:56:21 PM UTC+5:30, Chris Angelico wrote:
> On Wed, Sep 25, 2013 at 1:07 AM, rusi  wrote:
> > And this is an old conundrum in programming language design:
> >
> > In C printf is easy to write and NOT put into the language but into external libraries
> 
> > In Pascal, writeln cannot be outside the language because as a user defined function, its type would not fit the type system.
> >
> > And so printf can be made to crash quite easily; not so writeln!
> 
> I assume you're talking about mismatching percent-markers and
> arguments, there. That's because of a limitation in C's variadic
> function support, ameliorated somewhat by gcc's warnings system, and
> completely solved by other languages in which (s)printf can still be
> an external function, but with reliable type checking. It's not
> whether it's part of the language or not that does that.

Sure there can be and are specific workarounds.

My point was a general one:
Strong type system: Some desirable programs will get kicked out
Weak type system: Some undesirable programs will slip in
'Exactly' correct type system: Impossible by halting problem 

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

#55089 — Re: Functional Programming and python

In article <ba94102b-18b6-4850-ac85-032b0fe2fa75@googlegroups.com>,
 rusi <rustompmody@gmail.com> wrote:

> Combining your two questions -- Recently:
> What minimum should a person know before saying "I know Python"
> 
> And earlier this
> On Sunday, August 4, 2013 10:00:35 PM UTC+5:30, Aseem Bansal wrote:
> > If there is an issue in place for improving the lambda forms then that's 
> > good. I wanted a link about functional programming because it is mentioned as 
> > if it were a household word.
> 
> Python is not a functional programming language; however it supports most of FP better than traditional languages like C/Java.
> eg with iterators/generators + itertools + functools you can do most of what lazy lists give in haskell
> 
> Some discussion here: http://stackoverflow.com/questions/1017621/why-isnt-python-very-good-for-functional-programming
> 
> [Not everything said there is correct; eg python supports currying better than haskell which is surprising considering that Haskell's surname is Curry!]
> 
> So if I may break your question into two: 
> 1. Why should a programmer of a non-FP language know FP?
> 2. What in FP should a (any|all) programmer know?
> 
> I touched upon these in two blog-posts:
> 1. http://blog.languager.org/2013/06/functional-programming-invades.html
> 2. http://blog.languager.org/2012/10/functional-programming-lost-booty.html
> 
> Also most programmers without an FP background have a poor appreciation of the centrality of recursion in CS; see
> http://blog.languager.org/2012/05/recursion-pervasive-in-cs.html

Good approach of FP in Python, but two points make me crazy :
1. Tail recursion is not optimized. We are in 2013, why ? This is known technology (since 1960).
And don't answer with "good programmers don't use recursion", this is bullshit.
2. Lambda-expression body is limited to one expression. Why ?
Why the hell those limitations ? In this aspect, Javascript has a cooler approach.

   franck

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

#55091 — Re: Functional Programming and python

On Tue, Oct 1, 2013 at 3:04 AM, Franck Ditter <nobody@nowhere.org> wrote:
> 1. Tail recursion is not optimized. We are in 2013, why ? This is known technology (since 1960).
> And don't answer with "good programmers don't use recursion", this is bullshit.

I've yet to see any value in having the compiler/interpreter optimize
tail recursion that can't be achieved just as well, and usually more
clearly, with simple iteration. Recursion's important; tail
recursion's important; tail recursion optimization isn't. (But I do
sometimes yearn for a goto.)

> 2. Lambda-expression body is limited to one expression. Why ?
> Why the hell those limitations ? In this aspect, Javascript has a cooler approach.

Since you can just use def in the middle of another function, the
difference between def and lambda isn't all that huge. Yes, def isn't
an expression - but Python's lambda gives an incredibly compact
notation for the common case. Compare these two snippets:

# Python
odd_numbers = filter(lambda x: x%2, numbers)

//Pike
odd_numbers = filter(numbers, lambda(int x) {return x%2;})

Aside from the type declaration and the argument order, these two
snippets are doing exactly the same thing in exactly the same way.
Python's version is way more compact. Pike's version lets you put
multiple statements into the expression... but most of the time you
don't need that. Both approaches have their value.

ChrisA

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

#55098 — Re: Functional Programming and python

On 2013-09-30, Franck Ditter <nobody@nowhere.org> wrote:
> In article <ba94102b-18b6-4850-ac85-032b0fe2fa75@googlegroups.com>,
>  rusi <rustompmody@gmail.com> wrote:
>> I touched upon these in two blog-posts:
>> 1. http://blog.languager.org/2013/06/functional-programming-invades.html
>> 2. http://blog.languager.org/2012/10/functional-programming-lost-booty.html
>> 
>> Also most programmers without an FP background have a poor
>> appreciation of the centrality of recursion in CS; see
>> http://blog.languager.org/2012/05/recursion-pervasive-in-cs.html
>
> Good approach of FP in Python, but two points make me crazy :
> 1. Tail recursion is not optimized. We are in 2013, why ? This
> is known technology (since 1960). And don't answer with "good
> programmers don't use recursion", this is bullshit.

If you've got a set of recursive functions with recursive calls
in tail-call position it's pretty easy to convert to a solution
that doesn't blow the stack. Converting to a while loop is
usually straightforward, or you try trampolining.

If the calls aren't in tail-call position then you wouldn't get
tail-call optimization from a language like scheme, either.

Getting calls in tail position is often the sticking point, and
tail-call optimization doesn't help with that.

I think the Python rationale also discusses how it would make
tracebacks harder to understand if stackframes could clobber each
other. Personally I think that's more a theoretical than a
practical problem. Languages with tail-call optimization aren't
impossible to debug.

> 2. Lambda-expression body is limited to one expression. Why ?
> Why the hell those limitations ? In this aspect, Javascript has
> a cooler approach.

It's in the Design and History FAQ.

http://docs.python.org/3/faq/design.html

    Why can’t lambda forms contain statements?

    Python lambda forms cannot contain statements because
    Python’s syntactic framework can’t handle statements nested
    inside expressions. However, in Python, this is not a serious
    problem. Unlike lambda forms in other languages, where they
    add functionality, Python lambdas are only a shorthand
    notation if you’re too lazy to define a function.

    Functions are already first class objects in Python, and can
    be declared in a local scope. Therefore the only advantage of
    using a lambda form instead of a locally-defined function is
    that you don’t need to invent a name for the function – but
    that’s just a local variable to which the function object
    (which is exactly the same type of object that a lambda form
    yields) is assigned!

What I usually end up with is a dictionary of callbacks, with the
simple functions defined in-line and the more complex functions
defined just before that and referenced instead.

-- 
Neil Cerutti

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web