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

[Enrico]

"Joseph Garvin" <k0*****@kzoo.edu> ha scritto nel messaggio
news:ma**************************************@pyth on.org...

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

python:

"""
print 10
"""

and

#"""
print 10
#"""

C++:

/*
print(10);
*/

and

///*
print(10);
//*/

?

Bye,
Enrico

[Uwe Mayer]

Friday 24 June 2005 09:18 am Enrico wrote:

[...]

--This code will, because the first two dashes make the rest a comment,
breaking the block
---[[
print(10)
--]]

[...]
python:

"""
print 10
"""

and

#"""
print 10
#"""

C++:

/*
print(10);
*/

and

///*
print(10);
//*/

?

I think the *trick* here was that if you had larger blocks you'd only have
to change one side of the comment, i.e. the opening line, to de-comment the
block without searching the end of it and commenting that out aswell.

Ciao
Uwe

[gatti]

Joseph Garvin wrote:

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

Duff's device is a classic masterpiece of lateral thinking.
It is not possible in Python for many fundamental reasons, we are not
at risk.

Lorenzo Gatti

[Duncan Booth]

Uwe Mayer wrote:

/*
print(10);
*/

and

///*
print(10);
//*/

?
I think the *trick* here was that if you had larger blocks you'd only
have to change one side of the comment, i.e. the opening line, to
de-comment the block without searching the end of it and commenting
that out aswell.

Yes, but you can do that easily in C++ as well:

/*
print(10);
//*/

Change to:

//*
print(10);
//*/

I can't remember the exact pattern, but I remember using a
similar trick in BCPL where at least there was the excuse of not
otherwise having conditional compilation. C and C++ there is no excuse
for such tricks.

Google found Clive Feather's description of the BCPL trick at
http://www.lysator.liu.se/c/clive-on-history.html:
I doubt it (though DMR may contradict me, of course). Every compiler
I remember using allowed both // and /* */ type comment delimiters.
Some also allowed | and \ to be used instead of /, so that || was also
a comment-to-end-of-line, and \* ... *\ was an alternate block comment
symbol. The latter was particularly useful, because it could be used
to comment out blocks of code that included /* ... */ comments (as
with C, comments do not nest). We used comments with vertical bars to
implement a variety of conditional compilation:

|**||| IF
normal code
|*|||| ELSE
alternate code
|*|||| CANCEL ELSE
more normal code
|*|||| ELSE
more alternate code
|**||| ENDIF

By default, this would compile the "normal code". To switch to the
"alternate code", the first line was changed to |**||* or |*||||
instead. Because this comment symbol was used, the code could contain
normal comments and the "commenting-out" reverse comments I described
above.

[Lowell Kirsh]

Check out lisp macros. Other languages have macro systems but none
compare in power to lisp's. They are so powerful in lisp because lisp is
the only language where the source code closely resembles its parse tree
(created within the compiler/interpreter).

Lowell

Joseph Garvin wrote:

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

[Roel Schroeven]

Joseph Garvin wrote:

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

This syntax lets you do a nifty trick, where you can add or subtract a
third dash to change whether or not code runs:

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

Off topic, but in C or C++ it's easier to do it using

#ifdef 1
....
#endif

Then you just have to change the 1 into 0 or vice versa. It also
prevents problems with nested comments.

Back on topic, the lack of such a construct in Python is actually one of
the very few things that bother me in the language. There are
work-arounds, of course; idle, for example, has a feature that prepends
a # to every line in the selection, or removes the # again. But not all
editors have such a feature, and even if they have it I still need to
select the block of code every time. Not that big a deal though.

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

Roel Schroeven

[Claudio Grondi]

> And you can do block comments with --[[ and ---]].

I am very happy not to have such "tricks" in Python.

Any other (useful) suggestions?

Claudio

"Joseph Garvin" <k0*****@kzoo.edu> schrieb im Newsbeitrag
news:ma**************************************@pyth on.org...

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

[Joseph Garvin]

Claudio Grondi wrote:

And you can do block comments with --[[ and ---]].
I am very happy not to have such "tricks" in Python.

Any other (useful) suggestions?

Claudio

I'm glad and all that not everyone shares my enthusiasm over Lua's
trick, and I'm glad that C/C++ can do it, but the original issue was
non-python language tricks in general. Lets keep the thread on track.

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?

Yeesh.

"Joseph Garvin" <k0*****@kzoo.edu> schrieb im Newsbeitrag
news:ma**************************************@pyt hon.org...

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

[Thomas Guettler]

Am Fri, 24 Jun 2005 00:55:38 -0600 schrieb 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: [cut] This syntax lets you do a nifty trick, where you can add or subtract a
third dash to change whether or not code runs:

I do it this way:

if 0: # Just for testing
print value
.....

You only need to change "if 0" to "if 1" and the code gets executed.

