lambda

Discussion in 'Python' started by Egor Bolonev, Jan 13, 2005.

  1. Egor Bolonev

    Egor Bolonev Guest

    why functions created with lambda forms cannot contain statements?

    how to get unnamed function with statements?
     
    Egor Bolonev, Jan 13, 2005
    #1
    1. Advertising

  2. Egor Bolonev wrote:
    > why functions created with lambda forms cannot contain statements?


    syntax/technical answer: because lambda is an expression and it is not
    obvious how the syntax for 'statement inside expression' should be

    'Python is perfect' answer: if a function contains more than an
    expression, then it's complex enough to require a name

    > how to get unnamed function with statements?


    You can't. See various threads about Smalltalk/Ruby-like blocks and the
    recent one about the 'where' keyword for proposals to change this

    Daniel
     
    Daniel Dittmar, Jan 13, 2005
    #2
    1. Advertising

  3. Egor Bolonev

    Tim Leslie Guest

    Because if it takes more than a single line it deserves a name. Also,
    if you have more than one line in this function, how do you plan to
    reference it if not by name?

    Tim


    On Thu, 13 Jan 2005 20:53:09 +1000, Egor Bolonev <> wrote:
    > why functions created with lambda forms cannot contain statements?
    >
    > how to get unnamed function with statements?
    > --
    > http://mail.python.org/mailman/listinfo/python-list
    >
     
    Tim Leslie, Jan 13, 2005
    #3
  4. Op 2005-01-13, Tim Leslie schreef <>:
    > Because if it takes more than a single line it deserves a name.


    So if I have a call with an expression that takes more than
    one line, I should assign the expression to a variable and
    use the variable in the call?

    But wait if I do that, people will tell me how bad that it
    is, because it will keep a reference to the value which
    will prevent the garbage collector from harvesting this
    memory.

    Besides python allows more than one statement on the same line.

    --
    Antoon Pardon
     
    Antoon Pardon, Jan 13, 2005
    #4
  5. Egor Bolonev

    hanz Guest

    Antoon Pardon wrote:
    > So if I have a call with an expression that takes more than
    > one line, I should assign the expression to a variable and
    > use the variable in the call?


    Yes, that's sometimes a good practice and can clarify
    the call.

    > But wait if I do that, people will tell me how bad that it
    > is, because it will keep a reference to the value which
    > will prevent the garbage collector from harvesting this
    > memory.


    Nobody will tell you that it's bad. Python was never
    about super performance, but about readability.
    Besides, using such temporaries won't consume much
    memory (relatively).

    > Besides python allows more than one statement on the same line.

    But it's discouraged in general.
     
    hanz, Jan 13, 2005
    #5
  6. Egor Bolonev

    Paul Rubin Guest

    "hanz" <> writes:
    > > But wait if I do that, people will tell me how bad that it is,
    > > because it will keep a reference to the value which will prevent
    > > the garbage collector from harvesting this memory.

    >
    > Nobody will tell you that it's bad. Python was never about super
    > performance, but about readability. Besides, using such temporaries
    > won't consume much memory (relatively).


    That completely depends on the objects in question. Compare

    temp = all_posters[:]
    temp.sort()
    top_five_posters = temp[-5:]

    to:

    top_five_posters = all_posters.sorted()[-5:]

    which became possible only when .sorted() was added to Python 2.4.

    This is another reason it would be nice to be able to create very
    temporary scopes.
     
    Paul Rubin, Jan 13, 2005
    #6
  7. sorted (WAS: lambda)

    Paul Rubin wrote:
    >
    > That completely depends on the objects in question. Compare
    >
    > temp = all_posters[:]
    > temp.sort()
    > top_five_posters = temp[-5:]
    >
    > to:
    >
    > top_five_posters = all_posters.sorted()[-5:]
    >
    > which became possible only when .sorted() was added to Python 2.4.


    I believe you mean "when sorted() was added to Python 2.4":

    py> ['d', 'b', 'c', 'a'].sorted()
    Traceback (most recent call last):
    File "<interactive input>", line 1, in ?
    AttributeError: 'list' object has no attribute 'sorted'
    py> sorted(['d', 'b', 'c', 'a'])
    ['a', 'b', 'c', 'd']

    Note that sorted is a builtin function, not a method of a list object.
    It takes any iterable and creates a sorted list from it. Basically the
    equivalent of:

    def sorted(iterable):
    result = list(iterable)
    result.sort()
    return result

    Steve
     
    Steven Bethard, Jan 13, 2005
    #7
  8. Egor Bolonev

    Paul Rubin Guest

    Re: sorted (WAS: lambda)

    Steven Bethard <> writes:
    > Note that sorted is a builtin function, not a method of a list
    > object.


    Oh, same difference. I thought it was a method because I'm not using
    2.4 yet. The result is the same, other than that having it as a
    function instead of a method is another inconsistency to remember.
     
    Paul Rubin, Jan 13, 2005
    #8
  9. Re: sorted (WAS: lambda)

    Paul Rubin wrote:

    >> Note that sorted is a builtin function, not a method of a list
    >> object.

    >
    > Oh, same difference. I thought it was a method because I'm not using
    > 2.4 yet. The result is the same


    nope. sorted works on any kind of sequence, including forward-only
    iterators. sorted(open(filename)) works just fine, for example.

    > other than that having it as a function instead of a method is another
    > inconsistency to remember


    I suspect that you don't really understand how sequences and iterators
    work in Python...

    </F>
     
    Fredrik Lundh, Jan 13, 2005
    #9
  10. Egor Bolonev

    Paul Rubin Guest

    Re: sorted (WAS: lambda)

    "Fredrik Lundh" <> writes:
    > > Oh, same difference. I thought it was a method because I'm not using
    > > 2.4 yet. The result is the same

    >
    > nope. sorted works on any kind of sequence, including forward-only
    > iterators. sorted(open(filename)) works just fine, for example.


    Oh cool. However I meant the result is the same in my example, where
    assigning the temporary result to a variable stopped memory from
    getting reclaimed until after the function exits.
     
    Paul Rubin, Jan 13, 2005
    #10
  11. Egor Bolonev

    Terry Reedy Guest

    "Egor Bolonev" <> wrote in message
    news:eek:...
    > why functions created with lambda forms cannot contain statements?


    Because lambda was only ever intended to be an inline abbreviation of
    simple one-use functions whose body consists of 'return <expression>'. It
    is clear to me that the word 'lambda' was a mistake since it engenders
    expectations of more than that from too many people, such as you.

    Terry J. Reedy
     
    Terry Reedy, Jan 13, 2005
    #11
  12. Egor Bolonev

    Terry Reedy Guest

    Re: sorted (WAS: lambda)

    "Paul Rubin" <"http://phr.cx"@NOSPAM.invalid> wrote in message
    news:...
    > Steven Bethard <> writes:
    >> Note that sorted is a builtin function, not a method of a list
    >> object.

    >
    > Oh, same difference. I thought it was a method because I'm not using
    > 2.4 yet. The result is the same, other than that having it as a
    > function instead of a method is another inconsistency to remember.


    No, not same difference. A list method would only operate on lists, as is
    true of all list methods. Being a function lets it work for any iterable,
    as is true of any function of iterable. Big difference. And consistent.
    One could argue though that it should have been put into itermethods module
    instead of builtins.

    Terry J. Reedy
     
    Terry Reedy, Jan 13, 2005
    #12
  13. Op 2005-01-13, hanz schreef <>:
    >
    > Antoon Pardon wrote:
    >> So if I have a call with an expression that takes more than
    >> one line, I should assign the expression to a variable and
    >> use the variable in the call?

    >
    > Yes, that's sometimes a good practice and can clarify
    > the call.
    >
    >> But wait if I do that, people will tell me how bad that it
    >> is, because it will keep a reference to the value which
    >> will prevent the garbage collector from harvesting this
    >> memory.

    >
    > Nobody will tell you that it's bad.


    Sorry, someone already did. If I recall correctly it
    was Alex Martelli.

    --
    Antoon Pardon
     
    Antoon Pardon, Jan 14, 2005
    #13
  14. Egor Bolonev

    Steve Holden Guest

    Antoon Pardon wrote:

    > Op 2005-01-13, hanz schreef <>:
    >
    >>Antoon Pardon wrote:
    >>
    >>>So if I have a call with an expression that takes more than
    >>>one line, I should assign the expression to a variable and
    >>>use the variable in the call?

    >>
    >>Yes, that's sometimes a good practice and can clarify
    >>the call.
    >>
    >>
    >>>But wait if I do that, people will tell me how bad that it
    >>>is, because it will keep a reference to the value which
    >>>will prevent the garbage collector from harvesting this
    >>>memory.

    >>

    Of course, unless that reference is in the global scope of the __main__
    module its lifetime will be transient anyway. If the reference is stored
    in a function's local variable then unless its value is returned from
    the function it will become available for garbage collection when the
    function returns.

    >>Nobody will tell you that it's bad.

    >
    >
    > Sorry, someone already did. If I recall correctly it
    > was Alex Martelli.
    >

    "A foolish consistency is the hobgoblin of little minds". Rules are made
    to be broken. Besides which, if you don't understand the language
    environment, rules alone will do you very little good. Try to focus a
    little more on principles and a little less on minutiae.

    regards
    Steve
    --
    Steve Holden http://www.holdenweb.com/
    Python Web Programming http://pydish.holdenweb.com/
    Holden Web LLC +1 703 861 4237 +1 800 494 3119
     
    Steve Holden, Jan 14, 2005
    #14
  15. Op 2005-01-14, Steve Holden schreef <>:
    > Antoon Pardon wrote:
    >
    >> Op 2005-01-13, hanz schreef <>:
    >>
    >>>Antoon Pardon wrote:
    >>>
    >>>>So if I have a call with an expression that takes more than
    >>>>one line, I should assign the expression to a variable and
    >>>>use the variable in the call?
    >>>
    >>>Yes, that's sometimes a good practice and can clarify
    >>>the call.
    >>>
    >>>
    >>>>But wait if I do that, people will tell me how bad that it
    >>>>is, because it will keep a reference to the value which
    >>>>will prevent the garbage collector from harvesting this
    >>>>memory.
    >>>

    > Of course, unless that reference is in the global scope of the __main__
    > module its lifetime will be transient anyway. If the reference is stored
    > in a function's local variable then unless its value is returned from
    > the function it will become available for garbage collection when the
    > function returns.
    >
    >>>Nobody will tell you that it's bad.

    >>
    >>
    >> Sorry, someone already did. If I recall correctly it
    >> was Alex Martelli.
    >>

    > "A foolish consistency is the hobgoblin of little minds". Rules are made
    > to be broken.


    Like only use immutables as dictionary keys.

    > Besides which, if you don't understand the language
    > environment, rules alone will do you very little good. Try to focus a
    > little more on principles and a little less on minutiae.


    And what are the difference between those two?

    Sometimes I get the impression that everything is a principle until
    one personnaly finds the need to break it. After that it is a rule.

    --
    Antoon Pardon
     
    Antoon Pardon, Jan 17, 2005
    #15
  16. Egor Bolonev

    Steve Holden Guest

    Antoon Pardon wrote:
    [...]
    >>"A foolish consistency is the hobgoblin of little minds". Rules are made
    >>to be broken.

    >
    >
    > Like only use immutables as dictionary keys.
    >

    Fair enough, but don;t go advising newbies to do this.
    >
    >>Besides which, if you don't understand the language
    >>environment, rules alone will do you very little good. Try to focus a
    >>little more on principles and a little less on minutiae.

    >
    >
    > And what are the difference between those two?
    >
    > Sometimes I get the impression that everything is a principle until
    > one personnaly finds the need to break it. After that it is a rule.
    >

    Principle: "Ten angels can dance on the head of a pin".

    Minutiae: "Well, if they'd all recently been on a diet and they hold on
    to each other very carefully you can get 10.3. I got eleven once by
    adding a hash function".

    regards
    Steve
    --
    Steve Holden http://www.holdenweb.com/
    Python Web Programming http://pydish.holdenweb.com/
    Holden Web LLC +1 703 861 4237 +1 800 494 3119
     
    Steve Holden, Jan 17, 2005
    #16
  17. Op 2005-01-17, Steve Holden schreef <>:
    > Antoon Pardon wrote:
    > [...]
    >>>"A foolish consistency is the hobgoblin of little minds". Rules are made
    >>>to be broken.

    >>
    >>
    >> Like only use immutables as dictionary keys.
    >>

    > Fair enough, but don;t go advising newbies to do this.


    How about something like this.

    Because of the extra precautions one has to take when
    using mutables as hash keys, we advise newbies
    to stick with immutable keys until they have gathered
    enough knowledge and experience to adequatly weight
    the pro and cons of a mutable key solution against
    an immutable key solution.

    --
    Antoon Pardon
     
    Antoon Pardon, Jan 17, 2005
    #17
  18. Egor Bolonev

    Steve Holden Guest

    Antoon Pardon wrote:

    > Op 2005-01-17, Steve Holden schreef <>:
    >
    >>Antoon Pardon wrote:
    >>[...]
    >>
    >>>>"A foolish consistency is the hobgoblin of little minds". Rules are made
    >>>>to be broken.
    >>>
    >>>
    >>>Like only use immutables as dictionary keys.
    >>>

    >>
    >>Fair enough, but don;t go advising newbies to do this.

    >
    >
    > How about something like this.
    >
    > Because of the extra precautions one has to take when
    > using mutables as hash keys, we advise newbies
    > to stick with immutable keys until they have gathered
    > enough knowledge and experience to adequatly weight
    > the pro and cons of a mutable key solution against
    > an immutable key solution.
    >

    There you go with the minutiae again. How about:

    "Don't use mutables as hash keys"?

    regards
    Steve
    --
    Steve Holden http://www.holdenweb.com/
    Python Web Programming http://pydish.holdenweb.com/
    Holden Web LLC +1 703 861 4237 +1 800 494 3119
     
    Steve Holden, Jan 17, 2005
    #18
  19. Op 2005-01-17, Steve Holden schreef <>:
    > Antoon Pardon wrote:
    >
    >> Op 2005-01-17, Steve Holden schreef <>:
    >>
    >>>Antoon Pardon wrote:
    >>>[...]
    >>>
    >>>>>"A foolish consistency is the hobgoblin of little minds". Rules are made
    >>>>>to be broken.
    >>>>
    >>>>
    >>>>Like only use immutables as dictionary keys.
    >>>>
    >>>
    >>>Fair enough, but don;t go advising newbies to do this.

    >>
    >>
    >> How about something like this.
    >>
    >> Because of the extra precautions one has to take when
    >> using mutables as hash keys, we advise newbies
    >> to stick with immutable keys until they have gathered
    >> enough knowledge and experience to adequatly weight
    >> the pro and cons of a mutable key solution against
    >> an immutable key solution.
    >>

    > There you go with the minutiae again. How about:
    >
    > "Don't use mutables as hash keys"?


    That sounds too dogmatic to my ears. I also find it
    too selective. The problem with mutables as dictionary
    keys is not specific to dictionaries. Everywhere you
    have mutables in a container, it is possible that
    mutating the object in the container will cause
    problem. Heck even using mutables as arguments can
    cause trouble. Why else the specific advice against

    def foo(p = [])

    type of arguments. So should we adopt the principles:

    Don't use mutables in containers

    Don't use mutables as default values for parameters

    Don't use mutables as arguments.

    Don't assign one mutable to an other.


    I don't see a big difference between these principles
    and the hash key principle, so in the end may be we
    should just stick with the more general principle:

    Don't use mutables!


    and be done with it.

    --
    Antoon Pardon
     
    Antoon Pardon, Jan 17, 2005
    #19
  20. Egor Bolonev

    Just Guest

    In article <>,
    Antoon Pardon <> wrote:

    > Op 2005-01-17, Steve Holden schreef <>:


    > > There you go with the minutiae again. How about:
    > >
    > > "Don't use mutables as hash keys"?

    >
    > That sounds too dogmatic to my ears. I also find it
    > too selective. The problem with mutables as dictionary
    > keys is not specific to dictionaries. Everywhere you
    > have mutables in a container, it is possible that
    > mutating the object in the container will cause
    > problem.


    The main difference is: if you mutate a dict key you *always* have a
    problem. So don't do that. Mutating (say) a list item *only* is a
    problem if you (say) need that list to remain sorted. Lists don't
    magically remain sorted, so people generally sort it before they do some
    operation that expects a sorted list.

    > Heck even using mutables as arguments can
    > cause trouble. Why else the specific advice against
    >
    > def foo(p = [])
    >
    > type of arguments. So should we adopt the principles:
    >
    > Don't use mutables in containers


    Nonsense.

    > Don't use mutables as default values for parameters


    That's good advice in general.

    > Don't use mutables as arguments.


    Nonsense.

    > Don't assign one mutable to an other.


    Nonsense. Some newbies get surprised by Python's assignment-doesn't-copy
    semantics, but it's such basic knowledge (as well as a useful feature)
    that I simply don't understand you saying this.

    > I don't see a big difference between these principles
    > and the hash key principle,


    Than you haven't looked hard enough.

    > so in the end may be we
    > should just stick with the more general principle:
    >
    > Don't use mutables!
    >
    >
    > and be done with it.


    Ok, so you're indeed a troll.

    Just
     
    Just, Jan 17, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Xah Lee

    A Lambda Logo Tour

    Xah Lee, Apr 5, 2006, in forum: Java
    Replies:
    5
    Views:
    521
    Alex Hunsley
    Apr 7, 2006
  2. Xah Lee
    Replies:
    177
    Views:
    3,061
    Kay Schluehr
    May 23, 2006
  3. Roman Suzi
    Replies:
    13
    Views:
    608
    Bengt Richter
    Jan 7, 2005
  4. Steve Dogers

    lambda vs non-lambda proc

    Steve Dogers, Mar 30, 2009, in forum: Ruby
    Replies:
    1
    Views:
    178
    Sean O'Halpin
    Mar 30, 2009
  5. Haochen Xie
    Replies:
    4
    Views:
    245
    Haochen Xie
    Mar 17, 2013
Loading...

Share This Page