RE: [Tutor] Are you allowed to shoot camels? [kinda OT]
Alan,
That's no good. You still get something printed out. In this case:
None
Jeff
-Original Message-
From: Alan Gauld [mailto:[EMAIL PROTECTED]
Sent: Monday, February 07, 2005 6:15 PM
To: Smith, Jeff; Bob Gailer; tutor@python.org
Subject: Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
That's actually worse than you might think. Try this:
def p(): pass
ftable = { 'a' : lambda: 'a',
'd' : lambda: p}
That should be:
'd': p}
ie No lambda used at all.
I wish Python had real lambdas!
And what you get is:
function p at 0x009BDFB0
Yep, coz the lambda returns a function object!
Which it should, I just shouldn't have used lambda there.
My bad,
Alan G.
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
RE: [Tutor] Are you allowed to shoot camels? [kinda OT]
Jeff,
It looks like that finally is the simplest expression of the original
switch statement:
import sys
def p():
pass
ftable = { 'a' : lambda: sys.stdout.write('a\n'),
'b' : lambda: sys.stdout.write('b or c\n'),
'c' : lambda: sys.stdout.write('b or c\n'),
'd' : p }
ftable.get(var, lambda: sys.stdout.write('default case\n'))()
I do note that it took this group of experienced programmers several
tries to impliment this simple switch statement without actually using
switch. I dare say with standard switch syntax we would've had it right
the first time :-)
Jeff
-Original Message-
From: Jeff Shannon [mailto:[EMAIL PROTECTED]
Sent: Monday, February 07, 2005 9:19 PM
To: tutor@python.org
Subject: Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
Alan Gauld wrote:
As an aside, I did try to create a lambda based solution but was
unable. Let me know what's wrong:
ftable = { 'a' : lambda: print 'a',
SyntaxError: invalid syntax
I did say if Python had *proper* lambdas...
Unfortunately Python insists on only having *expressions* as lambdas
and since print is a command not a function you can't use it in Python
lambdas! Dumb or what??!
So you are stuck with predefining a bunch of one liner functions and
then creating a dictionary or going back to if/elif chains, which is
where we came in... :-)
Well, in this particular case, if one really wants to use lambdas then
one could (after importing sys, of course) replace the print statement
with a call to sys.stdout.write() --
ftable = { 'a': lambda: sys.stdout.write('a\n'), ... }
Note that sys.stdout.write() will *not* automatically add the newline
that print does (which is why I've specified it in the above sample).
Indeed, print can do all sorts of odd things with whitespace,
leaving sys.stdout.write() as the best way to have real control over
your output anyhow...
Jeff Shannon
Technician/Programmer
Credit International
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
That's no good. You still get something printed out. In this case:
None
Of course, silly me, p will return the default value None, you need
to replace the pass with return '' or, I guess use the lambda...
ftable = { 'a' : lambda: 'a',...
'd' : lambda: ''}
Now it should work and is consistent again! But only for this
trivial case of printing a label...
Alan G.
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
RE: [Tutor] Are you allowed to shoot camels? [kinda OT]
Not to be nit-picky but it's still not the same. The switch would give
no output but yours would give a newline. I think the sys write
solution would be the closest equivalent...and took a lot longer for us
to code correctly :-)
Jeff
-Original Message-
From: Alan Gauld [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 08, 2005 1:24 PM
To: Smith, Jeff; Bob Gailer; tutor@python.org
Subject: Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
That's no good. You still get something printed out. In this case:
None
Of course, silly me, p will return the default value None, you need
to replace the pass with return '' or, I guess use the lambda...
ftable = { 'a' : lambda: 'a',...
'd' : lambda: ''}
Now it should work and is consistent again! But only for this
trivial case of printing a label...
Alan G.
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
Smith, Jeff wrote:
Jeff,
It looks like that finally is the simplest expression of the original
switch statement:
import sys
def p():
pass
ftable = { 'a' : lambda: sys.stdout.write('a\n'),
'b' : lambda: sys.stdout.write('b or c\n'),
'c' : lambda: sys.stdout.write('b or c\n'),
'd' : p }
ftable.get(var, lambda: sys.stdout.write('default case\n'))()
I do note that it took this group of experienced programmers several
tries to impliment this simple switch statement without actually using
switch. I dare say with standard switch syntax we would've had it right
the first time :-)
I wasn't following this thread all the way through, but to be honest,
I'd have solved this differently -- that may be the best direct
translation of some switch statement, but that doesn't mean it's the
best-fit solution here. ISTM that, given the desire to print some
text (or nothing) based on the contents of a variable, I would *not*
handle the output inside the switch -- that is, I'd (conditionally)
print a value from a string-containing dictionary, rather than use a
table of functions that print strings.
table = { 'a': 'a', 'b': 'b or c', 'c': 'b or c', 'd': None }
result = table.get(var, 'default case')
if result:
print result
This, to my mind, is much cleaner -- you're factoring out the repeated
code, whether print statement or call to sys.stdout.write(), reducing
the complexity of the dict. You're making flow control much more
straightforward. You're making the whole thing easier to read.
The key, here, is that instead of saying I want a switch, how can I
implement that in Python?, I've taken the approach of The end result
I want is ***; what tools does Python offer to achieve that? This
conceptual shift is, IMHO, *the* most important mental hurdle in
learning a [second/third/n-th] language.
Jeff Shannon
Technician/Programmer
Credit International
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
Not to be nit-picky but it's still not the same. The switch would give no output but yours would give a newline. I think the sys write solution would be the closest equivalent...and took a lot longer for us to code correctly :-) I can't really argue with that! :-) Me, I'm blaming the lambdas! Alan g. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
table = { 'a': 'a', 'b': 'b or c', 'c': 'b or c', 'd': None }
result = table.get(var, 'default case')
if result:
print result
This, to my mind, is much cleaner -- you're factoring out the
repeated
code, whether print statement or call to sys.stdout.write(),
reducing
the complexity of the dict. You're making flow control much more
straightforward. You're making the whole thing easier to read.
Yep, the lambda stuff etc is there on the assumption that we are
trying to do something a tad more interesting than just print the
label - but as it happens printing the label has been hard enough!!
:-)
Alan G.
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
RE: [Tutor] Are you allowed to shoot camels? [kinda OT]
At 07:14 AM 2/7/2005, Smith, Jeff wrote:
Alan,
No use beating this dead horse...I guess that's why there are so many
languages in the first place. Different people are comfortable with
different things. (I did warn you that I like both Lisp and Prolog and
only wish I had more of a reason to use them :-)
As an aside, I did try to create a lambda based solution but was unable.
Let me know what's wrong:
ftable = { 'a' : lambda: print 'a',
'b' : lambda: print 'b or c',
'c' : lambda: print 'b or c',
'd' : lambda: pass }
ftable.get(var, lambda: print 'default case')()
From the docs: lambda arguments: expression
print 'a' is not an expression
File C:\scratch\Script1.py, line 2
ftable = { 'a' : lambda: print 'a',
^
SyntaxError: invalid syntax
Bob Gailer
mailto:[EMAIL PROTECTED]
303 442 2625 home
720 938 2625 cell
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
RE: [Tutor] Are you allowed to shoot camels? [kinda OT]
That's kinda what I thought but a couple of people suggested that I used
lambdas to make it clearer that I figured I was doing something wrong...
Jeff
-Original Message-
From: Bob Gailer [mailto:[EMAIL PROTECTED]
Sent: Monday, February 07, 2005 9:48 AM
To: Smith, Jeff; tutor@python.org
Subject: RE: [Tutor] Are you allowed to shoot camels? [kinda OT]
At 07:14 AM 2/7/2005, Smith, Jeff wrote:
Alan,
No use beating this dead horse...I guess that's why there are so many
languages in the first place. Different people are comfortable with
different things. (I did warn you that I like both Lisp and Prolog and
only wish I had more of a reason to use them :-)
As an aside, I did try to create a lambda based solution but was
unable. Let me know what's wrong:
ftable = { 'a' : lambda: print 'a',
'b' : lambda: print 'b or c',
'c' : lambda: print 'b or c',
'd' : lambda: pass }
ftable.get(var, lambda: print 'default case')()
From the docs: lambda arguments: expression
print 'a' is not an expression
File C:\scratch\Script1.py, line 2
ftable = { 'a' : lambda: print 'a',
^
SyntaxError: invalid syntax
Bob Gailer
mailto:[EMAIL PROTECTED]
303 442 2625 home
720 938 2625 cell
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
RE: [Tutor] Are you allowed to shoot camels? [kinda OT]
At 07:43 AM 2/7/2005, Smith, Jeff wrote:
That's kinda what I thought but a couple of people suggested that I used
lambdas to make it clearer that I figured I was doing something wrong...
Well you can use lambdas. Have them return an expression which you print
after retrieving:
ftable = { 'a' : lambda: 'a',
'b' : lambda: 'b or c',
'c' : lambda: 'b or c',
'd' : lambda: ''}
print ftable.get(var, lambda: 'default case')()
But it would be clearer to store just the expressions:
ftable = { 'a' : 'a',
'b' : 'b or c',
'c' : 'b or c',
'd' : ''}
print ftable.get(var, 'default case')
Bob Gailer
mailto:[EMAIL PROTECTED]
303 442 2625 home
720 938 2625 cell
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
RE: [Tutor] Are you allowed to shoot camels? [kinda OT]
Bob,
Unfortunately, that doesn't do the same thing. In the 'd' case, you get
a print rather than a pass for instance. It was also just happenstance
that I chose to print on each switch rather than do something like
increment a counter.
Jeff
-Original Message-
From: Bob Gailer [mailto:[EMAIL PROTECTED]
Sent: Monday, February 07, 2005 10:10 AM
To: Smith, Jeff; tutor@python.org
Subject: RE: [Tutor] Are you allowed to shoot camels? [kinda OT]
At 07:43 AM 2/7/2005, Smith, Jeff wrote:
That's kinda what I thought but a couple of people suggested that I
used lambdas to make it clearer that I figured I was doing something
wrong...
Well you can use lambdas. Have them return an expression which you print
after retrieving:
ftable = { 'a' : lambda: 'a',
'b' : lambda: 'b or c',
'c' : lambda: 'b or c',
'd' : lambda: ''}
print ftable.get(var, lambda: 'default case')()
But it would be clearer to store just the expressions:
ftable = { 'a' : 'a',
'b' : 'b or c',
'c' : 'b or c',
'd' : ''}
print ftable.get(var, 'default case')
Bob Gailer
mailto:[EMAIL PROTECTED]
303 442 2625 home
720 938 2625 cell
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
Bob Gailer wrote:
At 07:14 AM 2/7/2005, Smith, Jeff wrote:
Alan,
No use beating this dead horse...I guess that's why there are so many
languages in the first place. Different people are comfortable with
different things. (I did warn you that I like both Lisp and Prolog and
only wish I had more of a reason to use them :-)
As an aside, I did try to create a lambda based solution but was unable.
Let me know what's wrong:
ftable = { 'a' : lambda: print 'a',
'b' : lambda: print 'b or c',
'c' : lambda: print 'b or c',
'd' : lambda: pass }
ftable.get(var, lambda: print 'default case')()
From the docs: lambda arguments: expression
print 'a' is not an expression
As a workaround to use print in a lambda you can use sys.stdout.write()
instead.
Kent
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
As an aside, I did try to create a lambda based solution but was
unable.
Let me know what's wrong:
ftable = { 'a' : lambda: print 'a',
SyntaxError: invalid syntax
I did say if Python had *proper* lambdas...
Unfortunately Python insists on only having *expressions* as
lambdas and since print is a command not a function you can't
use it in Python lambdas! Dumb or what??!
So you are stuck with predefining a bunch of one liner
functions and then creating a dictionary or going back
to if/elif chains, which is where we came in... :-)
HTH,
Alan G.
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
That's kinda what I thought but a couple of people suggested
that I used lambdas to make it clearer
I suggested that if we had proper lambdas we could use 'em...
But of course you can still use lambdas just put the print
at the client side:
def p(): pass
ftable = { 'a' : lambda: 'a',
'b' : lambda: 'b or c',
'c' : lambda: 'b or c',
'd' : lambda: p}
print ftable.get(var, lambda: 'default case')()
But I still had to use a def for the pass... :-(
Alan G.
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
Well you can use lambdas. Have them return an expression which you
print
after retrieving:
ftable = { 'a' : lambda: 'a',
'b' : lambda: 'b or c',
But it would be clearer to store just the expressions:
ftable = { 'a' : 'a',
'b' : 'b or c',
True for this special case, but where the lambda has to do
some calculation it starts to make sense! :-)
Alan G.
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
RE: [Tutor] Are you allowed to shoot camels? [kinda OT]
Alan,
That's actually worse than you might think. Try this:
var = 'd'
def p(): pass
ftable = { 'a' : lambda: 'a',
'b' : lambda: 'b or c',
'c' : lambda: 'b or c',
'd' : lambda: p}
print ftable.get(var, lambda: 'default case')()
And what you get is:
function p at 0x009BDFB0
That's hardly a pass :-)
Jeff
-Original Message-
From: Alan Gauld [mailto:[EMAIL PROTECTED]
Sent: Monday, February 07, 2005 3:06 PM
To: Smith, Jeff; Bob Gailer; tutor@python.org
Subject: Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
That's kinda what I thought but a couple of people suggested
that I used lambdas to make it clearer
I suggested that if we had proper lambdas we could use 'em...
But of course you can still use lambdas just put the print
at the client side:
def p(): pass
ftable = { 'a' : lambda: 'a',
'b' : lambda: 'b or c',
'c' : lambda: 'b or c',
'd' : lambda: p}
print ftable.get(var, lambda: 'default case')()
But I still had to use a def for the pass... :-(
Alan G.
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
That's actually worse than you might think. Try this:
def p(): pass
ftable = { 'a' : lambda: 'a',
'd' : lambda: p}
That should be:
'd': p}
ie No lambda used at all.
I wish Python had real lambdas!
And what you get is:
function p at 0x009BDFB0
Yep, coz the lambda returns a function object!
Which it should, I just shouldn't have used lambda there.
My bad,
Alan G.
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
Alan Gauld wrote: ie No lambda used at all. I wish Python had real lambdas! If python had real lambda's then it would be lisp or schema. __ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250 ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
Alan Gauld wrote:
As an aside, I did try to create a lambda based solution but was
unable. Let me know what's wrong:
ftable = { 'a' : lambda: print 'a',
SyntaxError: invalid syntax
I did say if Python had *proper* lambdas...
Unfortunately Python insists on only having *expressions* as
lambdas and since print is a command not a function you can't
use it in Python lambdas! Dumb or what??!
So you are stuck with predefining a bunch of one liner
functions and then creating a dictionary or going back
to if/elif chains, which is where we came in... :-)
Well, in this particular case, if one really wants to use lambdas then
one could (after importing sys, of course) replace the print statement
with a call to sys.stdout.write() --
ftable = { 'a': lambda: sys.stdout.write('a\n'), ... }
Note that sys.stdout.write() will *not* automatically add the newline
that print does (which is why I've specified it in the above sample).
Indeed, print can do all sorts of odd things with whitespace,
leaving sys.stdout.write() as the best way to have real control over
your output anyhow...
Jeff Shannon
Technician/Programmer
Credit International
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
Even more OT it would seem, but harking back to the original subject, Perl isn't looking too bad because I've been working through Java tonight. $j = STDIN; is relatively intuitive for a child of Unix, and it's also documented. BufferedReader keyboard = new BufferedReader(new InputStreamReader(System.in)); String j = keyboard.readline(); is not intuitive, and is hidden very well in the bowels of Sun's API's. Scary, when a language makes me think Perl would be nicer. : ) Heh. Oh, and whoever recommended Eclipse to me? Thank you very much. On Sat, 5 Feb 2005 08:59:30 -, Alan Gauld [EMAIL PROTECTED] wrote: Surely you jest, Alan. :-) Smiley noted but... Both perl and awk are turing complete, hence anything perl can do, awk can do as well. This is a popular misconception. Being Turing complete simply means you can implement any algorithm. But if the language doesn't provide I/O access for example it is impossible to write a device driver, or a comms stack, or any of a host of other low level programs. awk is non extendable (unless you have the source code!) so you can't do those things. Perl is not only extendable but actually comes wth a heap of those kinds of features that awk just doesn't have. And no amount of clever algorithms can compensate. Awk was designed for one task which it does spectacularly well but it was never intended for general purpose use. I/O is just one example, there are meny more... Alan G. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor -- 'There is only one basic human right, and that is to do as you damn well please. And with it comes the only basic human duty, to take the consequences. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
Jacob S. wrote:
aFuncList=[]
def x():
print one
aFuncList.append(x)
def x():
print two
aFuncList.append(x)
def x():
print three
aFuncList.append(x)
for item in aFuncList:
item()
Okay, for this problem (it can be altered otherwise)
def makefunct(stri):
def x():
print stri
return x
aFuncList = [makefunct('one'),makefunct('two'),makefunct('three')]
for item in aFuncList:
item()
It's shorter, it works and it looks cool.
Thanks to Jeff Shannon for the backbone of this example.
My intent in showing the above code was not to really print one two
three, but to show that a function doesn't care what it's called.
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
Surely you jest, Alan. :-) Smiley noted but... Both perl and awk are turing complete, hence anything perl can do, awk can do as well. This is a popular misconception. Being Turing complete simply means you can implement any algorithm. But if the language doesn't provide I/O access for example it is impossible to write a device driver, or a comms stack, or any of a host of other low level programs. awk is non extendable (unless you have the source code!) so you can't do those things. Perl is not only extendable but actually comes wth a heap of those kinds of features that awk just doesn't have. And no amount of clever algorithms can compensate. Awk was designed for one task which it does spectacularly well but it was never intended for general purpose use. I/O is just one example, there are meny more... Alan G. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
Alan Gauld wrote: Sean, what book/tutor are you using for Haskell? I learned it from The Haskell School of Expression which was OK but very graphics focused, I'd be interested in recommended second source on Haskell. as with Max I am reading Haskell: Craft of Functional Programming. I am about half way through it (have not got to Monads yet which are the mind benders). So far I really like it. Thought provoking examples and exercises. However there are no answers to the exercises. Which for a relative newbie to functional programming would have been nice. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
We'll just have to have to disagree about awk. I starting learning Perl to avoid learning awk :-) But awk is smaller and simpler than perl. So it should be faster (esp. at startup) for small and simple tasks. As usual: Right tool for right task. awk starts faster but perl is more efficient because it compiles the code prior to execution. So for any long files or big programs Perl is significantly faster than awk. But awk is just so elegant and quick to write that I use it for everything except huge files. Alan G. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
Sean, what book/tutor are you using for Haskell? I'm not Sean, Oops, sorry, I picked the name from the post I was replying to, apologies! but I'm using Simon Thompson's Haskell: The Craft of Functional Programming, which I find quite good. However, it's a bit odd, in that it almost reads like a mathematics book, which is something you may or may not like. FP generally is math oriented, all the Haskell books I've seen are the same. In fact the reason I chose mine was because it seemed the least math oriented, but in practice, because I'm not much into graphics, I spent a lot of time trying to think how to apply the principles elsewhere... I'll have a look for your one. Alan G. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
The reasons for the KR style of brace winning is to do
with the way the brain process structure and despite
the subjects stated preference for the 'Pascal' style
they still had lower perception scores.
Little nit-picking here:
if(foo)
{
bar();
}
Is not KR style, but Allman style. KR style (also known as One
True
Brace Style or 1TBS) is this:
Correct. The style you show (which I called Pascal style) is
the one that doesn't work. KR style
if(foo) {
bar;
}
Is the one that won the shootout.
With the outsider(which I dont know a name for!) beating both...
if (foo)
{
bar;
}
Which is the one that Python uses...
Alan G.
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
On Thursday 03 February 2005 17:41, Alan Gauld wrote:
In fact the best style of all is neither of the two I showed,
its actually this - which early everyone hates when they see it!
inf f(x)
{
bah()
}
Ugh. Alan, I won't even try to dispute the study. But if I have to
write code like that, I'll just take up gardening instead. :}
Look at it conceptually:
X
X
X
Thats Python! Since you are on this list I suspect you do write
code like that Its just Guido removed the now extraneous {}...
:-)
Alan G.
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
and function. Its like the theory behind how elictricity Yikes! Did I really manage to type elictricity And I can't blame finger trouble, e and i are miles apart on the keyboard! Blush Alan G. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
RE: [Tutor] Are you allowed to shoot camels? [kinda OT]
The problem with if/elif is that it doesn't express what is actually gong on. What you are try to do is execute a block of code based on the value of a single statement. if/elif doesn't do that and thereby introduces the possibility of errors. switch on-this: case 'a': do something case 'b': do something else case 'c': do yet something else Is much clearer and more maintatinable than if on-this == 'a': do something elif on-this == 'b': do something else elif on-this == 'c': do yet something else Note that the logic intended is that on-this. So why force the programmer to rewrite it N times and thereby introduce the possibility of N-1 typographical errors...particularly if the on-this is sufficiently complex. Note that I've left out break. I'm not convinced that fall-through is an important feature in switch and is usually the culpit in the cases of abuse. Of course, abuse has nothing to do with it. Someone somewhere will abuse any syntax you give them. Just because it *can* be abused doesn't mean it doesn't have value when used properly. This is also true for the ternary operator. The desired logic is to assign the value of a variable based on the value of some other variable. The assignment is the primary action and therefore should be the primary feature in the statement. Using if/else makes the decision point the primary action and leads to people stuffing other things in the clauses which don't belong there. IMHO, if/elif/else statements are far more abused than either switch or ternary but I certainly wouldn't argue they should be removed from the language. I also like Perl's unless statement but really prefer VBs DO/WHILE/UNTIL/LOOP constuct. Nothing beats it for clarity of expression. Jeff -Original Message- From: Alan Gauld [mailto:[EMAIL PROTECTED] Sent: Thursday, February 03, 2005 6:29 PM To: Smith, Jeff; Jacob S.; [EMAIL PROTECTED]; tutor@python.org Subject: Re: [Tutor] Are you allowed to shoot camels? [kinda OT] Perl and Python both resist the introduction of a switch statement which I (and many others) feel is the most elegant way to express what it does. Interesting. What do you feel is the problem with elif? Its not even much more typing and allows for much more expressive test conditions. Switch is really only useful for a single subset of tests. And of course switch statements are notorious bug factories and maintenance nightmares - the reason why OOP tries to eliminate them wherever possible. I also wish Python would take up the C ternary operator which is also quite clear and elegant. :-) You joke I assume? ':?' is clear? Its succinct but also prone to abuse. I don't think the Python equivalent foo = x and y or z is much less elegant than foo = x ? y : z ... To paraphrase the famous quote: There are no good programming languages, just some that aren't as bad in some situations. Absolutely true. I still use assembler occasionally, and I even like bits of COBOL (although not much, its my least favourite language!). And probably my favourite language of all is Logo even though I've never used it for any serious projects. Alan G. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
RE: [Tutor] Are you allowed to shoot camels? [kinda OT]
Disagree to disagree again. I certainly don't think Perl is less capable than awk. And awk is only easier to learn because there's less to it. If someone only wanted to use Perl for exactly what awk does I suspect they would find Perl easier. And awk's terseness is part of what I don't like about it. Unwrapping those statement's and puzzling out what they do can be hellish. Of course, I do understand that if you use it every day, you get use to it like any other language...then again, that was the whole theory behinf APL :-) For what it's worth, I'm a big fan of LISP and Prolog but can't find any reason to really use them any more. And for whoever complained about the proprietary language they have to use daily, I suggest you take a look at ADA. It was intended to be self documenting and was designed by committee. They started with Pascal and decided it was too terse :-) PROCEDURE myfun Became PROCEDURE myfun BODY IS (or something similar, it's been years...err, decades) Jeff -Original Message- From: Alan Gauld [mailto:[EMAIL PROTECTED] Sent: Thursday, February 03, 2005 6:31 PM To: Smith, Jeff; [EMAIL PROTECTED] Cc: tutor@python.org; [EMAIL PROTECTED] Subject: Re: [Tutor] Are you allowed to shoot camels? [kinda OT] We'll just have to have to disagree about awk. I starting learning Perl to avoid learning awk :-) Really? Why for? awk is far easier to learn than Perl - and far less generally capable! - but it makes Perl seem positively verbose! Alan G. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
What you are try to do is execute a block of code based on the value of a single statement. if/elif doesn't do that and thereby introduces the possibility of errors. In that case the best solution is a dictionary jump table. That is more maintainable than either and much faster too. And its also shorter to write. [Especially with lambdas :-)] Note that the logic intended is that on-this. So why force the programmer to rewrite it N times and thereby introduce the possibility of N-1 typographical errors... Thats a fair point although the dictionary solution avoids that. OTOH such switches tend to proliferate thropugh code and become a big source of maintenance headaches in their own right - multiple update syndrome across multiple files potentially. Note that I've left out break. I'm not convinced that fall-through is an important feature in switch and is usually the culpit in the cases of abuse. The problem is its so hard to tell when fall though is happening intentionally or by accident because someone forgot a break sytatement. But when it comes to abuuse the fall through mechanism is one of the worst offenders in C, its just too tempting to be clever with it. This is also true for the ternary operator. The desired logic is to assign the value of a variable based on the value of some other variable. But its not its based on the value of an *expression*. If the test could be limited to a single valiable value it might be justified but its an arbitrary expression. That makes it a conditional statement, which is most clearly represented by an if/else... Well I think so :-) I also like Perl's unless statement but really prefer VBs DO/WHILE/UNTIL/LOOP constuct. Nothing beats it for clarity of expression. I won't argue on either point, Python's minimalist approach - there's only one way to do it - means a paucity of looping constructs - something I point out in my tutorial. But I can live with it for the other niceties it brings. Alan G. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
Max Noel wrote: According to the Jargon file, this one is called Whitesmiths style. I tend to use Allman style myself, but given the code completion, spellchecking, etc. in modern IDEs, I suspect it's become more a question of personal preference than anything else. A bit like if(foo) versus if (foo), and whether or not to use braces for single-line blocks. (the latter issue being why I think The Whitespace Thing is an instance of Best Thing Ever(TM)) Bracing single line expressions is something I constantly agonize over. I'm always thinking may as well brace it because I may want to add more to this if clause. That's one of the reasons I like python is because it's relatively painless to make sure that your blocks are closed properly, especially when you aren't using a decent IDE. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
Disagree to disagree again. I certainly don't think Perl is less capable than awk. Neither do I... Really? Why for? awk is far easier to learn than Perl - and far less generally capable! - but it makes Perl seem positively verbose! I said awk was easier to learn but less capable than Perl. Perl is capable of things that awk can only dream of! Alan G. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
Smith, Jeff wrote: IMHO, if/elif/else statements are far more abused than either switch or ternary but I certainly wouldn't argue they should be removed from the language. IMHO, if it's true that if/elif/else statements are more abused than ternaries, then it's only because they're *used* far more often than ternaries. I'd say that the percentage of uses which could count as abuse is *far* higher for ternary than for if/elif/else. And I avoid (and recommend against) Python's a and b or c trick for similar reasons -- it *is* a trick. A 'real' ternary operator is confusing enough; this trick is more readable (words instead of opaque symbols) but more difficult to write correctly given the constraints on 'a'... Maybe I'm just weird, but I just don't find so much benefit to putting *everything* in-line. Occassionally it improves readability, but more often it obscures and obfuscates. Jeff Shannon Technician/Programmer Credit International ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
RE: [Tutor] Are you allowed to shoot camels? [kinda OT]
Please don't take offense. I should have included the smiley. To
reiterate an earlier statement: I like Python...a lot. But as with all
langauges there are some things I don't like and I believe they were
left out for the wrong reasons.
On the indentation topic. I would be curious to know if anyone has had
an experience where a rogue process or editor has trashed the
indentation in your Python and how you recovered from it.
Jeff
-Original Message-
From: Marilyn Davis [mailto:[EMAIL PROTECTED]
Sent: Friday, February 04, 2005 5:07 PM
To: tutor@python.org
Subject: RE: [Tutor] Are you allowed to shoot camels? [kinda OT]
I think Danny was saying that if you don't like:
if var == 'a':
print 'a'
elif var == 'b' or var == 'c':
print 'b or c'
elif var == 'd':
pass
else:
print 'default case'
you might like his dispatch scheme. And it has been mighty nice and
handy for me since he taught me, in some special cases.
I'll whisper that I'm a tiny bit disappointed to see the vaguely
demeaning 'are you joking' theme that has emerged in here. It's unusual
for us to be anything but generous and kind with each other. I guess
this is a hot topic. :^)
Marilyn
On Fri, 4 Feb 2005, Smith, Jeff wrote:
Now who's joking? Are you saying that
switch var:
case 'a':
print 'a'
case 'b' or 'c':
print 'b or c'
case 'd':
pass
default:
print 'default case'
Is less clear and maintainable than
def do_this_function():
print 'a'
def do_that_function():
print 'b or c'
def do_pass_function():
pass
def do_default_function():
print 'default case'
ftable = { 'a' : do_this_function,
'b' : do_that_function,
'c' : do_that_function,
'd' : do_pass_function }
ftable.get(var, do_default_function)()
Ugh!
-Original Message-
From: Alan Gauld [mailto:[EMAIL PROTECTED]
Sent: Friday, February 04, 2005 1:14 PM
To: Smith, Jeff; Jacob S.; [EMAIL PROTECTED];
tutor@python.org
Subject: Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
What you are try to do is execute a block of code based on the
value of
a single statement. if/elif doesn't do that and thereby introduces
the
possibility of errors.
In that case the best solution is a dictionary jump table. That is
more maintainable than either and much faster too. And its also
shorter to write. [Especially with lambdas :-)]
Note that the logic intended is that on-this. So why force the
programmer to rewrite it N times and thereby introduce the
possibility
of N-1 typographical errors...
Thats a fair point although the dictionary solution avoids that. OTOH
such switches tend to proliferate thropugh code and become a big
source of maintenance headaches in their own right - multiple update
syndrome across multiple files potentially.
Note that I've left out break. I'm not convinced that fall-through
is
an important feature in switch and is usually the culpit in the
cases
of abuse.
The problem is its so hard to tell when fall though is happening
intentionally or by accident because someone forgot a break
sytatement.
But when it comes to abuuse the fall through mechanism is one of the
worst offenders in C, its just too tempting to be clever with it.
This is also true for the ternary operator. The desired logic is to
assign the value of a variable based on the value of some other
variable.
But its not its based on the value of an *expression*. If the test
could be limited to a single valiable value it might be justified but
its an arbitrary expression. That makes it a conditional statement,
which is most clearly represented by an if/else... Well I think so :-)
I also like Perl's unless statement but really prefer
VBs DO/WHILE/UNTIL/LOOP constuct. Nothing beats it for clarity of
expression.
I won't argue on either point, Python's minimalist
approach - there's only one way to do it - means a
paucity of looping constructs - something I point
out in my tutorial. But I can live with it for the
other niceties it brings.
Alan G.
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
--
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
Now who's joking?
:-)
Are you saying that
switch var:
case 'a':
print 'a'
...
default:
print 'default case'
Is less clear and maintainable than
I don;tthink I said (certainly didn't mean) less clear, but
yes it is less maintainable.
But then...
def do_this_function():
print 'a'
ftable = { 'a' : do_this_function,
'b' : do_that_function,
'c' : do_that_function,
'd' : do_pass_function }
ftable.get(var, do_default_function)()
I did also say that it was best with proper lambdas
ftable = {'a' : lambda: print 'a',
'b' : lambda: print 'b'
etc///
and I'd code the calling section:
try: ftable[value]()
except KeyError: doDefaultFunction()
Its more maintainable because even if the switches proliferates
as they tend to do, the dictionary stays in one place and the
calling code never needs changing. So the changes are much
more localised. And of course the more complex the case
actions are, the more effective the dictionary/function
approach becomes.
Alan G.
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
an experience where a rogue process or editor has trashed the indentation in your Python and how you recovered from it. Only in mailing list emails!! Alan G. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
Now this is a concrete example of how lambda simplifies code, at
least
for me because it does not clutter my mental name space. Also it is
much shorter. However it should be said that this is very much a
question of taste.
Agreed. Which would make it pointless to remove in a future release. ;-)
However I must say that lambda's are very useful
even necessary for using Tkinter.
I'll bet that there is an easy enough way to use Tkinter without them
(Before anyone wants to argue my points, I would like to say that I'm
neutral in
this discussion, I only wish to point out alternative views)
aFuncList=[]
def x():
print one
aFuncList.append(x)
def x():
print two
aFuncList.append(x)
def x():
print three
aFuncList.append(x)
for item in aFuncList:
item()
Okay, for this problem (it can be altered otherwise)
def makefunct(stri):
def x():
print stri
return x
aFuncList = [makefunct('one'),makefunct('two'),makefunct('three')]
for item in aFuncList:
item()
It's shorter, it works and it looks cool.
Thanks to Jeff Shannon for the backbone of this example.
Jacob Schmidt
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
Alan Gauld wrote: I said awk was easier to learn but less capable than Perl. Perl is capable of things that awk can only dream of! Surely you jest, Alan. :-) Both perl and awk are turing complete, hence anything perl can do, awk can do as well. Now, as to which one would be easier to work with for a large scale development project, I will leave that flame-fest up to the regulars. Andy ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
an experience where a rogue process or editor has trashed the indentation in your Python and how you recovered from it. Only in mailing list emails!! I'll second that!!! Jacob Alan G. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
Andrew D. Fant said unto the world upon 2005-02-04 18:27: Alan Gauld wrote: I said awk was easier to learn but less capable than Perl. Perl is capable of things that awk can only dream of! Surely you jest, Alan. :-) I'm prettry sure he means it. And stop calling him Surely ;-) Brian vdB ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
Just wondering if I should bite the bullet and code from scratch in Perl, or if my Python - Perl is Ok. Its nearly always a bad idea to just translate code structures from one language to another. It will usually be sub optimal and non idiomatic - thus harder for the 'native' programmers to understand/debug. Bjarne Stroustrup made the same observation when C++ first came out and lots of Smalltalkers tried to use it like Smalltalk. He said C++ is not Smalltalk, if you want to write Smalltalk use smalltalk 1) I'll use Perl for the regex stuff from now on, Perl is obviously built for this. Yes, or PHP. Both have RE baked in. 2 ) There's More Than One Way To Do It makes debugging hard - i.e. close INFILE; close (INFILE); are both valid. I like one syntax, cos it's easier to remember. I can cope with that - BASIC does the same kind of thing - but its the zillion ways to handle errors that bug me! do thing until die do thing or die die unless do thing etc 3) Some stuff is counter-intuitive - A huge understatement! :-) Also, why doesn't if ( not $d eq a not $d eq c) evaluate to I don;t know but in cases like these I use parentheses like amaniac: if ( ((not $d) eq a) ((not $d) eq c) ) Or did you mean if ( (not ($d eq a)) (not ($d eq c)) ) Or was it if ( (not $d) eq (a not ($d eq c) ) # OK thats a bit unlikely... 4) WHAT IS WITH THE STUPID SYMBOLS EVERYWHERE LARRY??!! Clever abbreviations apparently! I don't even like the $ and @... one reason I can never quite feel happy with Ruby. It has fewer of them but still more than I like. In my opinion, there's only one place a sign should be, in an inequality test. Nope, I'm quite happy for it to be used in file indirection and even for right/left bit-shifting. But I don;t like it being part of the filename - I agree with that! great for regexes obviously based around *nix conventions. Big hodge-podge, oozing with inconsistency. I'd hate to work collaboratively on a Perl project. Two steps up from Brainf**k in parts. Obviously in need of a benevolent dictator a la Guido. Good summary! Perl reflects the fact that its inventor is a natural-language student not a computer scientist. It tries to incorporate the richness of expression of natural spech. But when dealing with machines that's a flaw IMHO! Alan G. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
How's Ruby? I bookmarked the homepage, but never got around to looking at it. Very, very nice. Cleanest object-orientedness I ever saw in a language (not that I have that much experience -- people like Alan would probably be better judges than me on this). You knew I couldn't resist! :-) Ruby OOP is OK although I don;t like the @ stuiff for members, theres simply no need for it! ONe thing I really like about Ruby is its implementation of iterators and generators - much better than Pythons IMHO. And their anonymous code blocks (aka lambdas) show how it can bve done. Pythons lambda feature is a bare minimum (and Guido wants to remove it!). anyway because Ruby has a huge flaw: it's Japanese (AFAIK it's also the only Made in Japan programming language, apart from stuff like ASM Yes the Japanese thing is an issue. THere are a few English books now, and the original one by Thomas and Hunt is free on the web. And as far as I know there is no [EMAIL PROTECTED] No English one at least. From what I remember, if you're programming in an object-oriented style (which I now tend do by default unless there is a painfully obvious and optimal solution in procedural style), Perl is the ugliest thing ever created since Visual Basic. VB is a thing of beauty compared to Perl for OO! In fact I actually don't mind VB OOP at all, especially in its .NET variant which includes inheritance and polymorphism. But Perl OOP is a hideous bodge. was frighteningly ugly. Java was built as an OO language from the ground up, if you except the presence of the basic C types. But unfortunately built very badly as an OOP environment. Its more accurate to call it a class based language since its perfectly possible to build a Java program with no objecs but lots of classes! I'd go so far as to say that if you followed Java's lead on OOP you would pick up some very bad OO habits and write code that was not really very OOP at all! Thats not to say you can't write good OO code in Java just that Java does little to encourage it. You need to read a good OO book, like BRuce Eckels Thinking IN... series) to see how to do it properly! ...Sure, it requires a lot of typing (in both meanings of the word), :-) 1) The Java Virtual Machine is a horrible resource hog. Most virtual machines are, especially those that try to be the OS as opposed to simply wrap the OS... The old UCSD Pascal virtual machine was the same, it ran great on a mainframe but the little Mini computers we had in the labs were woeful! 2) Sun didn't ever encourage anyone to write [insert language here] compilers that compiled to JVM bytecode. I don't think they discouraged it, there are JVM compilers for Python, Smalltalk, Lisp, Tcl and Perl at least... And whats worse is that there are few native code compilers for Java. The JVM thing is a big hype factor IMHO. We've been writing C/C++ programs for years that ran on Windows/Unix and IBM boxes with only minor #ifdefs inserted. The performance (and hence costs for servers!) differences are huge! Its no coincidence that 2 of the biggest supporters of Java (IBM and Sun) are hardware vendors! A slightly cynical Alan G. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
On Feb 3, 2005, at 09:48, Alan Gauld wrote: Pythons lambda feature is a bare minimum (and Guido wants to remove it!). Does he? Damn, just when I was learning functional programming! (in Haskell, if you're curious ^^) Yes the Japanese thing is an issue. THere are a few English books now, and the original one by Thomas and Hunt is free on the web. A little bit outdated, however. Ruby lacks a proper series of O'Reilly books; last time I checked the only one available was Ruby in a Nutshell, which is a few years old and covers Ruby 1.6 (2 versions behind the current one). What Matz needs to do IMO is to gather a couple of the l33test Ruby hackers in the world in a nice house in the Japanese countryside, pick a cool-looking animal (what about an eastern dragon?), and sit down with them to write a thousand-page Programming Ruby. is a thing of beauty compared to Perl for OO! In fact I actually don't mind VB OOP at all, especially in its .NET variant which includes inheritance and polymorphism. But Perl OOP is a hideous bodge. I haven't tried VB.NET (and don't intend to, I don't like BASIC-style languages), so I can't comment on this. But unfortunately built very badly as an OOP environment. Its more accurate to call it a class based language since its perfectly possible to build a Java program with no objecs but lots of classes! I'd go so far as to say that if you followed Java's lead on OOP you would pick up some very bad OO habits and write code that was not really very OOP at all! Thats not to say you can't write good OO code in Java just that Java does little to encourage it. You need to read a good OO book, like BRuce Eckels Thinking IN... series) to see how to do it properly! Well, of course, it all depends on how you're learning it. I'm sure there are some C tutorials out there that teach you (and encourage you) to use GOTO statements. :-D Me? I learnt Java by reading Eckel's Thinking in Java (and then followed with Wigglesworth/McMillan's Java Programming: Advanced Topics). I agree with you: it's an excellent book, that encourages good coding style and proper OOP. And whats worse is that there are few native code compilers for Java. The JVM thing is a big hype factor IMHO. We've been writing C/C++ programs for years that ran on Windows/Unix and IBM boxes with only minor #ifdefs inserted. The performance (and hence costs for servers!) differences are huge! Its no coincidence that 2 of the biggest supporters of Java (IBM and Sun) are hardware vendors! Agreed. I'm no compiler programmer, but it seems to me that they could just have written a nice cross-platform API and then platform-specific compilers, while keeping the specification of the language intact (i.e. platform-independent endian-ness, type sizes, etc.). The reasoning behind the JVM is that you don't need to recompile your code to run it on a different platform. But most existing Java projects have platform-specific versions, if only to make the GUI (try to) look native. You can spot a Java app from a hundred meters away. (then again, the same critic could be made of Python's and Perl's standard GUI toolkits) -- Max maxnoel_fr at yahoo dot fr -- ICQ #85274019 Look at you hacker... A pathetic creature of meat and bone, panting and sweating as you run through my corridors... How can you challenge a perfect, immortal machine? ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
code to run it on a different platform. But most existing Java projects have platform-specific versions, if only to make the GUI (try to) look native. You can spot a Java app from a hundred meters away. (then again, the same critic could be made of Python's and Perl's standard GUI toolkits) Amen. This drives me absolutely bonkers! Alan ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
RE: [Tutor] Are you allowed to shoot camels? [kinda OT]
Title: Message Nicholas, Well put. I come from a physics FORTRAN background and when I decided to learn C and start using it I heard the same arguments: it's too hard to read. It's a silly argument to use against a language. It's like an English-only speaker claiming he won't learn Greek because he doesn't understand it :-) I've been programming Perl for about 10 years and Python about 6 months. Most of what Python programmers find counter-intuitive about Perl seem perfectly reasonable to me and I find something in Python quite counter-intuitive although I understand the rationale. For the non-Perl people here, let me defend Perl by saying it is VERY good at what it was built for and not so good (but passable) at what it was not built for. What it is good at: Very rapid development of small scripts Replacing sed/awk/ksh/etc for scripting Manipulating strings System administration tasks What it is only passable at Large scale team development OOP Most of what Python developmers complain about in Perl are aimed at the rapid development thing. Perl is very terse which allows you do quickly script up small filters and data miners. I still use Perl for this and don't think that will ever change. Someone also complained about the"many way to exit" issue. Personally, I love that and use it to clarify my code. On a normal if statement I will put the test first: (test) (stuff-to-do); whereas if the test will affect code flow in a more major way I use the inversion, as with: return if (test); It allows me to quickly re-read my older scripts and understand the code flow faster. Having said all that, I'm also a big fan of Python which I can see will be very good at the two things Perl isn't so good at. However (and I know most here will disagree) there's still things I don't like about Python. My top two are: 1. Lack of closure on flow statements. I've already been bitten by: if test: do this do that where "do that" should have been out-dented. For a non-Python programmer, this "feature" can lead to some very non-intuitive coding should someone be so perverse as to write it :-) 2. Lack of "use strict" semantics. I know that pychecker can supposedly do this but I still believe it belongs in the language. Don't try to defend them. I've read all the arguments but I just don't agree with the design choice. Jeff -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, February 03, 2005 8:43 AMTo: tutor@python.orgSubject: Re: [Tutor] Are you allowed to shoot camels? [kinda OT] Well, here's my $0.02. I would recommend caution regarding the trashing of Perl. One thing I've been very impressed with on this list (and other segments of the Python community) is the _fairly_ cordial relationship between the supporters of the two languages. Contrast that to a lot of PHP literature I've seen, which doesn't even acknowledge that Perl exists. My theory is that many who use PHP got kicked around by trying to learn Perl, and bitterness set in. But that's a digression... Anyway, I'm on the fence as to whether I want to learn Python (not exactly a "core competency" for statisticians, but I do line the numerical computation capabilities which look _much_ better than those of Perl), and I wouldn't want this negativity to push me (or others) awayNicholas MontpetitDeluxe Business Services651-787-1008 ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
I once heard that Larry Wall said, Perl is worse than Python because people needed it worse. And I've heard it said that Perl is the Write-Only language Marilyn ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
[EMAIL PROTECTED] wrote: Btw, I'm skeptical that the code below does what you want it to do. :-) that was kind of my point. In python I just type the obvious and it works. In Perl I have to muck with references, slashes, arrows and the like. Every time I have had to write a nested datastructure I have spent my time debugging that structure. Same here, Sean: whenever I work with nested data structures, I end up doing some debugging. However, I think that has more to do with my less-than-perfect understanding of references than with any Perl shortcomings. -Nick___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
Max Noel wrote: On Feb 3, 2005, at 09:48, Alan Gauld wrote: Pythons lambda feature is a bare minimum (and Guido wants to remove it!). Does he? Damn, just when I was learning functional programming! (in Haskell, if you're curious ^^) However, Python doesn't need lambdas to be able to write in a functional style. Functions are first-class objects and can be passed around quite easily, and IIRC Python's list comprehensions were borrowed (though probably with notable modification) from Haskell. Keep in mind that both lambdas and named functions are created at runtime, so the creation of both is fully dynamic. Indeed, there are only a few differences between lambdas and named functions in Python: - Anonymous vs named - Single expression vs suite of statements - Inline vs. pre-created Note that the second of these is a consequence of the third -- given Python's block-indentation-based structure, there's no good way to inline a multi-statement suite (how many of those statements belong to that 'if' suite?). Statements need to have a clear indentation level, and while one can sometimes fudge that for a single statement, it gets exponentially messier as the number of statements goes up. I'd also argue that the inline nature is the *true* differentiating feature of lambdas -- the fact that they're anonymous is relatively minor. Consider, also, that if they weren't inline then you'd need a name to refer to them by... and at that point, you *have* a 'normal' function. So, while there are some advantages to having single-use callables be defined inline (i.e. lambdas), their removal from Python (which wouldn't happen before the mythical Python 3k anyhow) isn't likely to be as devastating as some might lead you to believe. ;) It certainly won't prevent you from using Python for functional programming... (And personally, I suspect that if lambdas *are* removed, they will be replaced with a different construct that will fill the same needs in a more Pythonic way...) Jeff Shannon Technician/Programmer Credit International ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
Jeff Shannon wrote: However, Python doesn't need lambdas to be able to write in a functional style. Functions are first-class objects and can be passed around quite easily, and IIRC Python's list comprehensions were borrowed (though probably with notable modification) from Haskell. Note, it is haskell convention to name a list of objects with a plural. So xs - list of x. haskell: [ x | x - xs ] [ foo x | x - xs, x 2 ] python [ x for x in xs ] [ foo(x) for x in xs if x 2 ] shaleh still mastering haskell, but loving it. Like python for functional languages. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
For the non-Perl people here, let me defend Perl by saying it is VERY good at what it was built for and not so good (but passable) at what it was not built for. What it is good at: Very rapid development of small scripts Replacing sed/awk/ksh/etc for scripting Manipulating strings System administration tasks Absolutely true and the reason I used Perl for several years before I used Python - even though I was aware of Python and had even fired up the interpreter a couple of times. But then I had the advantage of using C and C++ and Pascal(Delphi) and Lisp and Smalltalk for more complex programs. And I still used awk because Perl makes a lousy awk replacement! But as a shell replacement its great, and for string manipulation only Snoball beats it. The only reason I initially took Python seriously was as a teaching language for my tutorial, but once I got into it I realised it was a lot more powerful than I had originally thought. What it is only passable at Large scale team development OOP Passable is optimistic, I used Perl with a team of only 6 programmers and it was a disaster! Most of what Python developmers complain about in Perl are aimed at the rapid development thing. Perl is very terse which allows you do quickly script up small filters and data miners. I still use Perl for this and don't think that will ever change. Absolutely and I agree. The things I don't like are not the rapid development things, the $,@ symbology is completely unnecessary and is extremely counter intuitive even for experienced Perl coders. We still have arguments about references versus scalars etc yet after 10 years of using Perl in prodsuction code... It was a side effct of shell programming that should never have happened (although I will grant it yields a marginal speed increase by improving optimisation in the compiler!) Someone also complained about the many way to exit issue. Personally, I love that and use it to clarify my code. On a normal if statement I will put the test first: And for one person projects, where a consistent style is used its fine, but the minute you get beyond small projects its another complication waiting to bite. But again thats Perls background showing through. Python was never intended just for quick n dirty scripting it was from the outset designed as a general purpose language so embodied best practice - or Guidos take on that - as discovered by computer science research. Larry Wall simply created a language to do a job, it turned out to be powerful and got used a lot more than he expected! There is no perfect language, and very few truly bad languages - they never get out of the lab - they all have something that they are good at and from which we can learn! Alan G. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
RE: [Tutor] Are you allowed to shoot camels? [kinda OT]
Alan, We'll just have to have to disagree about awk. I starting learning Perl to avoid learning awk :-) I also disagree about the symbology. I am never confused by it. In fact, I find it clarifies the language although I agree its ugly. When I see a random variable in Perl I can tell at a glance whether it's a scalar, list, or hash. That isn't true in Python (or most other languages). I realize that doesn't mean much in large OOP programs but in medium to large single-purpose scripts it does simplify debugging and maintenance. Jeff -Original Message- From: Alan Gauld [mailto:[EMAIL PROTECTED] Sent: Thursday, February 03, 2005 5:14 PM To: [EMAIL PROTECTED]; Smith, Jeff Cc: tutor@python.org; [EMAIL PROTECTED] Subject: Re: [Tutor] Are you allowed to shoot camels? [kinda OT] For the non-Perl people here, let me defend Perl by saying it is VERY good at what it was built for and not so good (but passable) at what it was not built for. What it is good at: Very rapid development of small scripts Replacing sed/awk/ksh/etc for scripting Manipulating strings System administration tasks Absolutely true and the reason I used Perl for several years before I used Python - even though I was aware of Python and had even fired up the interpreter a couple of times. But then I had the advantage of using C and C++ and Pascal(Delphi) and Lisp and Smalltalk for more complex programs. And I still used awk because Perl makes a lousy awk replacement! But as a shell replacement its great, and for string manipulation only Snoball beats it. The only reason I initially took Python seriously was as a teaching language for my tutorial, but once I got into it I realised it was a lot more powerful than I had originally thought. What it is only passable at Large scale team development OOP Passable is optimistic, I used Perl with a team of only 6 programmers and it was a disaster! Most of what Python developmers complain about in Perl are aimed at the rapid development thing. Perl is very terse which allows you do quickly script up small filters and data miners. I still use Perl for this and don't think that will ever change. Absolutely and I agree. The things I don't like are not the rapid development things, the $,@ symbology is completely unnecessary and is extremely counter intuitive even for experienced Perl coders. We still have arguments about references versus scalars etc yet after 10 years of using Perl in prodsuction code... It was a side effct of shell programming that should never have happened (although I will grant it yields a marginal speed increase by improving optimisation in the compiler!) Someone also complained about the many way to exit issue. Personally, I love that and use it to clarify my code. On a normal if statement I will put the test first: And for one person projects, where a consistent style is used its fine, but the minute you get beyond small projects its another complication waiting to bite. But again thats Perls background showing through. Python was never intended just for quick n dirty scripting it was from the outset designed as a general purpose language so embodied best practice - or Guidos take on that - as discovered by computer science research. Larry Wall simply created a language to do a job, it turned out to be powerful and got used a lot more than he expected! There is no perfect language, and very few truly bad languages - they never get out of the lab - they all have something that they are good at and from which we can learn! Alan G. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
I also disagree about the symbology. I am never confused by it.
I'll believe you, but its interesting that computer scientists
have done lots of studies to test people's comprehension of programs
and in every single case there has been clear evidence that
additional prefixes/characters etc obscure undestanding. Even
by those who thought they were fluent in the language concerned.
Check the book Code Complete for some references, or try searching
the Software Engineering Institute stuff at CMU.
Its like the old argument in C over whether
int f(){
blah()
}
or
int f()
{
blah()
}
was clearer. Many people claim to prefer the second but
objective testing repeatedly shows that the first form
produces measurably better results.
In both of these cases its not about style its about what works.
I suspect Guido was aware of that research and applied it to
Python's design. Larry wasn't and didn't... (although he sure
is now! :-)
Alan G.
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
RE: [Tutor] Are you allowed to shoot camels? [kinda OT]
I think the point is that different people are...different. It probably
won't surprise you to find out that I am in the C camp that prefers your
second example. I'm sure what those studies show is what the majority
find easier not what everyone finds easier. Who knows, maybe it's a
left-brain, right-brain thing. And it wouldn't be the first time I was
told my brain was wired differently from the general public. Just ask
my wife :-)
Jeff
-Original Message-
From: Alan Gauld [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 03, 2005 5:47 PM
To: Smith, Jeff; [EMAIL PROTECTED]
Cc: tutor@python.org; [EMAIL PROTECTED]
Subject: Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
I also disagree about the symbology. I am never confused by it.
I'll believe you, but its interesting that computer scientists
have done lots of studies to test people's comprehension of programs
and in every single case there has been clear evidence that
additional prefixes/characters etc obscure undestanding. Even
by those who thought they were fluent in the language concerned.
Check the book Code Complete for some references, or try searching
the Software Engineering Institute stuff at CMU.
Its like the old argument in C over whether
int f(){
blah()
}
or
int f()
{
blah()
}
was clearer. Many people claim to prefer the second but
objective testing repeatedly shows that the first form
produces measurably better results.
In both of these cases its not about style its about what works. I
suspect Guido was aware of that research and applied it to
Python's design. Larry wasn't and didn't... (although he sure
is now! :-)
Alan G.
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
haskell: [ x | x - xs ] [ foo x | x - xs, x 2 ] python [ x for x in xs ] [ foo(x) for x in xs if x 2 ] Sean, what book/tutor are you using for Haskell? I learned it from The Haskell School of Expression which was OK but very graphics focused, I'd be interested in recommended second source on Haskell. Alan G. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
Perl and Python both resist the introduction of a switch statement which I (and many others) feel is the most elegant way to express what it does. Interesting. What do you feel is the problem with elif? Its not even much more typing and allows for much more expressive test conditions. Switch is really only useful for a single subset of tests. And of course switch statements are notorious bug factories and maintenance nightmares - the reason why OOP tries to eliminate them wherever possible. I also wish Python would take up the C ternary operator which is also quite clear and elegant. :-) You joke I assume? ':?' is clear? Its succinct but also prone to abuse. I don't think the Python equivalent foo = x and y or z is much less elegant than foo = x ? y : z ... To paraphrase the famous quote: There are no good programming languages, just some that aren't as bad in some situations. Absolutely true. I still use assembler occasionally, and I even like bits of COBOL (although not much, its my least favourite language!). And probably my favourite language of all is Logo even though I've never used it for any serious projects. Alan G. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
We'll just have to have to disagree about awk. I starting learning Perl to avoid learning awk :-) Really? Why for? awk is far easier to learn than Perl - and far less generally capable! - but it makes Perl seem positively verbose! Alan G. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
Alan Gauld wrote: There is no perfect language, and very few truly bad languages - they never get out of the lab - they all have something that they are good at and from which we can learn! Heh, I'd look at that a bit differently -- I think that there's a *lot* of bad languages, it's just that we're spared ever hearing about the majority of them because they don't ever get very far. ;) (But then, at my job I'm stuck using a horrible Frankenstein's monster of a proprietary language on a daily basis, so I can't help but believe that there's plenty more awful languages around that didn't happen to be rescued from oblivion by an accident of history...) Jeff Shannon Technician/Programmer Credit International ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
second example. I'm sure what those studies show is what the
majority
find easier not what everyone finds easier.
They are statistical its true, but they were based on the folks
who actually used the second style indent and they actually
got worse scores in the tests using their own style than when
they used the style they were less used too.
The tests have been repeated many times using multiple
languages and thousands of subjects ranging from students
through to professionals with years of experience.
The reasons for the KR style of brace winning is to do
with the way the brain process structure and despite
the subjects stated preference for the 'Pascal' style
they still had lower perception scores.
As I said its not a style issue its to do with how the
brain works and the outcome of a lot of studies over at
least 30 years produces a pretty solid case.
left-brain, right-brain thing.
Nope they tried that too, comparing creative types with
science types etc. Same result.
told my brain was wired differently from the general
public. Just ask my wife :-)
And they tried mixing up the sexes too, no difference.
There may be a few individuals for whom it doesn't apply
but in the vast majority of cases its a fact.
In fact the best style of all is neither of the two I showed,
its actually this - which early everyone hates when they see it!
inf f(x)
{
bah()
}
After reading the studies I changed my C style to the above,
it certainly hasn't made my code harder to debug and I don't
see any increase in bug count, but I can't honestly say I
notice a reduction either, but it helps to know that I'm
increasing the chances of my code being understood by
someone else...
Alan G.
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
On Feb 3, 2005, at 23:19, Alan Gauld wrote: Sean, what book/tutor are you using for Haskell? I learned it from The Haskell School of Expression which was OK but very graphics focused, I'd be interested in recommended second source on Haskell. I'm not Sean, but I'm using Simon Thompson's Haskell: The Craft of Functional Programming, which I find quite good. However, it's a bit odd, in that it almost reads like a mathematics book, which is something you may or may not like. -- Max maxnoel_fr at yahoo dot fr -- ICQ #85274019 Look at you hacker... A pathetic creature of meat and bone, panting and sweating as you run through my corridors... How can you challenge a perfect, immortal machine? ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
On Feb 3, 2005, at 23:41, Jeff Shannon wrote: (But then, at my job I'm stuck using a horrible Frankenstein's monster of a proprietary language on a daily basis, so I can't help but believe that there's plenty more awful languages around that didn't happen to be rescued from oblivion by an accident of history...) Yeah. Sometimes I read a little bit of Wikipedia's Esoteric Programming Languages page, and some of them just leave me in awe. Brainfuck (and its variant Ook!) and INTERCAL (GOTO is considered harmful, so we removed it -- INTERCAL uses COME FROM instead) are already quite impressive, but the very idea of Befunge makes my brain want to explode. Especially that extension to the language that allows one to write N-dimensional programs. :D -- Max maxnoel_fr at yahoo dot fr -- ICQ #85274019 Look at you hacker... A pathetic creature of meat and bone, panting and sweating as you run through my corridors... How can you challenge a perfect, immortal machine? ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
Alan Gauld wrote: However, Python doesn't need lambdas to be able to write in a functional style. I disagree Jeff. It does need lambdas to do FP properly, and better lambdas than we have currently. What it doesn't need is the lambda keyword and syntax - although pesonally I like lambda since it is descriptive! Well, we'll have to continue to disagree on that. ;) Personally, I can't help but think that 'lambda' is descriptive only to people who've experienced it elsewhere, and that that does *not* include the majority of the programming community, but I could be mistaken. :) Functions are first-class objects and can be passed around quite easily, Yes, but lambdas are more than first class functions, they are anonymous functions! In fact really just callable code blocks, not necessarily functions in the strictest sense (except that every callable in FP is a function...! ;-) Well, given that in Python a function is just a callable code block that's bound to a name... ;) Personally, I fail to see why having an anonymous function is such a huge conceptual advantage, no matter how many times this is proclaimed as truth by lambda-users, but again this is just my own impression. Having to define every function before using it would be a big hassle and make code less readable IMHO. Here, ISTM that you're emphasizing the in-line nature of lambdas as being their key usage point... And personally, I prefer to have a glossary of terms rather than having to decipher jargon by context. ;) only a few differences between lambdas and named functions in Python: - Anonymous vs named the key feature Again, I fail to see why this is such an advantage -- I've seen assertions that it is, over and over again, but never any convincing evidence - Single expression vs suite of statements A python restriction. Well, I *did* specify that I was talking about 'in Python'... ;) I'd also argue that the inline nature is the *true* differentiating feature of lambdas -- the fact that they're anonymous is relatively minor. I agree, if I had an inline mechanism that forced me to provide a name I could just use 'f' over and over and not feel too cheated, but its nicer not to have an artificial name when theres no need. Personally, I prefer to have the opportunity to provide a meaningful name, and don't see where a generic name is any more restrictive than having no name, but again, maybe that's just me. So, while there are some advantages to having single-use callables be defined inline The other advantage is the huge conceptial advantage that real lambdas confer. The breakthrough idea of def f(x): return x+x being the same as f = lambda x: x+x is only possible to demonstrate if you have lambda to start with. And yet that concept of a function name being just another variable and the callable code being an object in its own right becomes much more obvious in my opinion. lambda is a learning tool which shows what is really happening whereas def is just syntactic sugar. Hm, I understood the idea of functions being just code objects that were bound to a name, and could be passed around, stored in collections, and effectively renamed, well before I really got a hold on lambdas as anything more than some confusing bit of magic. Of course, I started in C, where I was fairly comfortable with the idea of function pointers; function objects are a pretty simple step up, abstraction-wise, from that. I suppose that one might argue that I *still* just don't really get lambdas (and I wouldn't argue with that). I can see some advantages to small inline functions, though I suspect that a more-explicit currying mechanism (such as the proposed partial() higher-order function) could easily replace such uses. I'm sorry to say, though, that the supposed advantages of anonymity come across as little more than handwaving assertions to me, no matter how sincerely they're intended. (I've just started to read through SICP, to pick up some lisp/scheme, in hopes of understanding the appeal a bit better, so maybe there's hope for me yet. ;) ) Jeff Shannon Technician/Programmer Credit International ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
On Thursday 03 February 2005 17:41, Alan Gauld wrote:
In fact the best style of all is neither of the two I showed,
its actually this - which early everyone hates when they see it!
inf f(x)
{
bah()
}
Ugh. Alan, I won't even try to dispute the study. But if I have to
write code like that, I'll just take up gardening instead. :}
--
Bud Rogers [EMAIL PROTECTED] KD5SZ
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
Max Noel wrote: On Feb 3, 2005, at 23:41, Jeff Shannon wrote: (But then, at my job I'm stuck using a horrible Frankenstein's monster of a proprietary language on a daily basis, so I can't help but believe that there's plenty more awful languages around that didn't happen to be rescued from oblivion by an accident of history...) Yeah. Sometimes I read a little bit of Wikipedia's Esoteric Programming Languages page, and some of them just leave me in awe. Brainfuck (and its variant Ook!) and INTERCAL (GOTO is considered harmful, so we removed it -- INTERCAL uses COME FROM instead) are already quite impressive, but the very idea of Befunge makes my brain want to explode. Especially that extension to the language that allows one to write N-dimensional programs. :D The difference here is that those are languages that were *intended* to be brain-melting. The language I'm talking about (Pick Proc, aka UHL) was intended to do real work with -- though at times I think it was designed by a brain-damaged lemur that was huffing paint fumes. For example, every line (except flow-control statements i.e. 'if' and 'go' (there's a few other exceptions as well, but anyhow...)) must begin with a single character that denotes what the line does - 'c' for comment, 'o' for output (print to terminal), 'h' to build a command, 'p' to execute that command... empty lines are forbidden. Note also that the position *after* the final newline character is considered a line, and therefore a file cannot end with a newline. Especially when combined with several of the utilities that it's commonly used to script for, it begins to approach Perl in indecipherability, without even having the excuse of being largely non-alpha characters. I'd consider writing a Python extension that would interact with the system such that I wouldn't need to use this awful little scripting language, but that would require more effort and thought than I'm willing to invest in learning the details of this system. Jeff Shannon Technician/Programmer Credit International ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
Pythons lambda feature is a bare minimum (and Guido wants to remove it!). However, Python doesn't need lambdas to be able to write in a functional style. I disagree Jeff. It does need lambdas to do FP properly, and better lambdas than we have currently. What it doesn't need is the lambda keyword and syntax - although pesonally I like lambda since it is descriptive! Functions are first-class objects and can be passed around quite easily, Yes, but lambdas are more than first class functions, they are anonymous functions! In fact really just callable code blocks, not necessarily functions in the strictest sense (except that every callable in FP is a function...! ;-) Having to define every function before using it would be a big hassle and make code less readable IMHO. borrowed (though probably with notable modification) from Haskell. Conceptually not much modification, but the two syntaxes are poles apart! only a few differences between lambdas and named functions in Python: - Anonymous vs named the key feature - Single expression vs suite of statements A python restriction. - Inline vs. pre-created A key usage point Note that the second of these is a consequence of the third Again a Python restriction. And hard to see how you avoid given Pythons structure. I'd also argue that the inline nature is the *true* differentiating feature of lambdas -- the fact that they're anonymous is relatively minor. I agree, if I had an inline mechanism that forced me to provide a name I could just use 'f' over and over and not feel too cheated, but its nicer not to have an artificial name when theres no need. So, while there are some advantages to having single-use callables be defined inline The other advantage is the huge conceptial advantage that real lambdas confer. The breakthrough idea of def f(x): return x+x being the same as f = lambda x: x+x is only possible to demonstrate if you have lambda to start with. And yet that concept of a function name being just another variable and the callable code being an object in its own right becomes much more obvious in my opinion. lambda is a learning tool which shows what is really happening whereas def is just syntactic sugar. (And personally, I suspect that if lambdas *are* removed, they will be replaced with a different construct that will fill the same needs in a more Pythonic way...) I believe (and hope) this too. Certainly the stink it has created on c.l.p should hopefully convince Guido that there is a groundswell of demand for the facility if not the name... Alan G. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
[Tutor] Are you allowed to shoot camels? [kinda OT]
Hi, Had the *ahem* joy of learning Perl last night. Egad. Wrote the script in Python to get it right, and then 'translated' it to Perl. Does the style of coding Python engenders suit the Perl environment in anyone's experienc? AFAI can see there is no real 'style' to Perl, apart from white noise of non alphanumeric characters. Just wondering if I should bite the bullet and code from scratch in Perl, or if my Python - Perl is Ok. Two codes are here - Python http://www.rafb.net/paste/results/BVaym940.html Perl http://www.rafb.net/paste/results/LromA876.html [OT begins] By the way, I'm only learning Perl because I need to script some routine HTML maintenance, and I can't be bothered applying to head office IT for an install of Python, as the justification involved is ludicrous, especially considering that my role as defined does not include scripting. First impressions of Perl - 1) I'll use Perl for the regex stuff from now on, Perl is obviously built for this. 2 ) There's More Than One Way To Do It makes debugging hard - i.e. close INFILE; close (INFILE); are both valid. I like one syntax, cos it's easier to remember. 3) Some stuff is counter-intuitive - $lenOfModList = @moddirList is the Perl equivalent of lenofModList = len(moddirList) @someArray = (@someArray, $newValue) is the same as someArray.append(newValue) I couldn't figure this one out until I read that Perl automatically flattens lists. Also, why doesn't if ( not $d eq a not $d eq c) evaluate to true for $d = b when if (not $d eq a) evals to true and if ($d ne a $d ne c) evals true also? What's with that? 4) WHAT IS WITH THE STUPID SYMBOLS EVERYWHERE LARRY??!! I'm not referring to the $ @, I can see how they could be useful, although with a list - @dude = (1, 2, 3), to obtain the 2nd value I would expect $d = @dude[1], not $d = $dude[1], that's counterintuitive also. Oh, no, what I'm referring to is stuff like @_, and @!, and @indexFile = INFILE to read a whole file, and this - I hate Perl for this - open OUTFILE, c:/python23/j/index.htm What's the difference between open OUTFILE, c:/python23/j/index.htm and open OUTFILE, c:/python23/j/index.htm ? The first will open index.htm with the handle OUTFILE, to read... The second will open index.htm with the handle OUTFILE to write!. Of course, the documentation I had didn't mention that. It just said to open it and use print FILEHANDLE $value; to write. Oh no, I had to find a CGI Perl tutorial, which mentioned using lst; to open and gst; to write (or something), which I guessed as lesser/greater than. Why is the read/write modifier part of the filename??? Why is it a ? In my opinion, there's only one place a sign should be, in an inequality test. So, Perl in my opinion - great for regexes obviously based around *nix conventions. Big hodge-podge, oozing with inconsistency. I'd hate to work collaboratively on a Perl project. Two steps up from Brainf**k in parts. Obviously in need of a benevolent dictator a la Guido. But then, I've been spoilt by clean, smooth (usually) Python. Lovely, usually consistent Python. Aah, Pytho *dreamy look* [end OT rant] -- 'There is only one basic human right, and that is to do as you damn well please. And with it comes the only basic human duty, to take the consequences. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
On Feb 2, 2005, at 23:18, Liam Clarke wrote: 1) I'll use Perl for the regex stuff from now on, Perl is obviously built for this. Actually IIRC Perl *invented* regexes as we know them. The standard regex syntax is known as Perl regex syntax. 2 ) There's More Than One Way To Do It makes debugging hard - i.e. close INFILE; close (INFILE); are both valid. I like one syntax, cos it's easier to remember. I don't find it that bad. Ruby does it as well, and it's perfectly readable. It's more or less equivalent as if condition: and if(condition): both being valid in Python. 3) Some stuff is counter-intuitive - $lenOfModList = @moddirList is the Perl equivalent of lenofModList = len(moddirList) You sure of that? I was under the impression that len(moddirList) in Perl was $moddirList (@moddirList is the list itself). Also, why doesn't if ( not $d eq a not $d eq c) evaluate to true for $d = b when if (not $d eq a) evals to true and if ($d ne a $d ne c) evals true also? What's with that? This probably has to do with operator precedence. It's been lifted from C, so chances are that has a higher precedence than eq. Use parentheses. 4) WHAT IS WITH THE STUPID SYMBOLS EVERYWHERE LARRY??!! I'm not referring to the $ @, I can see how they could be useful, although with a list - @dude = (1, 2, 3), to obtain the 2nd value I would expect $d = @dude[1], not $d = $dude[1], that's counterintuitive also. This will be fixed in Perl 6. Then again, Perl 6 is supposed to be pure heaven, as the Parrot virtual machine can theoretically be used with any language and is heavily optimized. Python and Ruby with the speed of Perl, and the possibility to interface your code with CPAN modules. That's really cool. Once Perl 6 is released, of course. Why is the read/write modifier part of the filename??? Why is it a ? In my opinion, there's only one place a sign should be, in an inequality test. This is consistent with UNIX redirection. ./foo bar.txt executes the command foo, and redirects its STDOUT to the file bar.txt. ./foo bar.txt does the same, but appends to bar.txt instead f overwriting it. -- Max maxnoel_fr at yahoo dot fr -- ICQ #85274019 Look at you hacker... A pathetic creature of meat and bone, panting and sweating as you run through my corridors... How can you challenge a perfect, immortal machine? ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
(damn, forgot to add the main part of my argumentation) I learnt Perl as well, a few years ago. It was the first scripting language I came across (all I knew before that were C, Turbo Pascal, and a few calculator programming languages), so I immediately fell in love with its string manipulation capabilities. I came across PHP a little while after, and while it had some things which I liked (PHP.net being the main one), I preferred Perl. However, I never got the opportunity to really use it, and after a while the inconsistency of the syntax grew on me, and the language itself kept eluding me. I was never able to grok it, and thus systematically reverted to C every time I had to code something. Fast forward to last summer. In the span of 1 week, I discovered both Python and Ruby. Fell in love with both and immediately ditched Perl. I never looked back, even though I know Perl is still the fastest scripting language around. I value debugging time more than CPU time these days. -- Max maxnoel_fr at yahoo dot fr -- ICQ #85274019 Look at you hacker... A pathetic creature of meat and bone, panting and sweating as you run through my corridors... How can you challenge a perfect, immortal machine? ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
I don't find it that bad. Ruby does it as well, and it's perfectly readable. It's more or less equivalent as if condition: and if(condition): both being valid in Python. Yeah, but you'd never call a function foo like this- x = foo in Python. It's just good to be able to say that a function always has some rule here. That improves readability (imao). You sure of that? I was under the impression that len(moddirList) in Perl was $moddirList (@moddirList is the list itself). Well, my one's correct, but I think yours is also. And this is what gets me. @mod = (1,2,3) $mod = 3 $mod[0] = 1 Is inconsistent. Or at least, the logic behind this is not immediately apparent to me. I'm always open to illumination on these things however. if ( not $d eq a not $d eq c) = False for $d = b if ($d ne a $d ne c) = True This probably has to do with operator precedence. It's been lifted from C, so chances are that has a higher precedence than eq. Use parentheses. Ah... Ironic, I got misled by TMTOWTDI. I figured that if not x==a and not x == c evaled as True in Python, and if (not $d eq a) evaled as True in Perl, that if ( not $d eq a not $d eq c) would also eval as true. Of course, what's even weirder to me is that if ($d ne a $d ne c) does eval as True, as far as I can see, '$d ne a' is the same as d != a in Python, which is the same as 'if not d == a', which, logically, would mean that $d ne a is the same as 'if(not $d eq a) in which case both tests should handle the addition of an AND the same. Once again, illumination is welcomed, as I have a finally that some subtlety of Boolean logic is eluding me, and a 'x != a' test is different to 'if not x == a' in a small but significant way. Max - the foo std.txt thing explains it, but what about @dude = FILE, where do the brackets originate from? This is another issue I'm having with Perl as opposed to Python - Perl is very much written by *nix users for *nix users, it's implementation of *nix conventions shows, including the `` things. Whereas (correct me if I'm wrong), but Python was written by *nix users for everyone. Python seems very non-OS-denominational in it's current incarnation, it may have been very *nix orientated prior. So here comes me, the guy who installed Linux once, failed to see the big deal and uninstalled it. Up until 3 months ago, my comp was used for gaming, pure and simple, me being a certified Day of Defeat freak, and so Windows has always best served my purpose. Now, I want to programme, so I have to learn Unix conventions to use a crossplatform language! It's like asking *nix users to sign a Microsoft EULA!! (Well, not as bad, but still as anathemic.) Fast forward to last summer. In the span of 1 week, I discovered both Python and Ruby. Fell in love with both and immediately ditched Perl. How's Ruby? I bookmarked the homepage, but never got around to looking at it. Oh, and I will say this - Perl Java (and that's an inequality test, not a redirection of output) Cheers, Liam Clarke -- 'There is only one basic human right, and that is to do as you damn well please. And with it comes the only basic human duty, to take the consequences. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
On Thu, 3 Feb 2005, Liam Clarke wrote:
Had the *ahem* joy of learning Perl last night. Egad. Wrote the script
in Python to get it right, and then 'translated' it to Perl.
Hi Liam,
I strongly recommend sending the Perl code to that Perl-beginners mailing
list referenced earlier. I'm sure that there are some Perl idioms that
can simplify the code there.
For example:
### Perl ###
$wrkDir = c:/python23/j/j2;
opendir( TGTDIR, $wrkDir);
@dirList = readdir(TGTDIR);
@moddirList=();
foreach $fileName (@dirList) {
if ($fileName ne .. $fileName ne .) {
@moddirList = (@moddirList, $fileName);
}
}
##
can be greatly improved by Perl's globbing operator instead of readdir():
##
$wrkDir = c:/python23/j/j2;
@dirList = $wrkDir/*;
##
This has a fairly close Python equivalent in the glob.glob() function:
###
wrkDir = s:/toolkit/retain/sustainableEmployment
dirList = glob.glob(wrkDir + /*)
###
@someArray = (@someArray, $newValue) is the same as someArray.append(newValue)
This is actually doing much more work than a list append. The list-adding
code that you had earlier is equivalent to:
### Python ###
someList = someList + [newValue]
##
which is just bad. *grin*
More idiomatic Perl is:
### Perl ###
push @someArray, $newValue;
##
which should have the same performance as a list append().
Of course, the documentation I had didn't mention that. It just said to
open it and use print FILEHANDLE $value; to write.
Perl's documentation system 'perldoc' command is one of the really nice
things about Perl. In some cases, I think it might be even more
comprehensive than 'pydoc', since perldoc also directly links to tutorial
material.
Try:
###
$ perldoc perl
###
I guess I'm trying to say: language idioms take time to learn, and unlike
syntax errors, weird idioms aren't really detectable by the runtime
system. *grin*
If you continue to learn Perl, talk with the beginners's group there, so
that the community there can help. And if the Perl programs that you're
writing seem suboptimal, get it vetted by someone who knows Perl well; you
may be pleasantly surprised.
Best of wishes to you!
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
