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

Oops ! I've used filter only with lists and didn't know that it
preserves the type for strings and tuples. Here's a (hopefully) correct
version:

def filter(f,seq):
it = ifilter(f,seq)
if isinstance(seq, basestring):
return ''.join(it)
elif isinstance(seq, tuple):
return tuple(it)
else:
return list(it)
By the way, the documentation of filter is unclear on what is the
return type if seq is a subclass of list, tuple, str, or unicode; is it
type(seq) or the base builtin type ? Let's see:

def subclassFactory (cls):
return type("Dummy_" + cls.__name__, (cls,),
{'__new__' : lambda self, seq: cls.__new__(sel f, seq)})

baseToSub = dict([(base,subclassF actory(base))
for base in list,tuple,str, unicode])

f = lambda x: x.lower()
for Base,Sub in baseToSub.iteri tems():
assert type(__builtins __.filter(f, Sub('lowerUPPER Cap'))) is Base

for Base,Sub in baseToSub.iteri tems():
for cls in Base,Sub:
args = (f, cls('lowerUPPER Cap'))
assert filter(*args) == __builtins__.fi lter(*args)
George

[GodFoca]

> I'm curious -- what is everyone's favorite trick from a non-python

language? And -- why isn't it in Python?

Hmm... I used to be quite the fan of Python, yet not long ago I met
Ruby and fell in love almost instantly. Some of the features I like the
most:

- statement modifiers:

< "return a if a.value == true"
< "database.query (q) unless database.connec t == error
(etc)

- unless as "if not", since it gives nicer code to read

< unless false then print 1 # this prints 1 forever

- iterators, such as times (already mentioned)

- 'case'

< case var
< when 3 then do_sth
< when 4 then do_sth_else
< # etc...
< end

- everything returns a value, so you can do:

< foo = case foo2
< when 1 then yadda_yadda
< when 2 then blah_blah
< # etc
< end

And when foo2 == 2 then "blah_blah" gets executed and returned as the
'case' return value, thus assigning foo the value that results from
evaluating blah_blah

And some more, but those are the ones I like the best and python
doesn't have :-)

- greetings -
Nicolas

[Devan L]

< "return a if a.value == true"
< "database.query (q) unless database.connec t == error
(etc)

if a.value == True:
return a

if not database.connec t == error:
database.query( q)

Trading two words for one word doesn't necessarily make the code
better.

< unless false then print 1 # this prints 1 forever
while not False:
print 1

"unless" seems to become "while not", as opposed to "if not". Should be
more consistent.

[Bengt Richter]

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

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

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.

