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 :)

[Konstantin Veretennicov]

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.

- kv

[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

[Steven D'Aprano]

On Fri, 24 Jun 2005 15:47:45 -0700, James Stroud wrote:

On Friday 24 June 2005 05:58 am, Steven D'Aprano wrote:

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.
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.__clas s__.myattribute
# set an instance attribute
myobject.widget .datapoints[myobject.collec tor] \
= myobject.dispat cher(myobject.w idget.current_v alue)

you might do this:

with myobject:
# read a class attribute
print .__class__.myat tribute
# set an instance attribute
.widget.datapoi nts[.collector] = .dispatcher(.wi dget.current_va lue)
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.

[Steven D'Aprano]

On Fri, 24 Jun 2005 14:29:37 -0700, James wrote:

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

[Konstantin Veretennicov]

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

On Fri, 24 Jun 2005 14:29:37 -0700, James wrote:

2.) Contracts

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]

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

--
Steve.

[Tom Anderson]

On Fri, 24 Jun 2005, Roy Smith wrote:

Tom Anderson <tw**@urchin.ea rth.li> wrote:

The one thing i really do miss is method overloading by parameter type.
I used this all the time in java
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.

No, it's not really possible in a typeless language,

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

--
Why do we do it? - Exactly!

[Konstantin Veretennicov]

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

[Tom Anderson]

On Sat, 25 Jun 2005, 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 :)

from __grumpy_old_ba stard_who_cant_ keep_up__ import map

:)

tom

--
Why do we do it? - Exactly!

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

Peter