lambda

[Egor Bolonev]

why functions created with lambda forms cannot contain statements?

how to get unnamed function with statements?

 

[Daniel Dittmar]

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

 

[Tim Leslie]

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

 

[Antoon Pardon]

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.

 

[hanz]

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.

 

[Paul Rubin]

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.

 

[Steven Bethard]

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

 

[Paul Rubin]

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.

 

[Fredrik Lundh]

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>

 

[Paul Rubin]

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.

 

[Terry Reedy]

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]

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

 

[Antoon Pardon]

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


Nobody will tell you that it's bad.

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

 

[Steve Holden]

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.

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

 

[Antoon Pardon]

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.

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

 

[Steve Holden]

Antoon Pardon wrote:
[...]

Like only use immutables as dictionary keys.

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

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

 

[Antoon Pardon]

Antoon Pardon wrote:
[...]

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.

 

[Steve Holden]

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

 

[Antoon Pardon]

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.

 

[Just]

Op 2005-01-17, Steve Holden schreef <[email protected]>:

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