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

[James]

Interesting thread ...

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

2.) Contracts

3.) With

[Ron Adam]

George Sakkis wrote:

"Joseph Garvin" wrote:

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

Although it's an optimization rather than language trick, I like the
inline functions/methods in C++. There has been a thread on that in the
past (http://tinyurl.com/8ljv5) and most consider it as useless and/or
very hard to implement in python without major changes in the language
(mainly because it would introduce 'compile-time' lookup of callables
instead of runtime, as it is now). Still it might be useful to have for
time-critical situations, assuming that other optimization solutions
(psyco, pyrex, weave) are not applicable.

George

Thanks for the link George, It was interesting.

I think some sort of inline or deferred local statement would be useful
also. It would serve as a limited lambda (after it's removed), eval
alternative, and as a inlined function in some situations as well I think.

Something like:

name = defer <expression>

then used as:

result = name()

The expression name() will never have arguments as it's meant to
reference it's variables as locals and probably will be replaced
directly with names's byte code contents at compile time.

Defer could be shortened to def I suppose, but I think defer would be
clearer. Anyway, it's only a wish list item for now.

Regards,
Ron

[John Machin]

James wrote:

Interesting thread ...

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

Did you mean 1..9 or 1...10 or both or neither?

Can this construct be used like this: (i+1)..n ? If not, what would you
use? What is the frequency of range literals in the average piece of code?

[Steve Horsley]

Neat.
Thank Goodness for syntax-colouring editors!

Steve

[johng2001]

John Machin wrote:

James wrote:

Interesting thread ...

1.) Language support for ranges as in Ada/Pascal/Ruby
1..10 rather than range(1, 10)
Did you mean 1..9 or 1...10 or both or neither?

You are right. There is a difference.
1..10 == range(1, 10 + 1)
Can this construct be used like this: (i+1)..n ? If not, what would you
use?
Sure. In Ruby, you can do

i = 2
n = 5
for x in (i+1)..n do
print x
end

Can't in Ada/Pascal as far as I remember.
What is the frequency of range literals in the average piece of code?

Well! I certainly have not done a study with code metrics. You probably
can find something online. That probably will be variable and might
depend on individual language affordances.

BTW, Ruby's times loop is another thing I find better readable for a
few cases.

4.times {
print "Something ..."
}

than

for x in range(4):
print "Something ..."

[James Stroud]

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

Less typing than pascal. Also avoids those stupid little colons.

--
James Stroud
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095

http://www.jamesstroud.com/

[John Machin]

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

colour = color
centre = center
# etc etc
Less typing than pascal. Also avoids those stupid little colons.

[William Heymann]

On Friday 24 June 2005 02:53 pm, D H wrote:

Again, you are splitting hairs. His point still stands that it is not
possible to do method overloading in python (unless you use decorator
hacks). It may be possible to add this feature when type declarations
and type checking are added to a future version of python.

Decorators are actually a syntax hack remember. Everything you can do in a
decorator you could do with python before since they work via nested scopes.
It is easy to write wrapper methods and I use them for many purposes but not
for type checking.

Wrapper methods are very useful to take out common checking code. The checking
of conditions does not really belong in the caller (the caller could forget),
it does not really belong in the called function since that is not that
functions purpose but putting it in a wrapper and having it wrap the called
function sure gives a nice seperation and makes life simpler.

[Mandus]

Fri, 24 Jun 2005 16:31:08 +0100 skrev Tom Anderson:

On Fri, 24 Jun 2005, Joseph Garvin wrote:

Claudio Grondi wrote:

So far we've got lisp macros and a thousand response's to the lua trick.
Anyone else have any actual non-python language tricks they like?

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.

u-huu... I wasn't aware of that. 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 :(

Sure, I guess I can port most of it to list comprehensions, but
reduce/map are so much nicer.
--
Mandus - the only mandus around.

[Robert Kern]

Mandus wrote:

Fri, 24 Jun 2005 16:31:08 +0100 skrev Tom Anderson:

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.

u-huu... I wasn't aware of that. 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 :(

Python 3000 (or Python 3.0) is the designated "we're going to break
backwards compatibility" release. Your code won't necessarily work even
if map, filter, and reduce are kept.

Guido's current plans, such as they are, with links to his reasoning can
be found here:

http://www.python.org/peps/pep-3000.html
http://wiki.python.org/moin/Python3.0

Of course, there's no timetable for when this change will take place.
map, filter, and reduce are safe for quite some time.

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