On Feb 24, 16:48, Nick Seidenman wrote:
>
> I don't typically use emacs, but could it be that with it's context-sensitive
> editing features it has lulled our friends Guido et al into thinking the
> editor will ease this pain? I of course make the outlandish presumption
> that only old farts like me still use vi.
>
> -- End of excerpt from Nick Seidenman <nick@osg.saic.com>
But when I've argued this in other newgroups (comp.programming.literate,
and others) I've usually been hit with with OPPOSITE argument: with
tools like emacs, bad formatting should not be an issue ( though, that
means when you get some code that someone else has written, you should
go thru each file and reformat it before printing it out and reading
it. - I don't use vi, but I'm old enough for bifocals and I often
prefer paper to CRT. I only recently tried out the python-mode.el -
usually I use jove ( a mini-emacs ) and do a lot of interactive
use with the gnu-readline interface. )
Re: the argument that that feature is a turn-off for some potential
users:
I don't know if Guido should go to much effort to try to change
the language for people who don't like it anyway: he's got a big
enough backlog of requests from certified Python-Lovers like myself.
On Feb 24, 17:13, Richard Golding wrote:
>
> Well, to add a different viewpoint to this debate -- I have had
> problems with the indentation syntax because sometimes I don't want
> code written and manipulated by humans; I want code manipulated by
> code. One of the strengths of the lisp-like languages is that they
> have a syntactic structure that stays out of the way of machine
> manipulation. Much of this debate reminds me of the debate
> surrounding Lisp macros versus specialised special forms -- and macros
> seem to have been a win in the long run. Sad to say, this difficulty
> of manipulating code forms has kept me from using Python in general.
>
> -- End of excerpt from Richard Golding <golding@cello.hpl.hp.com>
But Richard hit on the number one problem. ( #2 is lambda )
It is solvable by using your one INDENT/DEDENT token and
then passing the code string thru a preprocessor funcion
that puts out the correct tab level, before passing the
string to exec/compile.
Tim has pointed out thet the lambda scope problem was due to the
dual local/global scope level restriction. But I would also add
that the DESIRE for lambda or anonymous functions is also due
partly to that restriction: after-all, it's not important that
function be *completely* ANONYMOUS, so much as anonymous in
some scope. I assume Bennett would be *almost* as happy with
an equivalent of Lisp's "let", binding locally to a function.
Forgetting, for a moment, the multi-line debate, an alternative
form of lambda syntax could be:
def outerfun():
myfun = lambda (x,y,seq):
news=[]
for item in seq:
if (item==x) news.append(y)
elif( item==y) news.append(x)
else: news.append(item)
return news
The one-line lambda form would still be restricted.
The scope of 'myfun' would be local to 'outerfun'.
This would parallel the Scheme distinction between
'define'-ing a function ( which puts the name into
the outer scope ) and "( let ((fun (lambda ... "
which would make a function of inner scope.
Popping the multi-line topic back onto the stack:
My vote is to add a INDENT/DEDENT token, but to
make it UGLY, so nobody will be tempted to use
it: ":< stmt; stmt; stmt >;"
- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU>
- UVA Department of Molecular Physiology and Biological Physics
[ "Richard Golding <golding@cello.hpl.hp.com>"
( Hmmm. That name looks awfully familiar...
'cd /usr/local/src/refdbms' ... )
Hello Richard! I didn't know you were on this list.
I've been using your 'refdbms' package ( and I've
been occasionally been tempted to try to rewrite
some of the csh scripts into python: There isn't
any chance that THAT project is already in the
works on YOUR end, is there? It would make it a
lot easier to customize. I figured out how to
add some new fields to refnew, just to discover
that they were not included in searches anyway! ]