ANN: Dao Language v.0.9.6-beta is release!

[Steve Holden]

actually, I do. i write as much as fits in one line and separate items
with comma.



I'm not Python newbie. I wrote a good deal of non-trivial python code,
and I still don't like it and still find it very annoying.



Actually, after I learned Python, I value "funny squiggles" in other
languages even more. It's very annoying, for example, that I can't split
a long line in the following way:

print a + b +
c + d
print "other statement"

I guess I'm required to insert some unneccessary () around the long expression
to disable the white space parsing..

I don't suppose there's any good reason, then, why (for example)
outlining tools use indentation to indicate different levels of
significance.

I'm sorry you find the indentation unnatural and inconvenient, but you
may have to accept that for this feature you are actually in a minority.

regards
Steve

 

[Zeljko Vrba]

I don't suppose there's any good reason, then, why (for example)
outlining tools use indentation to indicate different levels of
significance.

Nobody bothers to figure out something better? Now you will argue that then
the indendation is good enough.. and I can just reply that then it's an
open research question..

A philisophical note:

An obvious defficieny of the current way we write code now is its inherent
tree-structure resulting from {}, indentation, begin/end markers or whatnot.
But the flow of code is often not a tree but a cycle.. Yet we are always
dealing with a tree-like representation of the code on screen.

This note also applies to your remark about outlining tools.

I'm sorry you find the indentation unnatural and inconvenient, but you
may have to accept that for this feature you are actually in a minority.

I have no problem accepting that I'm in a minority. I have a problem with
offensive people using my example arguments to riducule me.. While they
even don't want to open their minds and accept that there might be a
remote possibility that indentation is not ideal.

 

[bonono]

I have no problem accepting that I'm in a minority. I have a problem with
offensive people using my example arguments to riducule me.. While they
even don't want to open their minds and accept that there might be a
remote possibility that indentation is not ideal.

Welcome to c.l.py

 

[Zeljko Vrba]

Welcome to c.l.py

Oh, thank you.

 

[Fredrik Lundh]

Nobody bothers to figure out something better? Now you will argue that then
the indendation is good enough.. and I can just reply that then it's an
open research question..

huh? people mention existing research (including formal usability studies),
and your response is that since you don't agree with the results, more re-
search is needed.

do you think this is a kansas school board meeting?

I have no problem accepting that I'm in a minority. I have a problem with
offensive people using my example arguments to riducule me..

http://www.google.com/search?q=duck+typing

</F>

 

[Mike Meyer]

An obvious defficieny of the current way we write code now is its inherent
tree-structure resulting from {}, indentation, begin/end markers or whatnot.
But the flow of code is often not a tree but a cycle.. Yet we are always
dealing with a tree-like representation of the code on screen.

Except the the representation on the screen isn't tree-like, it's a
two-dimenional array of characters. You can, of course, interpret that
as tree-like structure. But you can also interpret it as generalized
graph, cycles included.

I have no problem accepting that I'm in a minority. I have a problem with
offensive people using my example arguments to riducule me.. While they
even don't want to open their minds and accept that there might be a
remote possibility that indentation is not ideal.

What surprises me is that people come in assuming that there must be
one language for everything and everyone, and that Python should
strive to be that language. Such a language doesn't exist, so there is
no such thing as 'ideal'. A language that might be optimal for one
person and task won't necessarily be optimal if you change either the
person or the task. Yet some people intent on forcing one language to
be ideal propose changing it to suit them, and then act surprised when
people who've tried their proposed changes in other languages and
found them lacking reject them.


<mike

 

[Tom Anderson]

Zeljko Vrba enlightened us with:

Find me an editor which has folds like in VIM, regexp search/replace
within two keystrokes (ESC,, marks to easily navigate text in 2
keystrokes (mx, 'x), can handle indentation-level matching as well as
VIM can handle {}()[], etc. And, unlike emacs, respects all (not
just some) settings that are put in its config file. Something that
works satisfactorily out-of-the box without having to learn a new
programming language/platform (like emacs).

Found it! VIM!

ED IS THE STANDARD TEXT EDITOR.

Huh! *Real* men edit their text files by changing bits on the hard disk
by hand with a magnetized needle.

Hard disk? HARD DISK?

Hard disks are for losers who can't write tight code. *Real* mean keep
everything in core. Unless it's something performance-critical, in which
case they fit it in the cache.

tom

 

[Antoon Pardon]

Because you're accustomed to one set of conventions, you
may find Python's set strange at first. Please try it, and
don't fight it. See if your objections don't fade away. If
you're like most Python newbies, you'll stop thinking about
brackets before long, and if you're like a lot of us,
you'll wonder what those funny squiggles mean when you are
forced to revert to one of those more primitive languages.

I think the suggestion that those who have some problem
with how python deals with compound statements - obligated
indentation, no end markers - are newbees, is getting
stale. I am not a newbee and I have problems with it.
I had problems with it when I was a newbee, grew used
to it and even liked it at some point and now again
have problems with it.

Well problems is probably too strong, would prefer
differently seems closer.

 

[Rick Wotnaz]

I think the suggestion that those who have some problem
with how python deals with compound statements - obligated
indentation, no end markers - are newbees, is getting
stale. I am not a newbee and I have problems with it.
I had problems with it when I was a newbee, grew used
to it and even liked it at some point and now again
have problems with it.

Well problems is probably too strong, would prefer
differently seems closer.

You're right that I should not have assumed newbie status, but I
most often see posts complaining about lack of braces from those
newly exposed to Python's way of doing things. The post I responded
to considered whitespace indention a "design defect". I would be
surprised to hear an experienced Python programmer say that, but
maybe I'm just naive.

I am not a fanatic about structuring via whitespace. From time to
time, code arrives at this group with leading whitespace removed,
which makes me think it might be nice to have bracketing, so the
original logic could (maybe) be recreated. That's most of the
downside, though, and an artificial problem at that. It has nothing
to do with Python, but with hostile software along the way. The
upside is clarity of code (and a little less typing, too), and that
makes up for the occasional artificial problem.

 

[gene tani]

Python could take over the programming world except one of it's best
features (scope by indent) is a primary reason why it never will. It's
not flexible enough. A large percentage of programmers won't even try
the language.

Their loss.

And nobody else sees the need for change? Oh, except those who think
Tabs are evil and should no longer be allowed.

How about (1) add some more flexibility for optional braces [...]

Try this::

from __future__ import braces

Ciao,
Marc 'BlackJack' Rintsch

My catalog of asymptotic threads (i.e. once in a while somebody
*might* post something we haven't read before):

- why do tabs have syntax-significance
- why are there more python web app frameworks/ IDEs / GUI frameworks
than python keywords
- why don't you fix the official documentation?
- what's the best IDE / editor (actually, this discussion is still
worthwhile)

Jamie Zawinski would say: "there are python people, who, when
confronted with a problem, think "Aha, i'll post to c.l.python" At
that point...

 

[Marc 'BlackJack' Rintsch]

Actually, after I learned Python, I value "funny squiggles" in other
languages even more. It's very annoying, for example, that I can't split
a long line in the following way:

print a + b +
c + d
print "other statement"

I guess I'm required to insert some unneccessary () around the long expression
to disable the white space parsing..

They are not unneccesary. At least not in Python. Unless you use the
line continuation with trailing '\' which is a bit uglier than parenthesis
(IMHO).

And you want to trade occasional parenthesis for mandatory curly braces? I
guess it leads to much more braces or other explicit end markers for suits
than the few "unneccessary" parenthesis one has to use to group long
expressions.

Ciao,
Marc 'BlackJack' Rintsch.