Favorite non-python language trick?

[Konstantin Veretennicov]

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.

- kv

 

[Lee Harr]

Higher-order functions like map, filter and reduce. As of Python 3000,

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

from functional import map, filter, reduce

 

[Steven D'Aprano]

class color: # americanized
red = 0
blue = 255
green = 0

The problem is, you have made colour (returning to English spelling
instead of foreign) into a class. If you need two colour variables, you
have to duplicate the code for the class (perhaps only changing the
numeric constants. You can't even make instances from the class, because
they all share the same RGB values, which is pretty useless if they are
meant to represent different colours.

Less typing than pascal.

You have missed the point. I'm not comparing Python vs Pascal for
creating records representing RBG values. I'm talking about a Pascal
feature that reduced typing by allowing you to use an implicit record.
Here is one possible way you might use such a feature as a Python idiom,
letting "with" specify an implicit object. Instead of doing this:

# read a class attribute
print myobject.__class__.myattribute
# set an instance attribute
myobject.widget.datapoints[myobject.collector] \
= myobject.dispatcher(myobject.widget.current_value)

you might do this:

with myobject:
# read a class attribute
print .__class__.myattribute
# set an instance attribute
.widget.datapoints[.collector] = .dispatcher(.widget.current_value)

Also avoids those stupid little colons.

Using := and = for assignment and equality is precisely as stupid as using
= and == for assignment and equality. Perhaps less stupid: why do we use
== for equals, but not ++ for plus and -- for minus?

 

[Steven D'Aprano]

Interesting thread ...

1.) Language support for ranges as in Ada/Pascal/Ruby
1..10 rather than range(1, 10)

What advantages do Pascal-like for loops give over Python for loops?

The only two I can think of are trivial:

(1) the Pascal-like for loop is six characters shorter to type:

for i = 1 to 10: # 16 chars
for i in range(1, 10): # 22 chars

(2) for very large ranges, you don't have to hold the entire list of
integers in memory. But you can use xrange() instead of range(), which
also doesn't hold the entire list in memory.

2.) Contracts

Explain please.

3.) With

Explain please.

 

[Konstantin Veretennicov]

Explain please.

James probably meant Eiffel's Design by Contract. My favourite Python
implementation is Terence Way's http://www.wayforward.net/pycontract/
;-)

- kv

 

[Steven D'Aprano]

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

 

[Tom Anderson]

You do things like that in type-bondage languages

I love that expression. I think it started out as 'bondage and discipline
languages', which is even better. I'm going to start referring to python
as a 'sluttily typed' language.

like Java and C++ because you have to. Can you give an example of where
you miss it in Python?

No. I don't generally go around keeping a list of places where i miss
particular features or find particular warts irritating. Still, my
medium-term memory is not completely shot, so i assume i haven't missed it
much in the last couple of days!

If you want to do something different based on the type of an argument,
it's easy enough to do:

def foo (bar):
if type(bar) == whatever:
do stuff
else:
do other stuff

replace type() with isistance() if you prefer.

Yeah, i'm well aware that this is possible - what it's not is a clean
solution. If i was into writing boilerplate, i'd be using C. Also, this
gets really nasty if you want to overload on multiple variables.

Also, it actually falls down really badly in combination with duck typing
- you can't use isinstance to ask if an object looks like a file, for
example, only if it really is a file. Sure, you can do a bunch of hasattrs
to see if it's got the methods it should have, but that doesn't tell you
for certain it's a file, and it's a pain in the arse to write. In a typed
language, you'd just ask if it implemented the Channel (for example)
interface.

Python is not typeless. It's just that the types are bound to the
objects, not to the containers that hold the objects.

No. Types are properties of variables; the property that objects have is
called class. Python has classes but not types. I realise that many, even
most, people, especially those using typeless languages like python or
smalltalk, use the two terms interchangeably, but there's a real and
meaningful distinction between them. I may be the last person alive who
thinks it's an important distinction, but by god i will die thinking it.
So let's recognise that we have slightly different terminologies and not
argue about it!

tom

 

[Konstantin Veretennicov]

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

 

[Tom Anderson]

I think you'll be able to use "from __past__ import map, filter,
reduce" or something like that

from __grumpy_old_bastard_who_cant_keep_up__ import map



tom

 

[George Sakkis]

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,*iterables))

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

George

 

[Mandus]

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

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]

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

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

from functional import map, filter, reduce

but lambda is grammar, so probably not so easy to import?

 

[Devan L]

Why overload when you can use class methods?

 

[Peter Otten]

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.

Peter

 

[Nicolas Fleury]

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 = myVeryLongNameColour
c.red = 0; c.blue = 255; c.green = 0

Regards,
Nicolas

 

[Mandus]

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

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

I do.

 

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

 

[Robert Kern]

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
(e-mail address removed)

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

 

[Peter Otten]

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

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