Point taken.
I understand how to manipulate __dict__ as an more complicated (dare I say
obfuscated?) way of assigning to object attributes.
Yes, it's a bit obfuscated.
[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 wouldn't do something unfortunate, would you? ;-)
I just wanted to clear them all at that point in the interaction.
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?

The only thing, ISTM, that would not also be unique in the with construct
is the function name, and you snipped the anonymnous def version that would
eliminate that. The main question in my mind would be binding of non-leading-dot
names. Would they work as in the suite of an "if" (i.e., binding in the same scope)
or as in a function with a new local scope that disappears on exit?

A function solves the alias name pollution problem, but prevents rebinding
anything external except explicitly declared globals, and closure cell vars
can't be rebound currently.
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.

I wonder what happens when you have multiple withs, e.g.,

with obj_a:
.x = 1
with obj_b:
.x = 2
.y = 3

(I guess you would have to have a stack with only the latest with effective).
whereas a simple aliasing syntax like

(a=obj_a, b=obj_b):
a.x = 1
b.x = 2
b.y = 3

is unambigous and concise and the scope of the namescan be limited
to prevent name pollution at compile time.

OTOH, what should
(a=obj_a):
a = 123 # XXX ??
mean? Should it mean obj_a=123 and rebind in that scope,
like a macro substitution of names at compile time?
I guess the corresponding with thing would be
with obj_a:
. = 123


Regards,
Bengt Richter

[Bengt Richter]

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

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 oops, for below example, needs global declaration
def foo():
global x
x:=123 #note that x:=123 searches outward through nested scopes,
#not including globals unless explicitly declared, whereas
# x=456 would always {re}bind the global x, as usual with a global x declared.
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 oops, not so, unless foo has correction above 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?

I forgot some of my previous thoughts on this. It's not as wild as it appears ;-)

I forgot to mention that of course a symbol found in __builtins__ by way
of the usual default lookup should not be rebound. And only globals explicitly
declared should be rebound (error in code above, since foo doesn't have global x).
So that limits it to the local scope and nested scopes and declared globals not
preempted by nearer nested scope variable names.

This is motivated by currently not being able to rebind a closure variable in
a nested scope, and the requirement of pre-existence within a limited range of
namespaces that can (I think ;-) be statically analyzed for is meant to prevent
new accidental collision problems.

Regards,
Bengt Richter

[Terry Hancock]

On Sunday 26 June 2005 06:11 am, Robert Kern wrote:

Terry Hancock wrote:

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

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

You need to differentiate
a = b = 1
from
a = b == 1

Okay, I see what you mean. I can't ever recall having needed the
second form, though.

Of course, you could still do assignment like this:

a, b = (1,)*2

But I guess that's not exactly elegant. ;-)

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

[Robert Kern]

Terry Hancock wrote:

On Sunday 26 June 2005 06:11 am, Robert Kern wrote:

Terry Hancock wrote:

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

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

Okay, I see what you mean. I can't ever recall having needed the
second form, though.

I use it all the time with Numeric's rich comparisons.

mask = some_arr == 999
Of course, you could still do assignment like this:

a, b = (1,)*2

But I guess that's not exactly elegant. ;-)

Ya think? :-)

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

[Steven D'Aprano]

On Sun, 26 Jun 2005 23:22:00 -0500, Terry Hancock wrote:

You need to differentiate
a = b = 1
from
a = b == 1

Okay, I see what you mean. I can't ever recall having needed the
second form, though.

Of course, you could still do assignment like this:

a, b = (1,)*2

But I guess that's not exactly elegant. ;-)

In general that is not the same thing as a = b = obj.

py> a, b = ([], [])
py> a.append(1)
py> b
[]
py> a = b = []
py> a.append(1)
py> b
[1]
--
Steven.

[Robert Kern]

Steven D'Aprano wrote:

On Sun, 26 Jun 2005 23:22:00 -0500, Terry Hancock wrote:

You need to differentiate
a = b = 1
from
a = b == 1

Okay, I see what you mean. I can't ever recall having needed the
second form, though.

Of course, you could still do assignment like this:

a, b = (1,)*2

But I guess that's not exactly elegant. ;-)

In general that is not the same thing as a = b = obj.

py> a, b = ([], [])
py> a.append(1)
py> b
[]
py> a = b = []
py> a.append(1)
py> b
[1]

What you wrote isn't, but what Terry wrote is.

In [1]: a, b = ([],)*2

In [2]: a.append(1)

In [3]: b
Out[3]: [1]

In [4]: a is b
Out[4]: True

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

[Tim Peters]

[Terry Hancock]

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.

That's what Python originally did, before release 0.9.6 (search
Misc/HISTORY for eqfix.py). Even this is ambigous then:

a = b

Especially at an interactive prompt, it's wholly ambiguous then
whether you want to change a's binding, or want to know whether a and
b compare equal.

Just yesterday, I wrote this in a script:

lastinline = ci == ncs - 1

This:

lastinline = ci = ncs - 1

means something very different (or means something identical,
depending on exactly how it is Python "could easily figure out" what I
intended <wink>).

Of course strange rules could have resolved this, like, say, "=" means
assignment, unless that would give a syntax error, and then "=" means
equality. Then

lastinline = ci = ncs - 1

would have been chained assignment, and something like

lastinline = (ci = ncs - 1)

would have been needed to get the intent of the current

lastinline = ci == ncs - 1