Thomas

--
Thomas Güttler, http://www.thomas-guettler.de/

[Steven D'Aprano]

On Fri, 24 Jun 2005 00:55:38 -0600, Joseph Garvin wrote:

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

Long ago, I used to dabble in Forth. You could say, the entire Forth
language was a trick :-) It was interesting to be able to define your own
compiler commands, loop constructs and so forth.

One of the things I liked in Pascal was the "with" keyword. You could
write something like this:

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

[Claudio Grondi]

I supose it will be very, very hard to find a trick
which turns out useful in Python. The current
set of features is from my point of view very
well designed out of the experience with many
other languages, so maybe you can use Python
as reference telling you which tricks are really
useful in programming and which are just bad,
non-Pythonic style.

At least I am myself out of ideas, else I had
proposed a PEP already, to get it or have
provided a module for it.

So feel free to poke around with Python.

if(not \
"--[[" == "--[["):
# block of code
# --]]
as (already suggested) will also do the
trick with the block comment.

By the way, I personally find
--[[
good style comment block
]]--
or
[[--
good style comment block
--]]
much more intuitive than
--[[
bad style comment block
--]]

Claudio
"Joseph Garvin" <k0*****@kzoo.edu> schrieb im Newsbeitrag
news:ma**************************************@pyth on.org...

Claudio Grondi wrote:

And you can do block comments with --[[ and ---]].

I am very happy not to have such "tricks" in Python.

Any other (useful) suggestions?

Claudio

I'm glad and all that not everyone shares my enthusiasm over Lua's
trick, and I'm glad that C/C++ can do it, but the original issue was
non-python language tricks in general. Lets keep the thread on track.

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?

Yeesh.

"Joseph Garvin" <k0*****@kzoo.edu> schrieb im Newsbeitrag
news:ma**************************************@pyt hon.org...

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

[utabintarbo]

>with colour do begin

red := 0; blue := 255; green := 0;
end;

instead of:

colour.red := 0; colour.blue := 255; colour.green := 0;

Why not:

from color import *

red := 0
blue := 255
green := 0

....

[Steven D'Aprano]

On Fri, 24 Jun 2005 06:13:00 -0700, utabintarbo wrote:

with colour do begin
red := 0; blue := 255; green := 0;
end;

instead of:

colour.red := 0; colour.blue := 255; colour.green := 0;

Why not:

from color import *

red := 0
blue := 255
green := 0

Because colour is not a module, it is a record. Sorry, I assumed that
people would be familiar with Pascal records (similar to C structs) and
it wouldn't need explanation. My bad :-(

The closest example in Python would be:

def class Colour:
def __init__(self, blue=0, green=0, red=0):
self.blue = blue
self.green = green
self.red = red

which would become something like:

def class Colour:
def __init__(self, blue=0, green=0, red=0):
# pseudo-Python code borrowing concept "with" from Pascal
with self:
blue = blue
green = green
red = red

And now you can see why Python doesn't support this idiom.

--
Steven.

[D H]

Joseph Garvin wrote:

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

You can try out new features yourself now using various python
extensions or descendants:
http://livelogix.net/logix/
- macros, no statement/expression distinction
http://students.ceid.upatras.gr/~sxanth/pyc/
- assignments are expressions, you can try other features never added
python like a ternary operator (x ? true action:false action)
http://boo.codehaus.org/
assignments are expressions, macros, static typing, no more "self"
required, ...

[Peter Hansen]

ut*********@gmail.com wrote:

with colour do begin
red := 0; blue := 255; green := 0;
end;

instead of:

colour.red := 0; colour.blue := 255; colour.green := 0;

Why not:
from color import *

red := 0
blue := 255
green := 0

What do you think this actually does?

It doesn't do anything remotely resembling either of the things quoted
above. In fact, the "from color import *" line is pretty much useless here.

-Peter

[Doug Schwarz]

In article <Us********************@news3.tin.it>,
"Enrico" <lu*@perpetua.org> wrote:

"Joseph Garvin" <k0*****@kzoo.edu> ha scritto nel messaggio
news:ma**************************************@pyth on.org...

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

python:

"""
print 10
"""

and

#"""
print 10
#"""

It seems to me that this trick works in Python,too.

"""
print 10
#"""

and

#"""
print 10
#"""
You only have to change the first triple quote.

--
Doug Schwarz
dmschwarz&urgrad,rochester,edu
Make obvious changes to get real email address.

[infidel]

> def class Colour:

def __init__(self, blue=0, green=0, red=0):
# pseudo-Python code borrowing concept "with" from Pascal
with self:
blue = blue
green = green
red = red

And now you can see why Python doesn't support this idiom.

Maybe it would make more sense if it was done a la Visual Basic

with self:
.blue = blue
.green = green
.red = red

requiring a dot to be typed removes the ambiguity and gives the IDEs a
chance to Intellisense-ify your coding.

[D H]

infidel wrote:

def class Colour:
def __init__(self, blue=0, green=0, red=0):
# pseudo-Python code borrowing concept "with" from Pascal
with self:
blue = blue
green = green
red = red

And now you can see why Python doesn't support this idiom.

Maybe it would make more sense if it was done a la Visual Basic

with self:
.blue = blue
.green = green
.red = red

requiring a dot to be typed removes the ambiguity and gives the IDEs a
chance to Intellisense-ify your coding.

Some made a python recipe emulating this I believe. The python cookbook
search engine is down though so I cannot find the link.
At one point Guido van Rossum was advocating this use of "with" as well,
I believe:
http://mail.python.org/pipermail/pyt...ch/043545.html

But I don't think it is being considered now. I think now "with" is
being proposed for something more like VB and C#'s "using" statement.
It automatically disposes of a resource when done with it:
http://wiki.python.org/moin/WithStatement

[Sergei Organov]

Steven D'Aprano <st***@REMOVETHIScyber.com.au> writes:

On Fri, 24 Jun 2005 00:55:38 -0600, Joseph Garvin wrote:

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

Long ago, I used to dabble in Forth. You could say, the entire Forth
language was a trick :-) It was interesting to be able to define your own
compiler commands, loop constructs and so forth.

