Favorite non-python language trick?

[Joseph Garvin]

As someone who learned C first, when I came to Python everytime I read
about a new feature it was like, "Whoa! I can do that?!" Slicing, dir(),
getattr/setattr, the % operator, all of this was very different from C.

I'm curious -- what is everyone's favorite trick from a non-python
language? And -- why isn't it in Python?

Here's my current candidate:

So the other day I was looking at the language Lua. In Lua, you make a
line a comment with two dashes:

-- hey, this is a comment.

And you can do block comments with --[[ and ---]].

--[[
hey
this
is
a
big
comment
--]]

This syntax lets you do a nifty trick, where you can add or subtract a
third dash to change whether or not code runs:

--This code won't run because it's in a comment block
--[[
print(10)
--]]

--This code will, because the first two dashes make the rest a comment,
breaking the block
---[[
print(10)
--]]

So you can change whether or not code is commented out just by adding a
dash. This is much nicer than in C or Python having to get rid of """ or
/* and */. Of course, the IDE can compensate. But it's still neat :)

[George Sakkis]

"Konstantin Veretennicov" <kv***********@ gmail.com> wrote:

On 6/25/05, Steven D'Aprano <st***@removeth iscyber.com.au> wrote:

On Sat, 25 Jun 2005 17:41:58 +0200, Konstantin Veretennicov wrote:

On 6/25/05, Mandus <ma****@gmail.c om> wrote:
> It is really a consensus on this; that
> removing map, filter, reduce is a good thing? It will render a whole lot
> of my software unusable :(

I think you'll be able to use "from __past__ import map, filter,
reduce" or something like that :) They don't have to be built-in.

More likely they will be moved to something like itertools than "__past__".

Or just define them yourself:

def map(f, seq):
return [f(x) for x in seq]

def filter(p, seq):
return [x for x in seq if p(x)]

def reduce(f, seq, zero):
r = zero
for x in seq: r = f(r, x)
return r

FWIW, these don't exactly reproduce behaviour of current built-ins.
Filter, for instance, doesn't always return lists and map accepts more
than one seq... Just my $.02.

- kv

If they go to itertools, they can simply be:

def map(f, *iterables):
return list(imap(f,*it erables))

def filter(f, seq):
return list(ifilter(f, seq))

George

[Mandus]

Sun, 26 Jun 2005 04:36:51 +1000 skrev Steven D'Aprano:

On Sat, 25 Jun 2005 17:41:58 +0200, Konstantin Veretennicov wrote:

On 6/25/05, Mandus <ma****@gmail.c om> wrote:

It is really a consensus on this; that
removing map, filter, reduce is a good thing? It will render a whole lot
of my software unusable :(

I think you'll be able to use "from __past__ import map, filter,
reduce" or something like that :) They don't have to be built-in.

More likely they will be moved to something like itertools than "__past__".

Or just define them yourself:

def map(f, seq):
return [f(x) for x in seq]

def filter(p, seq):
return [x for x in seq if p(x)]

def reduce(f, seq, zero):
r = zero
for x in seq: r = f(r, x)
return r

sure - that will be possible. But the main point (for me) is to avoid
the horrible slow for-loop in python (reduce...). By using the builtin reduce, I
move the for-loop into the c-code which performs better.

map and filter with list-comprehensions is probably ok - I use
list-comprehensions a lot, but somehow like the syntax of map/filter
better.

When it comes to lambdas, I am not so sure. I use them all the time, and
I will certainly miss them, and I have used lambdas in ways which at
least take som tinkering to translate to normal def's (or rather
closures). But I am not sure yet whether I have cases which are
impossible to translate (hey, nothing is impossible, some things just
take a bit more time).

Oh, and by the way, I use python to solve PDEs :)

But as someone else said, this will take some time. And I can always put
the c-function back in my self when that time comes.

Another important point, which it seems Guido does not fancy very much,
is that Python can be an ok functional style language for those who like
it. I very much enjoy the concept of using different programming styles
within the same language. It is mostly a convenience - I admit that -
but it makes me more productive. I'll be very sorry if we take that away
from python.

Maybe I am to late to change Guido on this - but if we are many, maybe
we can!

--
Mandus - the only mandus around.

[Mandus]

Sat, 25 Jun 2005 16:06:57 GMT skrev Lee Harr:

Higher-order functions like map, filter and reduce. As of Python 3000,
they're non-python tricks. Sigh - i guess it's time for me to get to know
list comprehensions a bit better.

Couldnt there just be a "functional " module ?...

from functional import map, filter, reduce

but lambda is grammar, so probably not so easy to import?
--
Mandus - the only mandus around.

[Devan L]

Why overload when you can use class methods?

[Nicolas Fleury]

Steven D'Aprano wrote:

One of the things I liked in Pascal was the "with" keyword. You could
write something like this:

with colour do begin
red := 0; blue := 255; green := 0;
end;

instead of:

colour.red := 0; colour.blue := 255; colour.green := 0;

Okay, so maybe it is more of a feature than a trick, but I miss it and it
would be nice to have in Python.

With PEP343 (I guess in Python 2.5), you will be able to do something like:
with renamed(colour) as c:
c.red = 0; c.blue = 255; c.green = 0

I think however it is bad. Better solutions to me would be:

colour.setRgb(0 , 255, 0)

or

c = myVeryLongNameC olour
c.red = 0; c.blue = 255; c.green = 0

Regards,
Nicolas

[Mandus]

Sat, 25 Jun 2005 21:30:26 +0200 skrev Peter Otten:

Mandus wrote:

By using the builtin reduce, I
move the for-loop into the c-code which performs better.

No. There is no hope of ever writing fast code when you do not actually
measure its performance.

I do.

--
Mandus - the only mandus around.

[Devan L]

But by using the builtin reduce, you need to specify a function, which
probably slows it down more than any speed-up from the loop in C.

[Mandus]

25 Jun 2005 13:15:16 -0700 skrev Devan L:

But by using the builtin reduce, you need to specify a function, which
probably slows it down more than any speed-up from the loop in C.

Sounds reasonable, but not always the case, especially when dealing with
numpy arrays. At least that what some of my test shows. But then I
should probably write c-functions that deals with the numeric arrays
anyway.

Besides, functions like 'operator.add' is also in c, maybe that helps.

But I admit it's not a perfect example.

--
Mandus - the only mandus around.

[Robert Kern]

Devan L wrote:

But by using the builtin reduce, you need to specify a function, which
probably slows it down more than any speed-up from the loop in C.

Not if the function is from an extension module. For some applications,
this can be quite common.

Of course, in a Python 3000 world, nothing stops anyone from using their
own extension module implementing map, filter, and reduce if they really
want to. TSBOOOWTDI in the language/stdlib, but it shouldn't stop anyone
from using other ways to do it that aren't in the stdlib if the
tradeoffs are right for them.

--
Robert Kern
rk***@ucsd.edu

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

[Peter Otten]

Mandus wrote:

25 Jun 2005 13:15:16 -0700 skrev Devan L:

But by using the builtin reduce, you need to specify a function, which
probably slows it down more than any speed-up from the loop in C.
Sounds reasonable, but not always the case, especially when dealing with
numpy arrays. At least that what some of my test shows. But then I
should probably write c-functions that deals with the numeric arrays
anyway.

Besides, functions like 'operator.add' is also in c, maybe that helps.

Yes, the C-coded operator.mul() was the counterexample that John Lenton came
up with when I challenged the speed advantage of reduce() over the
equivalent for-loop.
But I admit it's not a perfect example.

Python is more about readability than raw speed, and I prefer a for-loop
over reduce() in that respect, too. If you need the best possible
efficiency you would probably have to code the loop in C. Incidentally, for
add() this has already been done with the sum() builtin.

Peter