Favorite non-python language trick?

[Tom Anderson]

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.

The one thing i really do miss is method overloading by parameter type. I
used this all the time in java, and it really notice the lack of it
sometimes in python. No, it's not really possible in a typeless language,
and yes, there are implementations based on decorators, but frankly,
they're awful.

Yeah, and i'm with "if False:" for commenting out chunks of code.

tom

 

[Roy Smith]

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 like Java and C++
because you have to. Can you give an example of where you miss it in
Python?

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.

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.

 

[D H]

You do things like that in type-bondage languages like Java and C++
because you have to. Can you give an example of where you miss it in
Python?

Well it's coming to a future Python version, so apparently there are
many who can use it:
http://wiki.python.org/moin/Python3.0Suggestions#head-7df9d7035174644fdae024ed4a5ea0960a003ef5
I don't know if you'll have method overloading, but there will be type
checking. It's not actually compile-time "static typing" though. The
type checking still happens at run-time similar to your isinstance
example, making code run slightly slower than a normal python method:
"Type checking is going to slow down your code." -GVR 2005 keynote,
http://www.sauria.com/~twl/conferences/pycon2005/20050324/The State of Python.html

 

[George Sakkis]

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

 

[Jeffrey Maitland]

1 trick I liked in C++ was for For loops.

{
for(int i = 0; i < 100; i++){
//do stuff
}
}

wrapping the for loop in { } makes the i a local variable and then you
can use it again in the code if not you will get a variable already
defined error.

As a side note python already keeps it a local variable, as most of us
know, and even if it did we can redifne it if we needed with ease.

Jeff

 

[Torsten Bronger]

Hallöchen!

[...]

{
for(int i = 0; i < 100; i++){
//do stuff
}
}

wrapping the for loop in { } makes the i a local variable

It's local anyway.

and then you can use it again in the code if not you will get a
variable already defined error.

Only in compilers created by this infamous company.

Tschö,
Torsten.

 

[Terry Reedy]

Roy Smith wrote:

Well it's coming to a future Python version,

The 'it' under discussion is 'method overloading by parameter type'. While
a few people have requested it, I have seen no indication that 'it' is
coming. I do not see even a mention of it in either page you referenced.

http://wiki.python.org/moin/Python3.0Suggestions#head-7df9d7035174644fdae024ed4a5ea0960a003ef5

I don't know if you'll have method overloading, but there will be type
checking.

Perhaps, though Guido has concerns about the issue.

"Type checking is going to slow down your code." -GVR 2005 keynote,
http://www.sauria.com/~twl/conferences/pycon2005/20050324/The State of Python.html

You left out " NOTE: Nothing's settled yet!!!!!!!!!!!!!!!!" and "
Reminder and Disclaimer
Nothing's settled yet!!!!!

Terry J. Reedy

 

[Terry Reedy]

sometimes in python. No, it's not really possible in a typeless language,
and yes, there are implementations based on decorators, but frankly,
they're awful.

Python has strongly typed objects. Only names are typeless.

Terry J. Reedy

 

[D H]

The 'it' under discussion is 'method overloading by parameter type'. While
a few people have requested it, I have seen no indication that 'it' is
coming.

Did you not see the very next sentence I wrote which exactly clarified
my point that I was referring to type checking and not method
overloading? Way to quote me out of context. Type checking IS coming
to python in all likelihood ->

>
>
> You left out " NOTE: Nothing's settled yet!!!!!!!!!!!!!!!!" and "
> Reminder and Disclaimer
> Nothing's settled yet!!!!!

I also left out the dozens of angry rants that people wrote after Guido
first proposed static typing, leading him to change the proposal to
runtime type checking, which by definition will slow down the code.
Static typing is almost certainly not going to come to Python, but the
typing annotations ("def method(x : int) -> bool") can be used by other
tools perhaps to do optimizations at compile time.

 

[D H]

Python has strongly typed objects. Only names are typeless.

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.

 

[Ron Adam]

:




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

 

[James]

Interesting thread ...

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

2.) Contracts

3.) With

 

[John Machin]

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]

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]

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]

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

colour = color
centre = center
# etc etc

 

[William Heymann]

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:

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.

 

[Robert Kern]

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

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

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