One of the things I liked in Pascal was the "with" keyword. You could
write something like this:

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.

.... that quickly becomes quite messy:

with A do begin
.....
with B do begin
.....
with C do begin
x := y;
end;
end;
end;

.... and now you need to check the declarations of C, B, and A to
actually see what is assigned to what.

Worse yet, adding field 'x' to 'C' will (silently) break the code :(

I don't think it would be that nice to have it in Python.

--
Sergei.

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

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

--
.... but when you spin it it looks like a dancing foetus!

[Roy Smith]

Tom Anderson <tw**@urchin.earth.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 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]

Roy Smith wrote:

Tom Anderson <tw**@urchin.earth.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 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....5ea0960a003ef5
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/%7Etwl/confere...%20Python.html

[George Sakkis]

"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

[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

On 6/24/05, D H <d@e.f> wrote:

Roy Smith wrote:

Tom Anderson <tw**@urchin.earth.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 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....5ea0960a003ef5
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/%7Etwl/confere...%20Python.html
--
http://mail.python.org/mailman/listinfo/python-list

[Torsten Bronger]

Hallöchen!

Jeffrey Maitland <je***********@gmail.com> writes:

[...]

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

--
Torsten Bronger, aquisgrana, europa vetus

[Terry Reedy]

"D H" <d@e.f> wrote in message

Roy Smith wrote:

Tom Anderson <tw**@urchin.earth.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 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,

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....5ea0960a003ef5 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/%7Etwl/confere...%20Python.html

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

Terry J. Reedy

[Terry Reedy]

"Tom Anderson" <tw**@urchin.earth.li> wrote in message
news:Pi*******************************@urchin.eart h.li...

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]

Terry Reedy wrote:

"D H" <d@e.f> wrote in message

Roy Smith wrote:

Tom Anderson <tw**@urchin.earth.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 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,

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

I don't know if you'll have method overloading, but there will be type
checking.
"Type checking is going to slow down your code." -GVR 2005 keynote,
http://www.sauria.com/%7Etwl/confere...%20Python.html

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]

Terry Reedy wrote:

"Tom Anderson" <tw**@urchin.earth.li> wrote in message
news:Pi*******************************@urchin.eart h.li...

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.

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.

[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

[Konstantin Veretennicov]

On 6/25/05, Mandus <ma****@gmail.com> 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.__class__.myattribute
# set an instance attribute
myobject.widget.datapoints[myobject.collector] \
= myobject.dispatcher(myobject.widget.current_value)

you might do this:

with myobject:
# read a class attribute
print .__class__.myattribute
# set an instance attribute
.widget.datapoints[.collector] = .dispatcher(.widget.current_value)
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***@removethiscyber.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.com> 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.earth.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***@removethiscyber.com.au> wrote:

On Sat, 25 Jun 2005 17:41:58 +0200, Konstantin Veretennicov wrote:

On 6/25/05, Mandus <ma****@gmail.com> 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.com> 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_bastard_who_cant_keep_up__ import map

:)

tom

--
Why do we do it? - Exactly!

[George Sakkis]

"Konstantin Veretennicov" <kv***********@gmail.com> wrote:

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

On Sat, 25 Jun 2005 17:41:58 +0200, Konstantin Veretennicov wrote:

On 6/25/05, Mandus <ma****@gmail.com> 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

If they go to itertools, they can simply be:

def map(f, *iterables):
return list(imap(f,*iterables))

def filter(f, seq):
return list(ifilter(f,seq))

George