In article [EMAIL PROTECTED],
Alex Martelli [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Thanks. :-) Two remarks.
o One-liner fits the eyes brains of a portion of people.
True! So, personally, I'd rather code, e.g.,
def bools(lst): return map(bool, lst)
rather than breal this
In article [EMAIL PROTECTED],
Craig Ringer [EMAIL PROTECTED] wrote:
.
.
.
IMO the reference behaviour of functions in the C API could be
clearer. One often has to simply know, or refer to the docs, to tell
whether a
On Wed, 2004-12-29 at 02:08, Cameron Laird wrote:
In article [EMAIL PROTECTED],
Craig Ringer [EMAIL PROTECTED] wrote:
.
.
.
IMO the reference behaviour of functions in the C API could be
clearer. [snip]
Dima Dorfman wrote:
I happen to not mind the ''.join syntax, but if I did, I would use
str.join('', seq)
which is just like a join builtin except that it's not as easy to make
it work on pre-string-method Pythons.
just like join, except that it isn't:
string.join(seq, sep)
u'axbxc'
Aahz wrote:
(I've said it before, and I'll say it again: native unicode and
generators are the only essential additions I've seen since 1.5.2, with
properties and sub-classable C types sharing a distant third place.
the rest of the stuff has had zero impact on my ability to write solid
code in no
In article [EMAIL PROTECTED],
Fredrik Lundh [EMAIL PROTECTED] wrote:
func(*arg) instead of apply() is a step back -- it hides the fact
that functions are objects, and it confuses the heck out of both
C/C++ programmers and Python programmers that understand the def
func(*arg) form, because it
On 2004-12-26, Fredrik Lundh [EMAIL PROTECTED] wrote:
string methods are nice, but nothing groundbreaking, and their niceness is
almost entirely offset by the horrid .join(seq) construct that keeps popping
up when people take the the string module is deprecated yada yada too
seriously. and
[EMAIL PROTECTED] (Aahz) writes:
While I'm in complete agreement about the .join() construct on the
basis of looks, I have come to appreciate the fact that I *never* mess up
the order of arguments any more.
Yeah. When I needed joinable arrays of strings in Eiffel, I added them
to the
Benji York wrote:
They do two different things. I think you have a spurious * in the call
to apply. The apply above is equivalent to
D'oh! This cold has definitely made me error prone the last
couple of days. Yesterday I managed to leave my cell phone
in my pants pocket along with a couple
Terry Reedy wrote:
Ok, add 'assuming that func and args are a valid callable and sequence
respectively.' Error messages are not part of the specs, and may change
for the same code from version to version.
While true, the difference in error messages suggests that the
two approaches use
Python 2.4 interactive session:
Py class Blah:
... def __iter__(self):
... yield Test
...
Py args = Blah()
Py apply(len, args)
Traceback (most recent call last):
File stdin, line 1, in ?
TypeError: apply() arg 2 expected sequence, found instance
Py len(*args)
4
Py class Blah(object):
...
Nick Coghlan wrote:
And you're right, there is a behavioural difference - apply() expects a real
sequence, whereas the extended function call syntax accepts any iterable.
However, there's also a bug in your demo code:
I guess I must be getting over this cold -- I'm only 1/2 wrong
this time.
In article [EMAIL PROTECTED],
Fredrik Lundh [EMAIL PROTECTED] wrote:
(I've said it before, and I'll say it again: native unicode and
generators are the only essential additions I've seen since 1.5.2, with
properties and sub-classable C types sharing a distant third place.
the rest of the stuff
Fernando Perez said unto the world upon 2004-12-23 14:42:
Alex Martelli wrote:
I don't know what it IS about lambda that prompts so much dubious to
absurd use, but that's what I observed. I don't know if that plays any
role in Guido's current thinking, though -- I have no idea how much
dubious
Nick Coghlan [EMAIL PROTECTED] writes:
jfj wrote:
Python 3.0 will be a case of OK, let's take the things we learned
were good and keep them, and throw away the things we realised were
bad
Undoubtedly, the two languages will co-exist for quite some time.
Perl 6.0 is going to include even
Andrew Dalke wrote:
Terry Reedy wrote:
As far as I know, apply(func, args) is exactly equivalent to func(*args).
After playing around a bit I did find one difference in
the errors they can create.
def count():
... yield 1
...
apply(f, count())
Traceback (most recent call last):
File stdin,
Andrew Dalke [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Terry Reedy wrote:
As far as I know, apply(func, args) is exactly equivalent to
func(*args).
After playing around a bit I did find one difference in
the errors they can create.
Ok, add 'assuming that func and args are
Mike Perl 6.0 is going to include even more drastic changes. It will
Mike also include a Perl 5.x interpreter, and will have to be switched
Mike to 6.0 mode by a magic cookie of some kind in the source. Possibly
Mike Python 3.0 could do something similar.
-1
Things are complex
Craig Ringer wrote:
It's hard to consistently support Unicode in extension modules without
doing a lot of jumping through hoops. Unicode in docstrings is
particularly painful. This may not be a big deal for normal extension
modules, but when embedding Python it's a source of considerable
-examples of using or not using
the lambdas.
While following the thread Lambda going out of fashion
I have read cries for not throwing lambdas away and also
the opposite opinions. I believe that the theme requires
more examples to convince. I personally incline towards
the experience of Craig Ringer (see
Keith Dart [EMAIL PROTECTED] wrote:
My personal gripe is this. I think the core language, as of 2.3 or 2.4
is very good, has more features than most people will ever use, and they
Indeed, it has _too many_ features. Look at the PEP about 3.0, and
you'll see that removing redundant features
On Thu, 23 Dec 2004 14:13:28 +1000, Stephen Thorne
[EMAIL PROTECTED] wrote:
I'm a little worried about the expected disappearance of lambda in
python3000. I've had my brain badly broken by functional programming
in the past, and I would hate to see things suddenly become harder
than they need
On 22 Dec 2004 23:21:37 -0800, [EMAIL PROTECTED] wrote:
but if lambda keyword is removed, I swear I will not use the python
anymore.
While I would be dissappointed to lose lambda, I think losing
Python would hurt me a lot more! After all we aren't losing
functionality here, just adding sonme
Alan Gauld [EMAIL PROTECTED] writes:
readability. Pythonic lambdas are just syntactic sugar in
practice,
Actually it's the other way around: it's named functions that are the
syntactic sugar.
--
http://mail.python.org/mailman/listinfo/python-list
On 23 Dec 2004 00:52:53 -0800, Paul Rubin
http://phr.cx@nospam.invalid wrote:
Alan Gauld [EMAIL PROTECTED] writes:
readability. Pythonic lambdas are just syntactic sugar in
practice,
Actually it's the other way around: it's named functions that are the
syntactic sugar.
Not true, you
Stephen Thorne wrote:
Not true, you can't re-write
def f():
raise ValueError, Don't call f
f = lambda: eval(compile(raise ValueError(\Don't call f\), , exec))
note that lambdas have names too, btw:
print f.func_name
lambda
/F
--
Alan Gauld wrote:
It can't be that hard to maintain the lambda code, why not just
leave it there for the minority of us who like the concept?
Because one of the points of Py3K is to clean up the language concepts and
syntax, and the current lambda just doesn't fit cleanly. If it was proposed in a
Alex Martelli wrote:
I think I'll scream, though not quite as loud as for my next seeing:
map(lambda x: f(x), ...
instead of
map(f, ...
note that if you replace map with some function that takes a callable, the
difference
between these two constructs may be crucially important.
/F
Alex Martelli wrote:
if len(somecontainer) 0:
instead of the obvious
if somecontainer:
so it's not as if pythonistas in general are blessed with some magical
redundancy avoidance spell...
That is not always equivalent:
z = Numeric.zeros(5)
z
array([0, 0, 0, 0, 0])
bool(z)
False
Peter Otten [EMAIL PROTECTED] wrote:
Alex Martelli wrote:
if len(somecontainer) 0:
instead of the obvious
if somecontainer:
so it's not as if pythonistas in general are blessed with some magical
redundancy avoidance spell...
That is not always equivalent:
z =
jfj wrote:
Stephen Thorne wrote:
Hi guys,
I'm a little worried about the expected disappearance of lambda in
python3000. I've had my brain badly broken by functional programming
in the past, and I would hate to see things suddenly become harder
than they need to be.
Don't worry, it's not gonna go
Nick Coghlan [EMAIL PROTECTED] wrote:
...
Perhaps something like:
accepts_func( (def (a, b, c) to f(a) + o(b) - o(c)) )
Nice, except I think 'as' would be better than 'to'. 'as' should be a
full keyword in 3.0 anyway (rather than a surprisingly-NOT-keyword like
today), and define
Fredrik Lundh wrote:
Craig Ringer wrote:
It's hard to consistently support Unicode in extension modules without
doing a lot of jumping through hoops. Unicode in docstrings is
particularly painful. This may not be a big deal for normal extension
modules, but when embedding Python it's a source
Alex Martelli wrote:
.
By the way, if that's very important to you, you might enjoy Mozart
(http://www.mozart-oz.org/) -- I'm looking at it and it does appear to
go even further in this specific regard (rich support for multi -
paradigm programming). It's also blessed with a great book,
Alex Martelli wrote:
Nick Coghlan [EMAIL PROTECTED] wrote:
...
Perhaps something like:
accepts_func( (def (a, b, c) to f(a) + o(b) - o(c)) )
Nice, except I think 'as' would be better than 'to'. 'as' should be a
full keyword in 3.0 anyway (rather than a surprisingly-NOT-keyword like
today),
Nick Coghlan wrote:
Indeed, lambda as it currently stands will disappear for the Python 2.x
series.
Will NOT disappear. I repeat, will NOT disappear.
Cheers,
Nick.
Damn those missing negators. . .
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
On Thu, 23 Dec 2004 13:47:49 +0100, Alex Martelli [EMAIL PROTECTED] wrote:
Nick Coghlan [EMAIL PROTECTED] wrote:
...
Perhaps something like:
accepts_func( (def (a, b, c) to f(a) + o(b) - o(c)) )
Nice, except I think 'as' would be better than 'to'. 'as' should be a
full keyword in
Stephen Thorne [EMAIL PROTECTED] wrote in
news:[EMAIL PROTECTED]:
Hi guys,
I'm a little worried about the expected disappearance of lambda
in python3000. I've had my brain badly broken by functional
programming in the past, and I would hate to see things suddenly
become harder than they
On Thu, 23 Dec 2004 13:36:08 GMT, rzed [EMAIL PROTECTED] wrote:
Stephen Thorne [EMAIL PROTECTED] wrote in
news:[EMAIL PROTECTED]:
[snip]
{
'one': lambda x:x.blat(),
'two': lambda x:x.blah(),
}.get(someValue, lambda x:0)(someOtherValue)
The alternatives to this, reletively
Stephen {
Stephen 'one': lambda x:x.blat(),
Stephen 'two': lambda x:x.blah(),
Stephen }.get(someValue, lambda x:0)(someOtherValue)
One thing to remember is that function calls in Python are pretty damn
expensive. If x.blat() or x.blah() are themselves only one or two lines of
Keith My personal gripe is this. I think the core language, as of 2.3
Keith or 2.4 is very good, has more features than most people will ever
Keith use, and they (Guido, et al.) can stop tinkering with it now and
Keith concentrate more on the standard libraries.
What keeps you
Craig IMO the reference behaviour of functions in the C API could be
Craig clearer. One often has to simply know, or refer to the docs, to
Craig tell whether a particular call steals a reference or is reference
Craig neutral. Take, for example, PyDict_SetItemString vs
Craig
readability. Pythonic lambdas are just syntactic sugar in practice,
Paul Actually it's the other way around: it's named functions that are
Paul the syntactic sugar.
While I'm sure it can be done, I'd hate to see a non-trivial Python program
written with lambda instead of def.
On Thu, 23 Dec 2004 10:19:33 -0600, Skip Montanaro [EMAIL PROTECTED] wrote:
readability. Pythonic lambdas are just syntactic sugar in practice,
Paul Actually it's the other way around: it's named functions that are
Paul the syntactic sugar.
While I'm sure it can be done, I'd
Skip Montanaro wrote:
Keith My personal gripe is this. I think the core language, as of 2.3
Keith or 2.4 is very good, has more features than most people will ever
Keith use, and they (Guido, et al.) can stop tinkering with it now and
Keith concentrate more on the standard
I have this book called TEXT PROCESSING IN PYTHON by David Mertz on
hand, it is a good book and in the first chapter it is really a show
room for higher-order functions which I may now cite to remind you of
the FLEXIBILITY of this keyword.
''' combinatorial.py
from operator import mul, add, truth
[EMAIL PROTECTED] wrote:
I have this book called TEXT PROCESSING IN PYTHON by David Mertz on
hand, it is a good book and in the first chapter it is really a show
room for higher-order functions which I may now cite to remind you of
the FLEXIBILITY of this keyword.
I'm not exactly sure what you
Thanks. :-) Two remarks.
o One-liner fits the eyes brains of a portion of people.
o Why don't you just say all python can be written in equivalent java,
can I assert that Guido doesn't want to get mixed with those
mainstream?
--
http://mail.python.org/mailman/listinfo/python-list
[EMAIL PROTECTED] wrote:
o Why don't you just say all python can be written in equivalent java,
your argumentation skills are awesome.
/F
--
http://mail.python.org/mailman/listinfo/python-list
Skip Montanaro wrote:
Jp OTOH, maybe that's still trivial, it's only a multiuser network
Jp chat server, after all.
You cheated by not rewriting Twisted using only lambda.
isn't twisted already written with lambdas only? why else would they call it
twisted?
/F
--
On Thu, 23 Dec 2004 12:00:29 -0600, Skip Montanaro [EMAIL PROTECTED] wrote:
While I'm sure it can be done, I'd hate to see a non-trivial Python
program written with lambda instead of def.
Jp What, like this?
Jp (lambda r,p,b:...
Jp OTOH, maybe that's still
Skip Montanaro [EMAIL PROTECTED] wrote in
news:[EMAIL PROTECTED]:
Stephen {
Stephen 'one': lambda x:x.blat(),
Stephen 'two': lambda x:x.blah(),
Stephen }.get(someValue, lambda x:0)(someOtherValue)
One thing to remember is that function calls in Python are
pretty damn
Alex Martelli wrote:
I don't know what it IS about lambda that prompts so much dubious to
absurd use, but that's what I observed. I don't know if that plays any
role in Guido's current thinking, though -- I have no idea how much
dubious Python he's had to struggle with.
Just a side comment,
Robin Becker wrote:
Alex Martelli wrote:
.
By the way, if that's very important to you, you might enjoy Mozart
(http://www.mozart-oz.org/)
.very interesting, but it wants to make me install emacs. :(
Apparently you can also use oz with a compiler and runtime engine...see
Jp Calderone [EMAIL PROTECTED] wrote in
news:[EMAIL PROTECTED]:
On Thu, 23 Dec 2004 13:36:08 GMT, rzed [EMAIL PROTECTED] wrote:
Stephen Thorne [EMAIL PROTECTED] wrote in
news:[EMAIL PROTECTED]:
[snip]
{
'one': lambda x:x.blat(),
'two': lambda x:x.blah(),
}.get(someValue, lambda
[EMAIL PROTECTED] wrote:
Thanks. :-) Two remarks.
o One-liner fits the eyes brains of a portion of people.
True! So, personally, I'd rather code, e.g.,
def bools(lst): return map(bool, lst)
rather than breal this one-liner into two lines at the colon, as per
standard Python style.
[EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Well, you can say apply() is 'deprecated' now,
What is deprecated is the spelling, not the concept or functionality.
As far as I know, apply(func, args) is exactly equivalent to func(*args).
If the latter had been invented in the
Nick Coghlan wrote:
...rather than pushing to retain lambda for Py3K, it might
be more productive to find a better statement - expression
translation for function definitions. Guido seems to prefer
named functions, so it would still be tough to gain his
acceptance. However, a more Pythonic
Stephen Thorne wrote:
Lambdas contain only a single expression. Even the py3k
wiki page ignores this critical difference. A single expression
means no statements of any kind can be included. Assignment,
if/elif/else, while, for, try/except, etc are not catered
for in lambdas.
That's been the
On 2004-12-23, Stephen Thorne [EMAIL PROTECTED] wrote:
Hi guys,
I'm a little worried about the expected disappearance of lambda in
python3000. I've had my brain badly broken by functional programming
in the past, and I would hate to see things suddenly become harder
than they need to be.
I
This is NOT true. Functional programming, AFAIKC, is a cool thing, and
in-fashion, increases productivity readability, and an indispensable
thing for a flexible scripting lang. The inline/lambda function is
feature is shared by many lang. which I frequently use,
MATLAB/R/Python/etc. Well, you can
On Thu, 2004-12-23 at 12:47, Keith Dart wrote:
On 2004-12-23, Stephen Thorne [EMAIL PROTECTED] wrote:
Hi guys,
I'm a little worried about the expected disappearance of lambda in
python3000. I've had my brain badly broken by functional programming
in the past, and I would hate to see
[EMAIL PROTECTED] wrote:
Well, you can say apply() is 'deprecated' now,
(which is another functional thing I like), but I am still using it.
Interesting. Could you explain why? Personally, I find the
*expr/**expr syntax much simpler, so I'd be interested in knowing what
motivates you to
On Thu, 2004-12-23 at 15:21, [EMAIL PROTECTED] wrote:
This is NOT true. Functional programming, AFAIKC, is a cool thing, and
in-fashion, increases productivity readability, and an indispensable
thing for a flexible scripting lang.
Couldn't agree more. One of the things I find most valuable
64 matches
Mail list logo
