rusi writes:
> On Jun 5, 5:03 pm, Jussi Piitulainen wrote:
> > rusi writes:
> > > On Jun 3, 11:17 am, Jussi Piitulainen wrote:
> > > > rusi writes:
> > > > > So I tried:
> > > > > Recast the comprehension as a map
> > > > > Rewrite the map into a fmap (functionalmap) to create new bindings
> >
> >
On Jun 5, 5:03 pm, Jussi Piitulainen
wrote:
> rusi writes:
> > On Jun 3, 11:17 am, Jussi Piitulainen wrote:
> > > rusi writes:
> > > > So I tried:
> > > > Recast the comprehension as a map
> > > > Rewrite the map into a fmap (functionalmap) to create new bindings
>
> > > > def fmap(f,lst):
> > > >
rusi writes:
> On Jun 3, 11:17 am, Jussi Piitulainen wrote:
> > rusi writes:
> > > So I tried:
> > > Recast the comprehension as a map
> > > Rewrite the map into a fmap (functionalmap) to create new bindings
> >
> > > def fmap(f,lst):
> > > if not lst: return []
> > > return [f(lst[0])] + f
On Jun 3, 11:17 am, Jussi Piitulainen
wrote:
> rusi writes:
> > So I tried:
> > Recast the comprehension as a map
> > Rewrite the map into a fmap (functionalmap) to create new bindings
>
> > def fmap(f,lst):
> > if not lst: return []
> > return [f(lst[0])] + fmap(f, lst[1:])
>
> > Still th
Alain Ketterlin wrote:
You must be kidding. Like many others, you seem to think that Scheme is
a typical functional language, which it is not.
I never said that Scheme is a functional language -- I'd be
the first to acknowledge that it's not. I do know what real
functional languages are like.
Alain Ketterlin wrote:
The reason why we have the kind of lambdas we have in python (and
scheme, and javascript, etc.) is just that it is way easier to
implement. That's all I've said. And people have gotten used to it,
without ever realizing they are using something completely different
from wha
On Fri, Jun 3, 2011 at 2:30 AM, Thomas Rachel
wrote:
> So there should be a way to replace the closure of a function with a
> snapshot of it at a certain time. If there was an internal function with
> access to the readonly attribute func_closure and with the capability of
> changing or creating a
On Fri, 03 Jun 2011 11:43:54 +1200, Gregory Ewing wrote:
>> But going against generally accepted semantics should at least
>> be clearly indicated. Lambda is one of the oldest computing abstraction,
>> and they are at the core of any functional programming language.
>
> Yes, and Python's lambdas
Alain Ketterlin writes:
> Gregory Ewing writes:
>
> > Alain Ketterlin wrote:
> >> But going against generally accepted semantics should at least be
> >> clearly indicated. Lambda is one of the oldest computing
> >> abstraction, and they are at the core of any functional
> >> programming language.
Gregory Ewing writes:
> Alain Ketterlin wrote:
>> But going against generally accepted semantics should at least
>> be clearly indicated. Lambda is one of the oldest computing abstraction,
>> and they are at the core of any functional programming language.
>
> Yes, and Python's lambdas behave exa
Am 03.06.2011 01:43 schrieb Gregory Ewing:
It's not the lambda that's different from other languages,
it's the for-loop. In languages that encourage a functional
style of programming, the moral equivalent of a for-loop is
usually some construct that results in a new binding of the
control variab
rusi writes:
> So I tried:
> Recast the comprehension as a map
> Rewrite the map into a fmap (functionalmap) to create new bindings
>
> def fmap(f,lst):
> if not lst: return []
> return [f(lst[0])] + fmap(f, lst[1:])
>
> Still the same effects.
>
> Obviously I am changing it at the wron
On Jun 3, 4:43 am, Gregory Ewing wrote:
> Alain Ketterlin wrote:
> > But going against generally accepted semantics should at least
> > be clearly indicated. Lambda is one of the oldest computing abstraction,
> > and they are at the core of any functional programming language.
>
> Yes, and Python'
Alain Ketterlin wrote:
But going against generally accepted semantics should at least
be clearly indicated. Lambda is one of the oldest computing abstraction,
and they are at the core of any functional programming language.
Yes, and Python's lambdas behave exactly the *same* way as
every other
On 6/2/2011 7:00 AM, Alain Ketterlin wrote:
Nowhere. But going against generally accepted semantics should at least
be clearly indicated. Lambda is one of the oldest computing abstraction,
and they are at the core of any functional programming language. Adding
a quick hack to python and call it
On Thu, Jun 2, 2011 at 11:22 AM, Steven D'Aprano
wrote:
> It seems to me that early binding is less flexible than late, because
> with late binding you have a chance to simulate early binding by saving a
> reference of the variable elsewhere, such as in a default value, or an
> instance attribute.
On Thu, 02 Jun 2011 10:55:49 -0500, harrismh777 wrote:
> Steven D'Aprano wrote:
>> What do you expect this code to do?
>>
>> a = 42
>> funcs = [(lambda x: x+a) for i in range(10)] funcs[0](1)
>
> I do see your point with this... truly... but it did get me to think
> about what I *do* expect..
Terry Reedy wrote:
Oh the irony of this proposal. You scolded us for breaking code with 2
to 3 changes, and here you propose a change more radical than anything
done in Python 3, and certain to break code, introduce bugs, complicate
the language, and reduce its functionality. Most of Guido's desi
Steven D'Aprano wrote:
What do you expect this code to do?
a = 42
funcs = [(lambda x: x+a) for i in range(10)]
funcs[0](1)
I do see your point with this... truly... but it did get me to think
about what I *do* expect... and that is that 'a' (for the lambda) will
be whatever 'a' is (now) a
Steven D'Aprano wrote:
funcs = [(lambda x, i=j: x+i) for j in range(10)]
Now the reader is no longer distracted by the "i=i" ugliness.
That's a good idea, in fact, change made!
The problem with Do What I Mean is that it so rarely Does What You Mean.
At best it Does What Some Other Guy Ima
Alain Ketterlin writes:
> Steven D'Aprano writes:
> > I agree it's not intuitive. But where does it say that programming
> > language semantics must always be intuitive?
>
> Nowhere. But going against generally accepted semantics should at
> least be clearly indicated. Lambda is one of the oldest
Steven D'Aprano writes:
>> The part that I don't see much about in the docs (some books, that is)
>> is that the lambda lookups occur late (the lambda is evaluated at the
>> time it is called). The Python docs on-line *do say* this (I found too
>> late) but its one quick phrase that can be missed
On Thu, Jun 2, 2011 at 3:14 PM, Steven D'Aprano
wrote:
> The problem with Do What I Mean is that it so rarely Does What You Mean.
> At best it Does What Some Other Guy Imagined I'd Probably Mean In This
> Situation. Let's not go there.
+1
One of my biggest "threats" to my coworkers goes along th
On 6/1/2011 8:40 PM, harrismh777 wrote:
The part that I don't see much about in the docs (some books, that is)
is that the lambda lookups occur late (the lambda is evaluated at the
time it is called). The Python docs on-line *do say* this (I found too
late) but its one quick phrase that can be m
On Wed, 01 Jun 2011 19:40:30 -0500, harrismh777 wrote:
> The part that I don't see much about in the docs (some books, that is)
> is that the lambda lookups occur late (the lambda is evaluated at the
> time it is called). The Python docs on-line *do say* this (I found too
> late) but its one quick
On Wed, 01 Jun 2011 19:50:14 -0500, harrismh777 wrote:
> harrismh777 wrote:
>> Allow me to clarify... I'm not speaking about whether the lambda is
>> short-hand for def, ... that part of the docs I understand well!... no
>> problems there.
>
> Allow me to clarify a little further... the docs ar
harrismh777 wrote:
Allow me to clarify... I'm not speaking about whether the lambda is
short-hand for def, ... that part of the docs I understand well!... no
problems there.
Allow me to clarify a little further... the docs are misleading in
that they state that the lambda can be coded (as an
Terry Reedy wrote:
function (I know, not so) is built-in. There is little to nothing
indicating in the docs that this is not so
On the contrary, the docs very explicitly say that a lambda expression
is equivalent to a def statement.
Allow me to clarify... I'm not speaking about whether the la
On 5/31/2011 8:09 PM, harrismh777 wrote:
At the moment I'm only speaking about my OP and that particular list
comprehension... the thing that happened (at least for me) is that the
intuitive sense that each 'i' somehow becomes a part of the anonymous
function (I know, not so) is built-in. There
On Tue, 31 May 2011 15:47:33 -0600
Ian Kelly wrote:
> The i variable is part of the global scope, and as you iterate over
> range(10) again it coincidentally takes on the same values as in the
> original list comprehension. You don't see this in Python 3 because
> the scope of i is limited to th
Terry Reedy wrote:
This is early-binding versus late-binding. Python is a late-binding
language.
ok ...
Are you asking about changing all function compilation or only when
functions are defined with lambda expressions?
At least lambda expressions, but (see below) any other built-in
On 5/31/2011 4:18 PM, harrismh777 wrote:
Terry Reedy wrote:
You have been hypnotizeed by lambda. (lambda n: i+n) is a *constant
expression*, so you get 10 'equal' functions.
'hypnotized' indeed!
I say 'hypnotized' ;-) because people have posted examples almost
exactly like the one you did,
On Wed, Jun 1, 2011 at 8:39 AM, Chris Angelico wrote:
> - Issue #1713: Fix os.path.ismount(), which returned true for symbolic links
> across devices.
PS. I know nothing about this particular issue, I just skimmed down
the release notes and stopped when something caught my eye. Choose
another ex
On Wed, Jun 1, 2011 at 7:53 AM, harrismh777 wrote:
> Having compared the two, someone please tell me whether the two are
> incompatible, mostly compatible, completely incompatible, or different
> languages...
>
By implication, every version of Python is incompatible with every
other. The 2.7.
On Tue, May 31, 2011 at 2:18 PM, harrismh777 wrote:
> If I'm understanding that correctly, then that means lambda is working as
> designed, and that there are very subtle nuances to be aware of. In my
> little case
>
> (lambda n: i + n)
>
> ... if the i goes out of scope before the anonymous
harrismh777 wrote:
PS Ian calls the second construct "working by mistake..."
oops, actually he called it, "working by accident... "
--
http://mail.python.org/mailman/listinfo/python-list
Martin Manns wrote:
After being confused I figured out it is a 3.x example:
Actually, it is a compatibility example between 2.x and 3.x, compare
below for different behavior from two seemingly identical compatible
constructs, one from 3.2, and the other from 2.6.4:
Python 3.2 (r32:88445,
On Tue, May 31, 2011 at 3:14 PM, Martin Manns wrote:
> $ python
> Python 2.6.6 (r266:84292, Apr 20 2011, 11:58:30)
> [GCC 4.5.2] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
fs=[]
fs = [(lambda n: i + n) for i in range(10)]
[fs[i](1) for i in ra
On Tue, 31 May 2011 01:48:05 -0500
harrismh777 wrote:
> >>> fs=[]
> >>> fs = [(lambda n: i + n) for i in range(10)]
> >>> [fs[i](1) for i in range(10)]
> [10, 10, 10, 10, 10, 10, 10, 10, 10, 10] <=== not good
>
> ( that was a big surprise! . . . )
> ( let's try it another way .
Terry Reedy wrote:
You have been hypnotizeed by lambda. (lambda n: i+n) is a *constant
expression*, so you get 10 'equal' functions.
'hypnotized' indeed! ... ok, so let me see if I get this... the lambda
defers lookup|bind of its references until such time as the lambda is
'called' and not
On 5/31/2011 2:48 AM, harrismh777 wrote:
fs=[]
Irrelevant here since you immediately rebind 'fs'.
fs = [(lambda n: i + n) for i in range(10)]
[fs[i](1) for i in range(10)]
Same as [f(1) for f in fs]
[10, 10, 10, 10, 10, 10, 10, 10, 10, 10] <=== not good
( that was a big surprise! . . . )
Thomas Rachel writes:
> Am 31.05.2011 12:08 schrieb Jussi Piitulainen:
>
> > The same sharing-an-i thing happens here:
> >
> fs = []
> for i in range(4):
> > ...fs.append(lambda n : i + n)
> > ...
> fs[0](0)
> > 3
> >
> > And the different private-j thing happens here:
> >
> >>>
Am 31.05.2011 12:08 schrieb Jussi Piitulainen:
The same sharing-an-i thing happens here:
fs = []
for i in range(4):
...fs.append(lambda n : i + n)
...
fs[0](0)
3
And the different private-j thing happens here:
gs = []
for i in range(4):
...gs.append((lambda j : lambda n : j + n)
harrismh777 writes:
> >>> fs=[]
> >>> fs = [(lambda n: i + n) for i in range(10)]
> >>> [fs[i](1) for i in range(10)]
> [10, 10, 10, 10, 10, 10, 10, 10, 10, 10] <=== not good
>
> ( that was a big surprise! . . . )
> ( let's try it another way . . . )
The ten functions share the
On Tue, May 31, 2011 at 12:48 AM, harrismh777 wrote:
> What is going on with the binding in the first construct... this seems
> to reduce the usefulness of lambda to a considerable extent?
I don't see why; as you've shown there are a couple of simple ways to
avoid this problem. The trick is
On Mon, May 30, 2011 at 11:48 PM, harrismh777 wrote:
fs=[]
fs = [(lambda n: i + n) for i in range(10)]
[fs[i](1) for i in range(10)]
>
> [10, 10, 10, 10, 10, 10, 10, 10, 10, 10] <=== not good
>
> ( that was a big surprise! . . . )
> lambda? closure? scope? bug?
>
46 matches
Mail list logo
