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

[Steven D'Aprano]

On Sat, 25 Jun 2005 23:08:10 +0000, Bengt Richter wrote:

On Sun, 26 Jun 2005 04:08:31 +1000, Steven D'Aprano <st***@REMOVETH IScyber.com.au> wrote:

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.
How do you like the following? >>> color = type('',(),{})( ) # an instance that will accept attributes
>>> vars(color) {}

The single line replacing
"""
with colour do begin
red := 0; blue := 255; green := 0;
end;
"""
follows: >>> vars(color).upd ate(red=0, blue=255, green=0)

The point is that a hypothetical "with" block would have to allow
arbitrary access to dotted names: getting, setting, deletion, and method
calling, not just one very limited form of keyword assignment.

I understand how to manipulate __dict__ as an more complicated (dare I say
obfuscated?) way of assigning to object attributes.
[snip]

We can clear those attributes from the instance dict: vars(colour).cl ear()
vars(colour) {}
Which has the unfortunate side effect of also destroying any other
instance attributes.

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)

def mywith(o=myobje ct):
# read a class attribute
print o.__class__.mya ttribute
# set an instance attribute
o.widget.datapo ints[o.collector] = o.dispatcher(o. widget.current_ value)
mywith()

[snip]
Is a one-character prefix to the dot objectionable?

That's a good workaround, subject to namespace pollution issues, and one
that I'm aware of. Although do you really want to be creating a unique
function definition every time you want to use the with idiom?

I'm not about to stop using Python because of the lack of Pascal-like
"with" blocks. It is a nice feature to have, but I'm aware that Guido
prefers explicit to implicit and "with" is extremely implicit.

--
Steven.

[Steven D'Aprano]

On Sat, 25 Jun 2005 23:08:10 +0000, Bengt Richter wrote:

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?

I agree, but I think := would be nice in python for RE-binding an existing
binding, wherever it is seen from the local context. Thus you could
write

def foo(): x:=123

and
x = 456
def bar():
x = 789
foo() # finds and rebinds local x
print x
bar() # -> 123
print x # -> 456
foo() # finds and rebinds the global x
print x # -> 123

but
del x
foo() #-> NameError exception, can't find any x to rebind

hm, wandered a bit OT there, ;-/

Given how much the use of global variables are discouraged, is it a
good idea to allow even more inter-namespace interactions?
--
Steven.

[Peter Otten]

Steven D'Aprano wrote:

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

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.

Good grief! You've been spying on Mandus! How else could you possibly know
that he doesn't measure performance? Are you running a key-logger on his
machine? *wink*

His mentioning reduce() as a performance panacea was a strong indication
even without looking over his shoulders. He filled in some conditions in a
later post, but "[u]sing reduce ... performs better [than a for-loop]" is
just wrong.
For the record, perhaps now is a good time to mention that even Guido
recommended the use of map, filter and reduce in some circumstances:
Personally I wouldn't rely on authority when I can measure without much
hassle. And the lesson I take from Guido's essay is rather how he got to
his conclusions than what his actual findings were. After all, Python may
have advanced a bit since he wrote the text.
Do we really need to profile our code every single time to know this?
No. Only if we care about the performance of a particular piece. And if we
do we are sometimes in for a surprise.
Isn't it reasonable to just say, "I use join because it is faster than
adding strings" without being abused for invalid optimization?

OK, I am making a guess: "".join(strings ) is more often faster than
naive string addition than reduce() wins over a for-loop.

I don't think my pointed comment qualifies as "abuse", by the way.

Peter

[Konstantin Veretennicov]

On 25 Jun 2005 12:17:20 -0700, George Sakkis <gs*****@rutger s.edu> wrote:

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

from itertools import ifilter
def filter(f, seq): .... return list(ifilter(f, seq)) filter(str.isal pha, 'not quite!') ['n', 'o', 't', 'q', 'u', 'i', 't', 'e'] __builtins__.fi lter(str.isalph a, 'not quite!')

'notquite'

- kv

[Terry Hancock]

On Saturday 25 June 2005 01:08 pm, Steven D'Aprano wrote:

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?

Probably the most pointless Python wart, I would think. The =/==
distinction makes sense in C, but since Python doesn't allow assignments
in expressions, I don't think there is any situation in which the distinction
is needed. Python could easily figure out whether you meant assignment
or equality from the context, just like the programmer does.

BASIC did it that way, IIRC. It always seemed like C was seriously twisted
for letting you get away with assignment in expressions in the first place.

I don't think Python's use of "==" has *ever* helped me find a bug, it
just creates them. I really think "=" ought to be accepted as well, and
"==" deprecated.

But, hey, nobody asked me, I guess. And it doesn't kill me to type the
extra "=". ;-)

Cheers,
Terry

--
Terry Hancock ( hancock at anansispacework s.com )
Anansi Spaceworks http://www.anansispaceworks.com

[Torsten Bronger]

Hallöchen!

Terry Hancock <ha*****@anansi spaceworks.com> writes:

[...]

BASIC did it that way, IIRC.
Right.
[...]

I don't think Python's use of "==" has *ever* helped me find a
bug, it just creates them. I really think "=" ought to be
accepted as well, and "==" deprecated.

However, then you must forbid a=b=1 for assigning to two variables
at the same time.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus

[Terry Hancock]

On Sunday 26 June 2005 05:39 am, Torsten Bronger wrote:

Hallöchen!
However, then you must forbid a=b=1 for assigning to two variables
at the same time.

Why? It's already handled as an exception in the syntax.

In C, what you say makes sense, because "b=1" is an expression as
well as an assignment. But I don't think Python reads it that way -- it
just has code to recognize multiple assignment as a statement. I think
I remember reading that in the Language Reference or something.

Cheers,
Terry

--
Terry Hancock ( hancock at anansispacework s.com )
Anansi Spaceworks http://www.anansispaceworks.com

[Robert Kern]

Terry Hancock wrote:

On Sunday 26 June 2005 05:39 am, Torsten Bronger wrote:

Hallöchen!
However, then you must forbid a=b=1 for assigning to two variables
at the same time.

Why? It's already handled as an exception in the syntax.

In C, what you say makes sense, because "b=1" is an expression as
well as an assignment. But I don't think Python reads it that way -- it
just has code to recognize multiple assignment as a statement. I think
I remember reading that in the Language Reference or something.

You need to differentiate

a = b = 1

from

a = b == 1

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

[Roel Schroeven]

Terry Hancock wrote:

On Saturday 25 June 2005 01:08 pm, Steven D'Aprano wrote:

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?

Probably the most pointless Python wart, I would think. The =/==
distinction makes sense in C, but since Python doesn't allow assignments
in expressions, I don't think there is any situation in which the distinction
is needed. Python could easily figure out whether you meant assignment
or equality from the context, just like the programmer does.

There are situations where Python can't figure it out:

a = 1
b = 2
f = a == b
print a, b, f 1 2 False f = a = b
print a, b, f

2 2 2

--
If I have been able to see further, it was only because I stood
on the shoulders of giants. -- Isaac Newton

Roel Schroeven

[Roy Smith]

Steven D'Aprano <st***@REMOVETH IScyber.com.au> wrote:

Using := and = for assignment and equality is precisely as stupid as using
= and == for assignment and equality.

On the other hand, == is easier to type than := (two taps on the same key
vs two different keys, and at least on a US/English keyboard, no shift key
required). Not only that, but := is more likely to be turned into some
bizarre smiley face by brain-dead IM clients :-)