Greg Ewing wrote the following on 2006-02-10 at 16:20 PST:
===
> Although "print" may become a function in 3.0, so that this
> particular example would no longer be a problem.
===
You can always make your own Print function. The pyNMS framework adds
many new builtins, as well as a Print function,
Guido van Rossum wrote the following on 2006-02-09 at 16:27 PST:
===
> Since you probably won't stop until I give you an answer: I'm really
> not interested in a syntactic solution that allows multi-line lambdas.
===
Fuzzy little lambdas, wouldn't hurt a fly.
Object of much derision, one has to wo
Die thread, die!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Fri, 10 Feb 2006 16:49:13 +1300, Greg Ewing <[EMAIL PROTECTED]> wrote:
>Valentino Volonghi aka Dialtone wrote:
>
>> when some_operation_that_results_in_a_deferred() -> result:
>> if result == 'Initial Value':
>> when work_on_result_and_return_a_deferred(result) -> inner_res:
>>
Guido van Rossum wrote:
> To those people who believe that lambda is required in some situations
> because it behaves differently with respect to the surrounding scope
> than def: it doesn't, and it never did. This is (still!) a
> surprisingly common myth. I have no idea where it comes from; does
Valentino Volonghi aka Dialtone wrote:
> when some_operation_that_results_in_a_deferred() -> result:
> if result == 'Initial Value':
> when work_on_result_and_return_a_deferred(result) -> inner_res:
> print inner_res
> else:
> print "No work on result"
> rea
[EMAIL PROTECTED] wrote:
> Lambdas are expressions. Statements can't be embedded in expressions. That
> statements and expressions are different is a core feature of the language.
> That is almost certainly not going to change.
Although "print" may become a function in 3.0, so that this
particu
On Thu, 9 Feb 2006 16:27:35 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>[Bengt, on lambda :: suite]
>
>Since you probably won't stop until I give you an answer: I'm really
>not interested in a syntactic solution that allows multi-line lambdas.
>I don't think the complexity (in terms of use
On Fri, 10 Feb 2006 01:23:25 +0100, Thomas Wouters <[EMAIL PROTECTED]> wrote:
>On Fri, Feb 10, 2006 at 12:16:30AM +, Bengt Richter wrote:
>> On Thu, 9 Feb 2006 10:33:10 -0800, Guido van Rossum <[EMAIL PROTECTED]>
>> wrote:
>> >Enough already.
>
[...some stuff snipped...]
>> Yes, but if you're
Guido van Rossum wrote:
> [Bengt, on lambda :: suite]
>
> Since you probably won't stop until I give you an answer: I'm really
> not interested in a syntactic solution that allows multi-line lambdas.
> I don't think the complexity (in terms of users needing to learn them)
> is worth it. So please
[Bengt, on lambda :: suite]
Since you probably won't stop until I give you an answer: I'm really
not interested in a syntactic solution that allows multi-line lambdas.
I don't think the complexity (in terms of users needing to learn them)
is worth it. So please stop (as several people have already
On Fri, Feb 10, 2006 at 12:16:30AM +, Bengt Richter wrote:
> On Thu, 9 Feb 2006 10:33:10 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >Enough already.
> Yes, but if you're an optimist, those years mean we're closer to the magic
> moment ;-)
Please stop. Discuss it elsewhere. I suggest
On Thu, 9 Feb 2006 10:33:10 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>Enough already.
>
>As has clearly been proven, lambda is already perfect.
>
[...]
>
>To those people still complaining that lambda is crippled because it
>doesn't do statements: First, remember that adding statement
>c
On 2/9/06, Valentino Volonghi aka Dialtone <[EMAIL PROTECTED]> wrote:
> Let's consider this piece of code (actual code that works today and uses
> twisted for convenience):
>
> def do_stuff(result):
> if result == 'Initial Value':
> d2 = work_on_result_and_return_a_deferred(result)
>
On Thu, 09 Feb 2006 17:39:31 +0100, "\"Martin v. Löwis\"" <[EMAIL PROTECTED]>
wrote:
>It's not a specific example though: what precise library provides
>the visit method?
I'll provide my own usecase right now which is event driven programming of
any kind (from GUI toolkits, to network frameworks/
Enough already.
As has clearly been proven, lambda is already perfect.
***
To those folks attempting to propose alternate syntax (e.g. x -> y):
this is the wrong thread for that (see subject). Seriously, I've seen
lots of proposals that just change the syntax, and none of them are so
much better
On Thu, 09 Feb 2006 17:39:31 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
<[EMAIL PROTECTED]> wrote:
>Jiwon Seo wrote:
>> Apparently, simplest example is,
>>
>> collection.visit(lambda x: print x)
>
>Ok. I remotely recall Guido suggesting that print should become
>a function.
>
Even so, tha
Jiwon Seo wrote:
> Apparently, simplest example is,
>
> collection.visit(lambda x: print x)
Ok. I remotely recall Guido suggesting that print should become
a function.
It's not a specific example though: what precise library provides
the visit method?
> which currently is not possible. Another
>> Hmm. Can you give real-world examples (of existing code) where you
>> needed this?
Jiwon> Apparently, simplest example is,
Jiwon> collection.visit(lambda x: print x)
Sure, but has several other people have indicated, statements are not
expressions in Python as they are in C (
On 2/8/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Jiwon Seo wrote:
> > Then, is there any chance anonymous function - or closure - is
> > supported in python 3.0 ? Or at least have a discussion about it?
>
> That discussion appears to be closed (or, not really: everybody
> can discuss, but
Jiwon Seo wrote:
> Then, is there any chance anonymous function - or closure - is
> supported in python 3.0 ? Or at least have a discussion about it?
That discussion appears to be closed (or, not really: everybody
can discuss, but it likely won't change anything).
> (IMHO, closure is very handy f
Jiwon Seo <[EMAIL PROTECTED]> wrote:
> On 2/8/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > Closures already exist in Python.
> >
> > >>> def foo(bar):
> > ... return lambda: bar + 1
> > ...
> > >>> a = foo(5)
> > >>> a()
> > 6
>
> Not in that we don't have anonymous function (or closure)
On 2/8/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> Jiwon Seo <[EMAIL PROTECTED]> wrote:
> >
> > On 2/8/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > On 2/8/06, Patrick Collison <[EMAIL PROTECTED]> wrote:
> > > > And to think that people thought that keeping "lambda", but changing
> >
Jiwon Seo <[EMAIL PROTECTED]> wrote:
>
> On 2/8/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 2/8/06, Patrick Collison <[EMAIL PROTECTED]> wrote:
> > > And to think that people thought that keeping "lambda", but changing
> > > the name, would avoid all the heated discussion... :-)
> >
>
On 2/8/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 2/8/06, Patrick Collison <[EMAIL PROTECTED]> wrote:
> > And to think that people thought that keeping "lambda", but changing
> > the name, would avoid all the heated discussion... :-)
>
> Note that I'm not participating in any attempts to
Guido van Rossum <[EMAIL PROTECTED]> writes:
> On 2/8/06, Patrick Collison <[EMAIL PROTECTED]> wrote:
>> And to think that people thought that keeping "lambda", but changing
>> the name, would avoid all the heated discussion... :-)
>
> Note that I'm not participating in any attempts to "improve" l
Robert Brewer wrote:
> Community consensus on syntax is a pipe dream.
+1 QOTF
And trust me, it'll be in there, since I'm one of the summary writers. ;-)
STeVe
--
Grammar am for people who can't think for myself.
--- Bucky Katt, Get Fuzzy
___
Py
Guido van Rossum wrote the following on 2006-02-08 at 10:07 PST:
===
> Note that I'm not participating in any attempts to "improve" lambda.
===
FWIW, I like lambda. No need to change it. Thank you.
--
-- ~
Keith Dart <[EMA
Raymond Hettinger wrote:
>>How about (lambda x,y: x**y)?
>
>
> The purpose of this thread was to conserve brain-power by bringing the issue
> to a close. Instead, it is turning into syntax/renaming fest. May I
> suggest that this be moved to comp.lang.python and return only if a
> community
Raymond Hettinger wrote:
> > How about (lambda x,y: x**y)?
>
> The purpose of this thread was to conserve brain-power by
> bringing the issue to a close. Instead, it is turning into
> syntax/renaming fest. May I suggest that this be moved to
> comp.lang.python and return only if a community con
> How about (lambda x,y: x**y)?
The purpose of this thread was to conserve brain-power by bringing the issue
to a close. Instead, it is turning into syntax/renaming fest. May I
suggest that this be moved to comp.lang.python and return only if a
community consensus emerges from the thousands o
On 2/8/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 10:07 AM 2/8/2006 -0800, Guido van Rossum wrote:
> >On 2/8/06, Patrick Collison <[EMAIL PROTECTED]> wrote:
> > > And to think that people thought that keeping "lambda", but changing
> > > the name, would avoid all the heated discussion... :-
At 10:07 AM 2/8/2006 -0800, Guido van Rossum wrote:
>On 2/8/06, Patrick Collison <[EMAIL PROTECTED]> wrote:
> > And to think that people thought that keeping "lambda", but changing
> > the name, would avoid all the heated discussion... :-)
>
>Note that I'm not participating in any attempts to "impr
On 2/8/06, Patrick Collison <[EMAIL PROTECTED]> wrote:
> And to think that people thought that keeping "lambda", but changing
> the name, would avoid all the heated discussion... :-)
Note that I'm not participating in any attempts to "improve" lambda.
Just about the only improvement I'd like to s
On Wed, Feb 08, 2006, Patrick Collison wrote:
>
> How about `procedure', or just `proc'?
-1
lambdas are *expected* to return a result -- procedures are functions
with side-effects that don't return a result.
--
Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/
"19. A la
>> After so many attempts to come up with an alternative for lambda,
>> perhaps we should admit defeat. I've not had the time to follow the
>> most recent rounds, but I propose that we keep lambda, so as to stop
>> wasting everybody's talent and time on an impossible quest.
>
> I agree with this. T
On 2/7/06, Michael Urman <[EMAIL PROTECTED]> wrote:
> On 2/6/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > And I think that a deferred object would help with one of
> > lambda's biggest uses and made its loss totally reasonable.
>
> The ambiguity inherent from the perspective of a deferred object
On 2/7/06, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 2/7/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > On 2/5/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > After so many attempts to come up with an alternative for lambda,
> > > perhaps we should admit defeat. I've not had the time to fol
On 2/6/06, Christopher Armstrong <[EMAIL PROTECTED]> wrote:
> On 2/7/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Brett Cannon wrote:
> > > But I know that everyone and their email client is against me on this
> > > one, so I am not going to really try to tear into this. But I do
> > > thi
Jiwon Seo wrote:
> After lambda being made more useful, can I hope that I will be able to
> use lambda with multiple statements? :) Lambdas in Lisp and Python are
> different, but in the usability perspective they don't need to differ
> too much.
To my knowledge, nobody proposed to make it "more u
On 2/6/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> And I think that a deferred object would help with one of
> lambda's biggest uses and made its loss totally reasonable.
The ambiguity inherent from the perspective of a deferred object makes
a general one impractical. Both map(Deferred().attribu
On 2/7/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On 2/5/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > After so many attempts to come up with an alternative for lambda,
> > perhaps we should admit defeat. I've not had the time to follow the
> > most recent rounds, but I propose that we kee
Jiwon Seo wrote:
> After lambda being made more useful, can I hope that I will be able to use
> lambda with multiple statements? :) Lambdas in Lisp and Python are
> different, but in the usability perspective they don't need to differ too
> much.
I don't think it helps usability much if anonymous
On 2/6/06, Christopher Armstrong <[EMAIL PROTECTED]> wrote:
> On 2/7/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Brett Cannon wrote:
> > > But I know that everyone and their email client is against me on this
> > > one, so I am not going to really try to tear into this. But I do
> > > thi
On 2/7/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
> > But I know that everyone and their email client is against me on this
> > one, so I am not going to really try to tear into this. But I do
> > think that lambda needs a renaming. Speaking as someone who still
> > fo
Brett Cannon wrote:
> But I know that everyone and their email client is against me on this
> one, so I am not going to really try to tear into this. But I do
> think that lambda needs a renaming. Speaking as someone who still
> forgets that Python's lambda is not the same as those found in
> fun
On 2/5/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> After so many attempts to come up with an alternative for lambda,
> perhaps we should admit defeat. I've not had the time to follow the
> most recent rounds, but I propose that we keep lambda, so as to stop
> wasting everybody's talent and ti
Guido van Rossum wrote:
> After so many attempts to come up with an alternative for lambda,
> perhaps we should admit defeat. I've not had the time to follow the
> most recent rounds, but I propose that we keep lambda, so as to stop
> wasting everybody's talent and time on an impossible quest.
>
T
Steven Bethard wrote:
> Guido van Rossum wrote:
>> After so many attempts to come up with an alternative for lambda,
>> perhaps we should admit defeat. I've not had the time to follow the most
>> recent rounds, but I propose that we keep lambda, so as to stop wasting
>> everybody's talent and time
> After so many attempts to come up with an alternative for lambda,
> perhaps we should admit defeat. I've not had the time to follow the
> most recent rounds, but I propose that we keep lambda, so as to stop
> wasting everybody's talent and time on an impossible quest.
+1.
This would remove my s
Guido van Rossum wrote:
> After so many attempts to come up with an alternative for lambda,
> perhaps we should admit defeat. I've not had the time to follow the
> most recent rounds, but I propose that we keep lambda, so as to stop
> wasting everybody's talent and time on an impossible quest.
Per
On 5 feb 2006, at 18:43, Guido van Rossum wrote:
> After so many attempts to come up with an alternative for lambda,
> perhaps we should admit defeat. I've not had the time to follow the
> most recent rounds, but I propose that we keep lambda, so as to stop
> wasting everybody's talent and time on
[Crutcher Dunnavant[
> Which reminds me, we need to support roman numeral constants.
One of my more-normal relatives reminded me that this is Super Bowl XL
Sunday, so your demand is more topical than it would ordinarily be.
Alas, there's already a PEP on this, and it was already rejected. See
PE
Which reminds me, we need to support roman numeral constants.
A silly implementation follows.
class RomanNumeralDict(dict):
def __getitem__(self, key):
if not self.has_key(key) and self.isRN(key):
return self.decodeRN(key)
return dict.__getitem__(self, key)
def isRN(self, key):
[Guido]
> After so many attempts to come up with an alternative for lambda,
> perhaps we should admit defeat. I've not had the time to follow the
> most recent rounds, but I propose that we keep lambda, so as to stop
> wasting everybody's talent and time on an impossible quest.
Huh! Was someone b
+1
On 2/5/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> After so many attempts to come up with an alternative for lambda,
> perhaps we should admit defeat. I've not had the time to follow the
> most recent rounds, but I propose that we keep lambda, so as to stop
> wasting everybody's talent an
+1 on retaining lambda
-1 on any name change
On Sun, 5 Feb 2006, Paul Moore wrote:
> On 2/5/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > After so many attempts to come up with an alternative for lambda,
> > perhaps we should admit defeat. I've not had the time to follow the
> > most rece
> After so many attempts to come up with an alternative for lambda,
> perhaps we should admit defeat. I've not had the time to follow the
> most recent rounds, but I propose that we keep lambda, so as to stop
> wasting everybody's talent and time on an impossible quest.
+1 -- trying to cover all t
On 2/5/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> After so many attempts to come up with an alternative for lambda,
> perhaps we should admit defeat. I've not had the time to follow the
> most recent rounds, but I propose that we keep lambda, so as to stop
> wasting everybody's talent and ti
On Sunday 05 February 2006 12:43, Guido van Rossum wrote:
> After so many attempts to come up with an alternative for lambda,
> perhaps we should admit defeat. I've not had the time to follow the
> most recent rounds, but I propose that we keep lambda, so as to stop
> wasting everybody's talent
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> After so many attempts to come up with an alternative for lambda,
> perhaps we should admit defeat. I've not had the time to follow the
> most recent rounds, but I propose that we keep lambda, so as to stop
> wasting
Guido van Rossum wrote:
>After so many attempts to come up with an alternative for lambda,
>perhaps we should admit defeat. I've not had the time to follow the
>most recent rounds, but I propose that we keep lambda, so as to stop
>wasting everybody's talent and time on an impossible quest.
>
>--
>
After so many attempts to come up with an alternative for lambda,
perhaps we should admit defeat. I've not had the time to follow the
most recent rounds, but I propose that we keep lambda, so as to stop
wasting everybody's talent and time on an impossible quest.
--
--Guido van Rossum (home page: h
63 matches
Mail list logo
