Re: ANN: Dao Language v.0.9.6-beta is release!
In [EMAIL PROTECTED], Zeljko Vrba wrote: 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Op 2005-12-11, Rick Wotnaz schreef [EMAIL PROTECTED]: 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. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Antoon Pardon [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: Op 2005-12-11, Rick Wotnaz schreef [EMAIL PROTECTED]: 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. 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. -- rzed -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Marc 'BlackJack' Rintsch wrote: In [EMAIL PROTECTED], JohnBMudd wrote: 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... -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
On 2005-12-11, Rick Wotnaz [EMAIL PROTECTED] wrote: Make a grocery list. Do you terminate each item with punctuation? Write a headline for a newspaper. Is actually, I do. i write as much as fits in one line and separate items with comma. 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 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. 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. 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.. -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Zeljko Vrba wrote: On 2005-12-11, Rick Wotnaz [EMAIL PROTECTED] wrote: Make a grocery list. Do you terminate each item with punctuation? Write a headline for a newspaper. Is actually, I do. i write as much as fits in one line and separate items with comma. 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 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. 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. 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 -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
On 2005-12-11, Steve Holden [EMAIL PROTECTED] wrote:
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.
--
http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Zeljko Vrba wrote: 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. Welcome to c.l.py -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
On 2005-12-11, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Welcome to c.l.py Oh, thank you. -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Zeljko Vrba wrote: 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Zeljko Vrba [EMAIL PROTECTED] writes:
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
--
Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
On Sun, 11 Dec 2005, Steven D'Aprano wrote:
On Sat, 10 Dec 2005 16:34:13 +, Tom Anderson wrote:
On Sat, 10 Dec 2005, Sybren Stuvel wrote:
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
--
ø¤º°`°º¤øø¤º°`°º¤øø¤º°`°º¤øø¤º°`°º¤ø--
http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Zeljko Vrba wrote:
On 2005-12-08, Steven D'Aprano [EMAIL PROTECTED] wrote:
Making a mistake in indentation level is precisely analogous to leaving
out markers in other languages. If your editor is smart enough, and the
But look at the following example:
if a:
some_code1
if b:
some_code2
If I accidentaly delete if b:, then some_code2 gets under the if a: which is
not intended. With braces (or other delimiters):
if(a) {
some_code1;
}
if(b) {
some_code2;
}
if I delete if(b) I get a syntax error about unmatched braces. IMO, the
right
way to handle braces in C is always to include them, even when they are not
technically obligatory. I code like that for a long time and it has saved me
a lot of headache.
My advice would be to stop using punch cards and start using a sensible
text editor. Your use case is somewhat unconvincing in the 21st century.
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/
--
http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
On 2005-12-10, Steve Holden [EMAIL PROTECTED] wrote:
My advice would be to stop using punch cards and start using a sensible
text editor.
Such as..?
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).
--
http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
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!
Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa
--
http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Zeljko Vrba wrote:
On 2005-12-10, Steve Holden [EMAIL PROTECTED] wrote:
My advice would be to stop using punch cards and start using a sensible
text editor.
Such as..?
Since choice of text editor tends to be a religious issue, that will
have to be your decision, not mine.
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).
Jusr choose one that minimises your propemsity to accidentally delete
lines.
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/
--
http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
On Sat, 10 Dec 2005, Sybren Stuvel wrote:
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.
tom
--
Argumentative and pedantic, oh, yes. Although it's properly called
correct -- Huge
--
http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
On 2005-12-10, Tom Anderson [EMAIL PROTECTED] wrote: ED IS THE STANDARD TEXT EDITOR. And: INDENTATION SUCKS BIG TIME. Using indentation without block termination markers is opposite of the way we write spoken language, terminating each sentence with . Ever wondered why we use such things in written language, when people are much better in guessing what the writer wanted to say then computers? -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Zeljko Vrba wrote: Using indentation without block termination markers is opposite of the way we write spoken language, terminating each sentence with . Ever wondered why we use such things in written language, when people are much better in guessing what the writer wanted to say then computers? Interesting. Python's use of indentation comes from ABC, which based the design partially on extensive testing on human beings. Humans often use indentation for grouping, and colons to introduce a new level or group are at least as common. In fact, most humans can understand the structure of a Python program even if they've never programmed before. I guess writers don't use indentation to group text on your planet. /F -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Zeljko Vrba [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: On 2005-12-10, Tom Anderson [EMAIL PROTECTED] wrote: ED IS THE STANDARD TEXT EDITOR. And: INDENTATION SUCKS BIG TIME. Using indentation without block termination markers is opposite of the way we write spoken language, terminating each sentence with . Ever wondered why we use such things in written language, when people are much better in guessing what the writer wanted to say then computers? I believe I may have seen cases in written spoken language where paragraphs were indented, or otherwise separated with whitespace. It's even possible that I've seen some examples of written languages that use no periods at all! And what's more, I've seen more than one *computer* language that uses no terminating periods! Why, it boggles the mind. Despite the arguments advanced by those whose previous computer languages used braces and semicolons, there actually are more ways to separate complete statements than with punctuation. Make a grocery list. Do you terminate each item with punctuation? Write a headline for a newspaper. Is punctuation always included? Read a mediaeval manuscript. Do you find punctuation? Whitespace? How about Egyptian hieroglyphs, Chinese ideograms, Ogham runes? 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. -- rzed -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
On Sat, 10 Dec 2005 16:34:13 +, Tom Anderson wrote:
On Sat, 10 Dec 2005, Sybren Stuvel wrote:
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.
--
Steven.
--
http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
On Sat, 10 Dec 2005 22:01:07 +, Zeljko Vrba wrote: On 2005-12-10, Tom Anderson [EMAIL PROTECTED] wrote: ED IS THE STANDARD TEXT EDITOR. And: INDENTATION SUCKS BIG TIME. Using indentation without block termination markers is opposite of the way we write spoken language, terminating each sentence with . That's not true at all. We terminate sentences with punctuation because sentences can and frequently do go over multiple lines. Sentences are independent of indentation. But paragraphs are not. We terminate paragraphs with whitespace, sometimes including indentation. A very common method of terminating paragraphs in written English is to indent the first line of a new paragraph, with no vertical whitespace between them. We also terminate items in lists, sometimes without punctuation, by a new line: item one item two item three and indicate long items by a change in indentation: item one item two is an extremely long item which goes over two or more physical lines item three We sometimes indicate a block of text -- which may be one or more paragraphs -- purely with indentation: Blocks of quoted text are frequently delimited by a blank line at the top and bottom of the block, and indentation on the left margin. The indentation is necessary because the block of text may include multiple paragraphs. On the other hand, vertical white space between paragraphs is optional. It is a common convention to flag new paragraphs with an indentation, or if already indented, an extra indentation. It is even possible to have multiple levels of quoting. According to Professor Joe Expert: As a general rule, one should never indent more than two levels deep, even if this means avoiding quoting text which quotes a quotation. We also delimit larger sections of novels with whitespace. A common convention is to use an indent and no vertical space to delimit paragraphs, and three blank lines to delimit a block of text (for example, when changing the point of view character). Only if that end of block occurs at the end of the page is it replaced with punctuation, usually a series of three asterisks. So, in summary, your argument that block markers are necessary in English is wrong. Only sentences use start/end markers. Words are delimited by whitespace, paragraphs and larger blocks of text use either whitespace, indentation or both. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
On 2005-12-08, Steven D'Aprano [EMAIL PROTECTED] wrote:
Making a mistake in indentation level is precisely analogous to leaving
out markers in other languages. If your editor is smart enough, and the
But look at the following example:
if a:
some_code1
if b:
some_code2
If I accidentaly delete if b:, then some_code2 gets under the if a: which is
not intended. With braces (or other delimiters):
if(a) {
some_code1;
}
if(b) {
some_code2;
}
if I delete if(b) I get a syntax error about unmatched braces. IMO, the right
way to handle braces in C is always to include them, even when they are not
technically obligatory. I code like that for a long time and it has saved me
a lot of headache.
--
http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Zeljko Vrba wrote: But look at the following example: if a: some_code1 if b: some_code2 If I accidentaly delete if b:, then some_code2 gets under the if a: which is not intended. not to mention that if you have if a: some_code1 some_code2 and accidentally remove some_code2, it won't be executed at all ! do you often remove code by accident? is this some vi-specific problem ? /F -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Op 2005-12-08, Steven D'Aprano schreef [EMAIL PROTECTED]: On Thu, 08 Dec 2005 08:23:52 +, Antoon Pardon wrote: Op 2005-12-07, Steven D'Aprano schreef [EMAIL PROTECTED]: On Wed, 07 Dec 2005 15:26:59 +, Zeljko Vrba wrote: Braces are very convenient to match block start and end. Open a C program in the VI editor, and press % in command mode on some brace.. It will take you to its matching brace. How do you do something like that with python code (or any code that is based purely on indentation..) (1) You don't need to, because you can *see* where the indentation changes, so you don't need to rely on your editor counting for you. But you can't alway easily discern by how much. Admittedly, the blind and visually impaired might not. They will need a screen reader that understands indentation. Admittedly, a badly formatted arbitrary piece of text with arbitrary indentation from line to line is difficult to judge. But fortunately we're discussing code, not arbitrary text. Code will not jump from one random level of indentation to another: there will often be blocks of lines with the same indentation; when the indent level increases it should always increase by one only; and when it decreases it will usually decrease by one, sometimes two, more rarely three. Four is not that unusual. The last method in a class and you already have at least two. If that method ended with an if in a while, not that uncommon, and you have four. If your functions have more than, say, twelve levels of indentation, you should be refactoring them. Well I'm not going to put a hard number on it, but I agree with the gist of your statement. If you are stuck reading other people's code, where they have hard-coded indents as (say) two spaces, you may have trouble. But if they are using a more standard four or eight spaces, it is easier to judge, and better still if they use tabs, you can tell your editor to set the tabs to whatever size works for you. IME it doesn't make that much of a difference whether two spaces are used, or four. One is too little and more than four is too much, but between those two it doesn't make much difference for me. [snip] But sometimes you mess up and your code is no longer indented as it should. If you marked the end of the indentations, you can easily correct this. And sometimes you mess up and delete braces you shouldn't have. Sure and if you have correctly indented your code, that will be easily corrected too. If you had Or worse, you delete code you shouldn't have. Whoops! Lets hope you have a backup. Start/end markers (whether braces or keywords) plus indentation carry redundant information. Redundancy means you can *sometimes* correct *some* errors. But there are costs to redundancy: you have to carry the redundant information around (in source code, in your head, in the complexity of the parser) for the 99.99% of time that there is no error. 99.99% of the time, I don't need a backup either. Besides what I had in mind wouldn't force anyone to use end markers. It wouldn't break any program(with the exception of programs using variable like endif). It would just allow people to put in the redundancy where they think it would be usefull. And what happens when the indentation and the markers disagree? Languages like C decide arbitrarily that the markers are meaningful and indentation is not, and it is a potent source of bugs and obfuscation. Make it an error. That IMO is what redundant information is for, so that when it doesn't agree, you are alerted to the problem. Making a mistake in indentation level is precisely analogous to leaving out markers in other languages. If your editor is smart enough, and the code is not ambiguous, a smart editor will pick that up straight away. And if not, the Python compiler will soon tell you, and you can then fix the bug in your code. A smart editor may just happily continue, putting all further statements on the wrong indentation level. Besides I hate smart editors. They always seem to get in my way. This will probably say more about my lack of knowledge about emacs, but the fact that it always jumps to the corresponding left parent, bracket or brace when I type the right character in, just drives me nuts. Besides no editor has saved me once from the fact that I forget a colon as last charater of an if, else, try or whatever compound statement, so why should I rely on the editor for other problems? -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Fredrik Lundh wrote: Zeljko Vrba wrote: But look at the following example: if a: some_code1 if b: some_code2 If I accidentaly delete if b:, then some_code2 gets under the if a: which is not intended. not to mention that if you have if a: some_code1 some_code2 and accidentally remove some_code2, it won't be executed at all ! do you often remove code by accident? is this some vi-specific problem ? If you had bothered to read the context he was merely showing an example to prove that this is not entirely true: Making a mistake in indentation level is precisely analogous to leaving out markers in other languages. He was not suggesting that this is some affliction that he suffers, as you are suggesting. -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
David Rasmussen a écrit : Antoon Pardon wrote: Write shorter functions ;) This has little to do with long functions. A class can contain a large number of methods, whitch are all rather short, and your class will still be spread over several pages. Write classes with a smaller interface ;-) /David What about an editor that will reserve the first lines in the edit window to show the current class ? Could be a cool feature here :) You'll see something like that when you scroll too far : FileEdit OptionsAbout --- class do_something(object): ... return 1 def do_it(self): print self.what_now -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Christophe wrote: David Rasmussen a écrit : Antoon Pardon wrote: Write shorter functions ;) This has little to do with long functions. A class can contain a large number of methods, whitch are all rather short, and your class will still be spread over several pages. Write classes with a smaller interface ;-) /David What about an editor that will reserve the first lines in the edit window to show the current class ? Could be a cool feature here :) I've been using a Vim script for a while that adds the name of current class, function, or Class.Method to the status line and it helps quite a bit. -- Benji York -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
On Fri, 09 Dec 2005 09:34:44 +0100, Fredrik Lundh wrote: do you often remove code by accident? is this some vi-specific problem ? +1 QOTW I wish I had thought of saying that! In fact, I think I will have done! -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
On Fri, 09 Dec 2005 08:15:14 +, Zeljko Vrba wrote:
On 2005-12-08, Steven D'Aprano [EMAIL PROTECTED] wrote:
Making a mistake in indentation level is precisely analogous to leaving
out markers in other languages. If your editor is smart enough, and the
But look at the following example:
if a:
some_code1
if b:
some_code2
If I accidentaly delete if b:, then some_code2 gets under the if a: which is
not intended. With braces (or other delimiters):
if(a) {
some_code1;
}
if(b) {
some_code2;
}
if I delete if(b) I get a syntax error about unmatched braces.
Not unless you also delete the opening brace on the same line, surely?
Okay, you've deleted the line and you get a syntax error. But not if you
accidentally deleted the previous brace as well, or if there was an
earlier unmatched brace somewhere earlier in your code.
We could play this game all day -- you find some error or typo where
redundant braces will save the day, and I'll find another error where they
won't. In the meantime, you're spending more time thinking about braces
plus indentation than I am thinking about just indentation.
And I bet that you've made more mistakes where you got the indentation
right but the braces wrong, even with a smart editor, than I've
accidentally deleted code in a way that the indentation levels just happen
to wrongly match up.
IMO, the right
way to handle braces in C is always to include them, even when they are not
technically obligatory. I code like that for a long time and it has saved me
a lot of headache.
Sure, and that's good advice for C, but that's because C is labouring
under the disadvantage that indentation is not meaningful to the compiler,
but is meaningful to the human programmer.
--
Steven.
--
http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
On Fri, 09 Dec 2005 02:59:44 -0600, D H wrote: Fredrik Lundh wrote: Zeljko Vrba wrote: But look at the following example: if a: some_code1 if b: some_code2 If I accidentaly delete if b:, then some_code2 gets under the if a: which is not intended. not to mention that if you have if a: some_code1 some_code2 and accidentally remove some_code2, it won't be executed at all ! do you often remove code by accident? is this some vi-specific problem ? If you had bothered to read the context he was merely showing an example to prove that this is not entirely true: Making a mistake in indentation level is precisely analogous to leaving out markers in other languages. Pardon me, but how is deleting code equivalent to making a mistake in indentation level? Is there some editor where if you hit tab too few or too many times it deletes the previous line? -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Op 2005-12-07, Zeljko Vrba schreef [EMAIL PROTECTED]: On 2005-12-07, Antoon Pardon [EMAIL PROTECTED] wrote: What I don't understand is, that most people who have a problem with scope by indentation, want to introduce braces. I think braces are the worst solution. Braces are very convenient to match block start and end. Other conventions can be just as convenient. Open a C program in the VI editor, and press % in command mode on some brace.. It will take you to its matching brace. How do you do something like that with python code (or any code that is based purely on indentation..) Not my problem, since I don't suggest pure indentation is the way to go. I just think braces are the worst solution for it, as python is concerned. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Op 2005-12-07, Steven D'Aprano schreef [EMAIL PROTECTED]: On Wed, 07 Dec 2005 15:26:59 +, Zeljko Vrba wrote: Braces are very convenient to match block start and end. Open a C program in the VI editor, and press % in command mode on some brace.. It will take you to its matching brace. How do you do something like that with python code (or any code that is based purely on indentation..) (1) You don't need to, because you can *see* where the indentation changes, so you don't need to rely on your editor counting for you. But you can't alway easily discern by how much. (2) And if you do need to, then you should use a smarter editor that understands indentation levels, not just braces. Braces are superfluous if you use consistent indentation, and indentation is superfluous -- to the compiler -- if you use braces. But indentation is *not* superfluous to the human eye: we can parse indentation very easily, but nested braces/brackets only with great difficulty. That's why programmers in languages that ignore indentation still indent their code, or at least the sensible ones do. But sometimes you mess up and your code is no longer indented as it should. If you marked the end of the indentations, you can easily correct this. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
On 8 Dec 2005 08:17:14 GMT in comp.lang.python, Antoon Pardon [EMAIL PROTECTED] wrote: [...] I just think braces are the worst solution for it, as python is concerned. Agreed. A model like Modula-2's would be much preferable, and in fact is supported (but not enforced) today (as long as you also obey indentation rules). Just mark the end of your blocks with #endif, #endfor, #endwhile, #enddef, #endclass, #endwhatever as appropriate. Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
On Thu, 08 Dec 2005 08:23:52 +, Antoon Pardon wrote: Op 2005-12-07, Steven D'Aprano schreef [EMAIL PROTECTED]: On Wed, 07 Dec 2005 15:26:59 +, Zeljko Vrba wrote: Braces are very convenient to match block start and end. Open a C program in the VI editor, and press % in command mode on some brace.. It will take you to its matching brace. How do you do something like that with python code (or any code that is based purely on indentation..) (1) You don't need to, because you can *see* where the indentation changes, so you don't need to rely on your editor counting for you. But you can't alway easily discern by how much. Admittedly, the blind and visually impaired might not. They will need a screen reader that understands indentation. Admittedly, a badly formatted arbitrary piece of text with arbitrary indentation from line to line is difficult to judge. But fortunately we're discussing code, not arbitrary text. Code will not jump from one random level of indentation to another: there will often be blocks of lines with the same indentation; when the indent level increases it should always increase by one only; and when it decreases it will usually decrease by one, sometimes two, more rarely three. If your functions have more than, say, twelve levels of indentation, you should be refactoring them. If you are stuck reading other people's code, where they have hard-coded indents as (say) two spaces, you may have trouble. But if they are using a more standard four or eight spaces, it is easier to judge, and better still if they use tabs, you can tell your editor to set the tabs to whatever size works for you. [snip] But sometimes you mess up and your code is no longer indented as it should. If you marked the end of the indentations, you can easily correct this. And sometimes you mess up and delete braces you shouldn't have. If you had Or worse, you delete code you shouldn't have. Whoops! Start/end markers (whether braces or keywords) plus indentation carry redundant information. Redundancy means you can *sometimes* correct *some* errors. But there are costs to redundancy: you have to carry the redundant information around (in source code, in your head, in the complexity of the parser) for the 99.99% of time that there is no error. And what happens when the indentation and the markers disagree? Languages like C decide arbitrarily that the markers are meaningful and indentation is not, and it is a potent source of bugs and obfuscation. Making a mistake in indentation level is precisely analogous to leaving out markers in other languages. If your editor is smart enough, and the code is not ambiguous, a smart editor will pick that up straight away. And if not, the Python compiler will soon tell you, and you can then fix the bug in your code. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Op 2005-12-06, [EMAIL PROTECTED] schreef [EMAIL PROTECTED]: Just because a few people dislike something, doesn't make it a defect. Actually, it does. Unless you're in the business of building security systems. Then the goals are reversed. I can accept that you like scope by indent and don't want to see any changes gong forward. That's your choice. it's somewhat ironic that you have to cite a documented source to back up your point. Somewhat. :) Do you think that adding braces to Python will mean we can remove part of the existing documentation? No, it will add a little there. Where it will cut down is the otherwise unending debate over the issue. Documentation is not just what you find on a single web page. What I don't understand is, that most people who have a problem with scope by indentation, want to introduce braces. I think braces are the worst solution. Python has clear constructs that mark where suites begin. There is no need for an extra open brace. So if you don't want to rely on indentation, something to mark the end of a suite would be sufficient. I personnaly don't like the forced indentation of python and its lack of endmarkers for suits/blocks. I also think it is not that a big deal. Just as I indent my code in languages that don't enforce it, I generally put in end markers when I program python. In the past that was just by using comments like: if ...: ... #end But lately I have been wondering about doing the following: end = None ... if ...: ... end IMO it looks better, but I'm reluctant because it suggest some checking by the compilor, which just doesn't happen. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Op 2005-12-06, Ben Sizer schreef [EMAIL PROTECTED]: [EMAIL PROTECTED] wrote: Just because a few people dislike something, doesn't make it a defect. Actually, it does. Whose definition of defect are we using? And how small a sample population are we going to require in order to find a 'something' which less than 'a few' people dislike? Where it will cut down is the otherwise unending debate over the issue. Documentation is not just what you find on a single web page. It will cut down debate but it would make the language more complex and less consistent. I don't think that's a price worth paying. And it might help bring Python into the mainstream. I'd much rather educate the mainstream to be able to see the benefits of this method, than drag Python down to meet them. ...things should be self-documenting and obvious. You simply can't do that with programming languages. Maybe not completely. Trust me though, we can do better. Of course. However I would argue that indented scope is one way of doing so. Scope is instantly visible, and no longer a game of 'hunt the punctuation character, which is in a different place depending on the coder's style'. There are situations in which indentation is not that visible. The problem is that situations arise where your code can't be read continuously. e.g. it can be spread over pages in a book. It isn't always clear whether the code on the new space is equally idented as the code on the previous space. Other situations arise where indentation alone isn't a clear indication of how many scopes are left. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Antoon Pardon [EMAIL PROTECTED] writes: But lately I have been wondering about doing the following: end = None ... if ...: ... end IMO it looks better, but I'm reluctant because it suggest some checking by the compilor, which just doesn't happen. I don't think you can always do that. try: ... end except blah: ... looks syntactically invalid. -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Paul Rubin a écrit : Antoon Pardon [EMAIL PROTECTED] writes: But lately I have been wondering about doing the following: end = None ... if ...: ... end IMO it looks better, but I'm reluctant because it suggest some checking by the compilor, which just doesn't happen. I don't think you can always do that. try: ... end except blah: ... looks syntactically invalid. You shouldn't put end before the except but after : try: ... except blah: ... end -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Antoon Pardon wrote: Op 2005-12-06, Ben Sizer schreef [EMAIL PROTECTED]: Of course. However I would argue that indented scope is one way of doing so. Scope is instantly visible, and no longer a game of 'hunt the punctuation character, which is in a different place depending on the coder's style'. There are situations in which indentation is not that visible. The problem is that situations arise where your code can't be read continuously. e.g. it can be spread over pages in a book. Write shorter functions ;) Other situations arise where indentation alone isn't a clear indication of how many scopes are left. No, but I find it's only a tiny bit worse than in C++/Java, where I usually find myself adding a comment at the end of a block anyway, just so that I remember what exactly is coming to an end at that point. (Although again, this might be telling me that my function is too big.) That transfers to Python where necessary. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Op 2005-12-07, Paul Rubin schreef http: Antoon Pardon [EMAIL PROTECTED] writes: But lately I have been wondering about doing the following: end = None ... if ...: ... end IMO it looks better, but I'm reluctant because it suggest some checking by the compilor, which just doesn't happen. I don't think you can always do that. try: ... end except blah: ... IMO this is the wrong way to use end. end should be used to mark the end of a compound statement, not the end of a suite. If a suite ending is already clear because the next clause of the compound statement is beginning, we don't need an extra marker to make that clear. So the above should be: try: ... except blah: ... end -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Op 2005-12-07, Ben Sizer schreef [EMAIL PROTECTED]: Antoon Pardon wrote: Op 2005-12-06, Ben Sizer schreef [EMAIL PROTECTED]: Of course. However I would argue that indented scope is one way of doing so. Scope is instantly visible, and no longer a game of 'hunt the punctuation character, which is in a different place depending on the coder's style'. There are situations in which indentation is not that visible. The problem is that situations arise where your code can't be read continuously. e.g. it can be spread over pages in a book. Write shorter functions ;) This has little to do with long functions. A class can contain a large number of methods, whitch are all rather short, and your class will still be spread over several pages. Other situations arise where indentation alone isn't a clear indication of how many scopes are left. No, but I find it's only a tiny bit worse than in C++/Java, where I usually find myself adding a comment at the end of a block anyway, just so that I remember what exactly is coming to an end at that point. (Although again, this might be telling me that my function is too big.) That transfers to Python where necessary. The fact that your function might be too long, doesn't change that a proper end marker can make the structure of your program more clearer for those reading the code. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Op 2005-12-07, Christophe schreef [EMAIL PROTECTED]:
Paul Rubin a écrit :
Antoon Pardon [EMAIL PROTECTED] writes:
But lately I have been wondering about doing the following:
end = None
...
if ...:
...
end
IMO it looks better, but I'm reluctant because it suggest
some checking by the compilor, which just doesn't happen.
I don't think you can always do that.
try:
...
end
except blah:
...
looks syntactically invalid.
You shouldn't put end before the except but after :
try:
...
except blah:
...
end
What I was wondering about. Some year back or longer someone
suggested a module he had written could help those who like
end markers.
He had written a function 'end' you could use as follows and
that would check if it ended the right block.
if ...:
...
end('if')
Can anyone recall? I have tried google to find it back, but
no luck. A pointer would be much appreciated.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
On Mon, 05 Dec 2005 05:16:04 -0800, JohnBMudd wrote: From The Design of Everyday Things, docs are a sign of poor design. Even a single word, such as the word Push on the face of a door, is an indication that the design can be improved. I find it ironic that you are using a book that documents design principles as evidence that using documentation is an indication of poor design. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
[EMAIL PROTECTED] wrote: ,, info cut However there is one thing I don't like in python, that is, scoping by indentation. But it would not annoy me so much that make me decide to implement a new language^_^. Regards, Limin I find these comments interesting. It is very common for people to complain about indentation. I have helped several very large companies create C++ coding standards. One common requirement is very fixed indentation rules. These rules are often encoded into lint-like tools. These tools treat indentation errors like compile time errors. These are often the same people that don't want to use python because it uses indentation .. It is humorous if stand back and look from a distance greater then 10 feet :-) Mike -- The greatest performance improvement occurs on the transition of from the non-working state to the working state. -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
On 2005-12-07, Antoon Pardon [EMAIL PROTECTED] wrote: What I don't understand is, that most people who have a problem with scope by indentation, want to introduce braces. I think braces are the worst solution. Braces are very convenient to match block start and end. Open a C program in the VI editor, and press % in command mode on some brace.. It will take you to its matching brace. How do you do something like that with python code (or any code that is based purely on indentation..) -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Zeljko Vrba [EMAIL PROTECTED] wrote: On 2005-12-07, Antoon Pardon [EMAIL PROTECTED] wrote: What I don't understand is, that most people who have a problem with scope by indentation, want to introduce braces. I think braces are the worst solution. Braces are very convenient to match block start and end. Open a C program in the VI editor, and press % in command mode on some brace.. It will take you to its matching brace. How do you do something like that with python code (or any code that is based purely on indentation..) By programming % to match indentation (in Python syntax mode) when the character under the cursor when % is hit is not a parenthesis, of course; much the same approach as you use to have it jump between opening and closing tags when you're editing an XML or HTML file, except that matching indentation may be somewhat easier. You can find many vim programming tips at www.vim.org much more easily than in this group (you CAN program vim with Python if you wish, rather than having to use vim's own scripting language, but for that you need to build VIM with Python scripting enabled in the first place). Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
So... Python is already flexible. It supports use of (1) tabs, (2) space or (3) a mix of tabs and space to indicate scope. Some people think this is too flexible. It should be cut back to tabs or spaces. The fewer people comfortable with Python, the better. It's better to be right than popular. Some people like it just as it is. Don't change ANYTHING! Some people (a lot of the ones that don't give Python a chance) want one more choice, braces. Is that so much to ask for? Does that pretty well sum it up? Thanks for the responses. I've been educated. John -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
[EMAIL PROTECTED] wrote: Some people like it just as it is. Don't change ANYTHING! search for NIMPY Some people (a lot of the ones that don't give Python a chance) want one more choice, braces. Is that so much to ask for? If you like curly brace style, there are always other scripting languages like javascript (rhino for the jvm) or groovy or others. If you like end statements style, there is always ruby or one of the basic dialects like visual basic or gambas, or see rexx dialects too like netrexx or oorexx. -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
[EMAIL PROTECTED] enlightened us with:
Some people (a lot of the ones that don't give Python a chance) want
one more choice, braces. Is that so much to ask for?
I say: use #{ and #} instead. If you want to have braces, what's wrong
with
if condition: #{
some statement
other statement
#}
I'm sure you can even teach editors to match on those braces.
Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa
--
http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
On Wed, 07 Dec 2005 07:58:55 -0800, JohnBMudd wrote: So... Python is already flexible. It supports use of (1) tabs, (2) space or (3) a mix of tabs and space to indicate scope. Some people think this is too flexible. It should be cut back to tabs or spaces. The fewer people comfortable with Python, the better. It's better to be right than popular. My understanding is that mixed spaces and tabs are discouraged because they are a potential source of hard-to-deal-with bugs. Although, I've never found any -- but perhaps I'm not looking hard enough. It is better to be right than wrong, and if the only way to be popular is to be wrong, well, that explains a lot. Fortunately, it isn't the only way. Some people like it just as it is. Don't change ANYTHING! Some people (a lot of the ones that don't give Python a chance) want one more choice, braces. Is that so much to ask for? Perhaps we could also add line numbers, for the old-style BASIC programmers before all those new-fangled sub-routines got added to the language, spoiling it for all time? Does that pretty well sum it up? Nah. What you forgot is, you can't please everyone, and nor should you try. Python is not designed by committee, and just because some random group of third-rate code peons like a feature, it doesn't mean that Python will get that feature. It may, if the feature is worthwhile, but pleasing barely literate code monkeys like me is *way* down the list of priorities for Guido. And that's good, because instead of me forcing my ignorant opinions and expectations onto Python, using a language designed by people who know more about computer science that I do has taught me skills I never would have discovered on my own. That doesn't mean I'm not allowed an opinion. But if I can't justify my opinion for why it is so important for Python to include line numbers, then my opinion counts for very little. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
On Wed, 07 Dec 2005 15:26:59 +, Zeljko Vrba wrote: Braces are very convenient to match block start and end. Open a C program in the VI editor, and press % in command mode on some brace.. It will take you to its matching brace. How do you do something like that with python code (or any code that is based purely on indentation..) (1) You don't need to, because you can *see* where the indentation changes, so you don't need to rely on your editor counting for you. (2) And if you do need to, then you should use a smarter editor that understands indentation levels, not just braces. Braces are superfluous if you use consistent indentation, and indentation is superfluous -- to the compiler -- if you use braces. But indentation is *not* superfluous to the human eye: we can parse indentation very easily, but nested braces/brackets only with great difficulty. That's why programmers in languages that ignore indentation still indent their code, or at least the sensible ones do. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Antoon Pardon wrote: Write shorter functions ;) This has little to do with long functions. A class can contain a large number of methods, whitch are all rather short, and your class will still be spread over several pages. Write classes with a smaller interface ;-) /David -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
[EMAIL PROTECTED] wrote: a decent description or tutorial... is better Sound good but... we're programmers, not documentation specialist or motivational speakers. Why, when I suggest fixing a design defect with code, do so many programmers want to respond with... documentation and arguments instead of code? You haven't suggested fixing a design defect. You've suggested changing part of the design. Just because a few people dislike something, doesn't make it a defect. I dislike child-proof medicine bottles, as they're a slight inconvenience to me, but they serve an important purpose. From The Design of Everyday Things, docs are a sign of poor design. Firstly, it's somewhat ironic that you have to cite a documented source to back up your point. Some things simply require being put into words. You make your point by referring to a book; I would make the case for scope-indentation by referring to a paragraph in the docs. Secondly, how is this at all relevant? Do you think that adding braces to Python will mean we can remove part of the existing documentation? That is the only logical conclusion to draw from what you're saying. Thirdly, is a programming language an Everyday Thing? Computer programs are, yes, but languages are not. They're targeted at a very specific audience and are geared towards a very complex task. There is only so much simplification that can be done before a tool becomes useless. The context of your quote is that that things should be self-documenting and obvious.You simply can't do that with programming languages. All you can do is try to make it as consistent as possible, so that there are few surprises and as little documentation as possible. Merging scope with indentation is one good example of doing this. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
On 2005-12-02, Micah Elliott [EMAIL PROTECTED] wrote: On Dec 02, Dave Hansen wrote: Python recognizes the TAB character as valid indentation. TAB characters are evil. They should be banned from Python source code. AGREE! AGREE! AGREE! The day TABs are banned from the source, I drop python forever. It took me too long to get used to indentation in the first place, now if you ban TABs (which make code formatting a whole lot easier), I'm dropping python. I've heard nice things about Ruby.. Maybe it's time to shift my primary scripting language. I already made transition perl-python, and now I'm observing pythong getting more and more hackish solutions and features.. -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Zeljko Vrba a écrit : On 2005-12-02, Micah Elliott [EMAIL PROTECTED] wrote: On Dec 02, Dave Hansen wrote: Python recognizes the TAB character as valid indentation. TAB characters are evil. They should be banned from Python source code. AGREE! AGREE! AGREE! The day TABs are banned from the source, I drop python forever. It took me too long to get used to indentation in the first place, now if you ban TABs (which make code formatting a whole lot easier), I'm dropping python. Editors make code formatting easier, not TABs. Maybe it's time to leave the 80s and use a code editor that works with you and not against you ;) -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Zeljko Vrba wrote: Python recognizes the TAB character as valid indentation. TAB characters are evil. They should be banned from Python source code. AGREE! AGREE! AGREE! The day TABs are banned from the source, I drop python forever. It took me too long to get used to indentation in the first place, now if you ban TABs (which make code formatting a whole lot easier), I'm dropping python. luckily, python's not developed by random posters on the comp.lang.python newsgroup, so I doubt you will ever have to drop Python for that reason... /F -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
[EMAIL PROTECTED] wrote: Just because a few people dislike something, doesn't make it a defect. Actually, it does. Whose definition of defect are we using? And how small a sample population are we going to require in order to find a 'something' which less than 'a few' people dislike? Where it will cut down is the otherwise unending debate over the issue. Documentation is not just what you find on a single web page. It will cut down debate but it would make the language more complex and less consistent. I don't think that's a price worth paying. And it might help bring Python into the mainstream. I'd much rather educate the mainstream to be able to see the benefits of this method, than drag Python down to meet them. ...things should be self-documenting and obvious. You simply can't do that with programming languages. Maybe not completely. Trust me though, we can do better. Of course. However I would argue that indented scope is one way of doing so. Scope is instantly visible, and no longer a game of 'hunt the punctuation character, which is in a different place depending on the coder's style'. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
It seems to me that the tabs-vs-spaces thing is really about who controls the indentation: with spaces, it's the writer, and with tabs, it's the reader. Agreed. if [scope by indent] really is scaring off potential converts, then a dumbed-down dialect of python which uses curly brackets and semicolons might be a useful evangelical tool. Yes, that's how I see it too. -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
D H wrote: How is that a problem that some editors use 8 columns for tabs and others use less? So what? A bigger problem I see is people using only 2 or 3 spaces for indenting. That makes large amounts of code much less readable. And of course it is a problem if you mix tabs and spaces at the beginning of the same line. Tabs are easier to type (one keystroke each) and lead to visually better results (greater indentation unless you like hitting 8 spaces for each indent level). Where does that misconception that 2-3 spaces for indenting makes things less readable come from? There was an article in Comm. of the ACM on research into readability back in 1984 or so, that indicated 2-4 spaces has very similar readability and 8 spaces significantly less than that. IIRC they took care of personal preferences/what one was used to in the research. So disallowing tabs which could be set to 8 spaces (positions?) does make sense to me. I switched from using 2 to using 4 spaces for Python recently, and the big pain was to deal with lines that no longer fitted in 80 columns :-( -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Tom Anderson wrote: Which is not to say that it's a bad idea - if it really is scaring off potential converts, then a dumbed-down dialect of python which uses curly brackets and semicolons might be a useful evangelical tool. If we're going to be creating evangelical tools, I think a decent description or tutorial explaining why scoping through indentation is a better idea, rather than capitulating to the ignorance of those who won't try something different. If you repeat a piece of functionality, you factor it out into a single function. If you repeat a piece of data, you normalise it into a separate table or object. If you consistently find yourself having to enter a new scope and indent at the same time, and close scopes and unindenting at the same time, the sensible approach is to combine these concepts into one. Surely any programmer worthy of the term can see benefits to the approach when it is not just mentioned as a bizarre and arbitrary limitation of the language. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
a decent description or tutorial... is better Sound good but... we're programmers, not documentation specialist or motivational speakers. Why, when I suggest fixing a design defect with code, do so many programmers want to respond with... documentation and arguments instead of code? From The Design of Everyday Things, docs are a sign of poor design. Even a single word, such as the word Push on the face of a door, is an indication that the design can be improved. Please, rethink the design instead of trying to compensate with more documentation. John -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
[EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: a decent description or tutorial... is better Sound good but... we're programmers, not documentation specialist or motivational speakers. Why, when I suggest fixing a design defect with code, do so many programmers want to respond with... documentation and arguments instead of code? From The Design of Everyday Things, docs are a sign of poor design. Even a single word, such as the word Push on the face of a door, is an indication that the design can be improved. Please, rethink the design instead of trying to compensate with more documentation. So, for instance, even a single character (like an opening or closing bracket or a semicolon) is an indication that the design can be improved. Please, rethink your opposition instead of trying to impose your design defect on a better, cleaner design. Seriously. What you call a design defect and what other call a design feature are one and the same. I will concede this much: I would like a guarantee that helpful software would not strip leading whitespace (as has happened with some mail clients), which trashes logic-by-indention. Alternatively, it might be useful to have brackets and semicolons to overcome sadistic software interactions, but I don't *really* expect Python to be willing and able to predict and prevent all the crazy things other programs might do. And I certainly hope that Python doesn't ever *require* the brackets and semicolons that add so little value and so much clutter. -- rzed -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
[EMAIL PROTECTED] wrote:
Where does that misconception that 2-3 spaces for indenting makes
things less readable come from? There was an article in Comm. of the
ACM on research into readability back in 1984 or so, that indicated 2-4
spaces has very similar readability and 8 spaces significantly less
than that. IIRC they took care of personal preferences/what one was
used to in the research. So disallowing tabs which could be set to 8
spaces (positions?) does make sense to me.
I switched from using 2 to using 4 spaces for Python recently, and the
big pain was to deal with lines that no longer fitted in 80 columns :-(
Bigger indentation steps *are* more obvious, but on the other
hand, smaller indentation allows you to use more indentation
levels without using up all of your line width. (Using more than
80 chars per line is typically a bad idea.)
In general, I find that you rarely need so many indentation
levels in Python as in e.g. C or C++. I rarely run out of line
width in Python, even though I use 4 space indents and use fairly
long names. Remember that you can freely break lines within pairs
of (), [] and {}, and that adjacent string literals are concatenated.
If you try to squeeze something like...
self.logger.log(log_level, Blaha bla bla bla bla
at: %s:%i caused a %s with message\n%s\n %
(file_name, row, error, error_message))
...into one line, it doesn't matter what indentation depth you use...
--
http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
even a single character (like an opening or closing bracket or a semicolon) is an indication that the design can be improved. Close, there are two principles for good design: Afford proper use and Don't afford improper use. I could argue that not having to type extra characters falls into the first category and so is part of why Python is a better design. Not having to type extra characters makes it easier (affords me) to enter source code in the first place and there's less to maintain in the long run. That's probably why nobody in the thread, including myself, has advocated *require* the brackets. But, like a lot of solutions, in solving one problem Python has created another one. Many people, for whatever reasons, feel that the solution (scope by indent) prevents them from using the tool. Hence Python has not really made it easier to type and maintain source code for the general audience, it's has only polarized the audience. There are many people who would say it definitely does NOT afford proper use. Python is the superior design, today. But, like Betamax tape format, Python isn't mainstream yet. And, sadly, maybe it never will be. I want that changed. I want Python to take over the world so I don't have to beg my next boss to let me use it. And if adding an optional dumbed-down format will help then that might be an improvement in the big picture. John -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Tom Anderson [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Which is not to say that it's a bad idea - if it really is scaring off
potential converts, then a dumbed-down dialect of python which uses curly
brackets and semicolons might be a useful evangelical tool.
I doubt it: a lot of people have asserted something similar over
the years but I don't remember anyone ever bothering to post
a patch (and if someone has it disappeared without a ripple).
I'm sure some folk can remember local coding styles that suggested
using BEGIN and END as macros for curly brackets in C because
{ and } aren't intuitive.
--
http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
[EMAIL PROTECTED] wrote: Python is the superior design, today. But, like Betamax tape format, Python isn't mainstream yet. And, sadly, maybe it never will be. I want that changed. I want Python to take over the world so I don't have to beg my next boss to let me use it. And if adding an optional dumbed-down format will help then that might be an improvement in the big picture. I couldn't disagree more. I most certainly do *not* want Python to take over the world. I want .NET and Java to prevail, so that large companies with money to throw away at such technologies will continue to do so, and so that I can still fly in under the radar to my small clients and be able to provide them with the simplest solution that works at a price they can afford and a price that I can live on. Having .NET and Java in the world makes me into more of a hero when I can swoop in and get the real business problem solved using Python. Now, say Python were to usurp everything else and become the dominant language. Everyone would learn Python. Python would become all the rage and get all the hype. Sun, Oracle, Microsoft, IBM, Apple, and SCO would all evangelize on their new Python initiatives. Microsoft would attempt to release their version with just a few non-standard things added on. Sun would sue them for not sticking with standards. Books and articles would be written. Middle-level management would start identifying places that Python is deficient in their eyes. CIO Insight would start making recommendations. Everyone would be pumping so much energy into so many different places that, like Java, Python would stall out and be consumed by its own hype, and the programmers that made Python what it is would burn out on it (read: they'd be busy counting all their stock options). Plus, there would now be a deluge of Python programmers in the market place, competing with my billing rate. No, I like Python just where it is, thank you very much. If someone doesn't want to give Python a second look because of their own bigoted ideas, I say Python doesn't want that type of person to begin with. Perhaps that sounds a bit elitist, but if people would just put their preconceptions aside, they'd quickly realize that Python really does get block indentation (and a whole host of other things besides) right. -- Paul McNett http://paulmcnett.com http://dabodev.com -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
[EMAIL PROTECTED] wrote: even a single character (like an opening or closing bracket or a semicolon) is an indication that the design can be improved. Close, there are two principles for good design: Afford proper use and Don't afford improper use. I could argue that not having to type extra characters falls into the first category and so is part of why Python is a better design. Not having to type extra characters makes it easier (affords me) to enter source code in the first place and there's less to maintain in the long run. That's probably why nobody in the thread, including myself, has advocated *require* the brackets. But, like a lot of solutions, in solving one problem Python has created another one. Many people, for whatever reasons, feel that the solution (scope by indent) prevents them from using the tool. Hence Python has not really made it easier to type and maintain source code for the general audience, it's has only polarized the audience. There are many people who would say it definitely does NOT afford proper use. Python is the superior design, today. But, like Betamax tape format, Python isn't mainstream yet. And, sadly, maybe it never will be. I want that changed. I want Python to take over the world so I don't have to beg my next boss to let me use it. And if adding an optional dumbed-down format will help then that might be an improvement in the big picture. But you don't want it to be Python, is all. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
If someone doesn't want to give Python a second look because of their own bigoted ideas, I say Python doesn't want that type of person to begin with. Some days I feel the same way. I've described Python as a filter where only the best get through. That's leads to a concentration of talent and good taste which has great value and can even eclipse any shortcomings in the flawed tool that initially drew the crowd together. This is from a paper I started a long time ago, entitled The Value of Bad Design. I never finished it but I do think it might be valid. John -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Richard Brodie wrote:
I'm sure some folk can remember local coding styles that suggested
using BEGIN and END as macros for curly brackets in C because
{ and } aren't intuitive.
Indeed. Meanwhile, see Tools/scripts/pindent.py in the Python source
code distribution for a tool which understands block end delimiters and
can output normal Python programs from those using such delimiters. It
can also perform the transformation in reverse, converting those
indentation-happy source files to the rigid world of the block
delimiter.
Paul
--
http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Richard Brodie enlightened us with:
I'm sure some folk can remember local coding styles that suggested
using BEGIN and END as macros for curly brackets in C because { and
} aren't intuitive.
I think that if you sink that low, you shouldn't be programming
anyway. Come on, if someone can't even grasp the concept of having
symbols and understand their meaning, how is such a person going to
write a proper program?
Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa
--
http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Paul McNett wrote: Having .NET and Java in the world makes me into more of a hero when I can swoop in and get the real business problem solved using Python. +1QOTW -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Rick Wotnaz wrote: So, for instance, even a single character (like an opening or closing bracket or a semicolon) is an indication that the design can be improved. Or a colon -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Meanwhile, see Tools/scripts/pindent.py Yes, thanks, that's very close to what I was thinking of. If it just went a little further and used semi-colons and braces then it would be complete. Granted, that might still not be enough for people who don't like scope by indent. It would be interesting though to see how people react to the option. Would they suddenly give Python a try or simply look for another excuse? Such a little program could make the test feasible. John -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
But you don't want it to be Python, is all. No, the opposite. I'm pro-Python but anti-stagnant, anti-dogma and anti-bad design. If Python never changes that will be okay too. It *is* great! John -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
[EMAIL PROTECTED] wrote: From The Design of Everyday Things, docs are a sign of poor design. Even a single word, such as the word Push on the face of a door, is an indication that the design can be improved. Please, rethink the design instead of trying to compensate with more documentation. This quote, with a naive reading, would seem to imply that needing documentation is evidence of bad design. I think we can all agree that this interpretation is ludicrous: the only programming language, for example, which does not need documentation is the natural language, and that contains so many ambiguities that humans often get instructions wrong. If nothing else, documentation is necessary to explain why X instead of Y, when both X and Y are perfectly valid, but mutually exclusive choices (CamelCase versus underscore_names). IMO, the correct interpretation of this reduces exactly to the principle of least surprise. If a door needs to have a sign that says push, it means that a fair number of people have looked at the door and thought it was a pull-door. But they expect it to be a pull-door based on /experience with other doors,/ not some odd Platonic ideal of door-osity. Some surprise, however, (especially in Python) is necessary because the same feature can be seen more than one way: see the ever-present discussion about func(arg=default) scoping of default arguments. While that's the way it is shouldn't cover up true design flaws, arbitrary replacement with another behaviour doesn't work either: the other way will, ultimately, need the same order of documentation to catch surprises coming from the other way. -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Christopher Subich wrote: [EMAIL PROTECTED] wrote: From The Design of Everyday Things, docs are a sign of poor design. Even a single word, such as the word Push on the face of a door, is an indication that the design can be improved. Please, rethink the design instead of trying to compensate with more documentation. This quote, with a naive reading, would seem to imply that needing documentation is evidence of bad design. I think we can all agree that this interpretation is ludicrous: the only programming language, for example, which does not need documentation is the natural language, and that contains so many ambiguities that humans often get instructions wrong. Indeed, there is only one user interface that needs no documentation whatsoever. -- Paul McNett http://paulmcnett.com http://dabodev.com -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
On Dec 5, 2005, at 3:13 PM, Paul McNett wrote: Indeed, there is only one user interface that needs no documentation whatsoever. Yeah, and it sucks! ;-) -- Ed Leafe -- http://leafe.com -- http://dabodev.com -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
the only programming language, for example, which does not need documentation is the natural language, and that contains so many ambiguities that humans often get instructions wrong. Natural languag (e.g. English) does not need documentation? Was there a shortage of big fat text books in your English department at school?? I know you don't mean to but you're making my point for me. John -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Richard Brodie wrote: I doubt it: a lot of people have asserted something similar over the years but I don't remember anyone ever bothering to post a patch people have posted more than just patches; see e.g. http://www.google.com/search?q=corbascript (and if someone has it disappeared without a ripple). /F -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
In [EMAIL PROTECTED], JohnBMudd wrote: 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Try this:: from __future__ import braces from __future__ import braces File stdin, line 1 SyntaxError: not a chance Thanks, that's funny. John -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Peter Decker [EMAIL PROTECTED] wrote: I'm starting to suspect that the same people who are zealous about spaces are also the same people who look down on anyone who doesn't agree with their choice of text editor. Text editors are like underwear. Everyone has their own favorite brand, and no rational argument will ever convince someone else to abandon their brand. -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Christopher Subich [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: From The Design of Everyday Things, docs are a sign of poor design. Even a single word, such as the word Push on the face of a door, is an indication that the design can be improved. Please, rethink the design instead of trying to compensate with more documentation. This quote, with a naive reading, would seem to imply that needing documentation is evidence of bad design. I think we can all agree that this interpretation is ludicrous: the only programming language, for example, which does not need documentation is the natural language, and that contains so many ambiguities that humans often get instructions wrong. My high school sophomore would strongly disagree with your assertion that natural language does not need documentation... Both The Design of Everyday Things and The Psychology of Everyday Things are fascinating books that should be mandatory reading for all engineering students. -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
On Dec 3, 2005, at 3:37 PM, Scott David Daniels wrote: They appear in different positions on different terminals (older hard- copy), Is anyone still using such devices to program Python? do different things on different OS's, Such as? I use OS X, Windows and Linux daily, and tabs work just fine on all of those. Which OS is it that is aberrant, and how exactly does it pose a problem? and in general do not behave nicely. Again, specifics would be welcome. I've been using tabs for indentation for over a decade, and have not once run into the horror stories that everyone who hates tabs says will happen, but who never give specifics as to how they cause problems. If you want to use spaces, great. I'm certainly not going to make up reasons why spaces are bad, just to make me feel better about my preference. Just don't make general damning comments without any specifics to back them up. -- Ed Leafe -- http://leafe.com -- http://dabodev.com -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
On Dec 3, 2005, at 5:55 PM, Sybren Stuvel wrote: That depends on your editor. Mine (vim) can be instructed to insert the appropriate amount of spaces on a tab, and remove them on a backspace. So let's say that you are using 4 spaces as your standard, but by accident type 5. You hit backspace, which deletes 4 spaces, and you now have to mentally compute the difference in order to keep things aligned. See, I can make up bizarre scenarios where spaces cause problems, too. -- Ed Leafe -- http://leafe.com -- http://dabodev.com -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Dave Hansen wrote: It's far more interesting to me _why_ people think indentation scoping is a bad thing. The answer I get back fall into two general categories: 1) I've heard/read/been told it's a bad thing, and 2) It causes portability problems. I can tell you why it freightened me at first: it made me think of the rigid formatting of Fortran 77 and to a lesser extent BASIC. But when I started working my way trough the tutorial, that fear very rapidly vanished. -- If I have been able to see further, it was only because I stood on the shoulders of giants. -- Isaac Newton Roel Schroeven -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
This is amazing. 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. And even amongst Python enthusiast who appreciate the feature (me included) we can't agree on how to use it. Python is too flexible. 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 and (2) add a formatting tool so I can reformat Python code to the correct style? Python is just a program, not a religion. Unless... Tabs really are evil. John -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Ed Leafe wrote: That depends on your editor. Mine (vim) can be instructed to insert the appropriate amount of spaces on a tab, and remove them on a backspace. So let's say that you are using 4 spaces as your standard, but by accident type 5. You hit backspace, which deletes 4 spaces, and you now have to mentally compute the difference in order to keep things aligned. See, I can make up bizarre scenarios where spaces cause problems, too. what's bizarre is that you're using an editor that don't understand how blocks work in the language you're editing. (in good python editor, tab means move to next indentation level and backspace over a virtual tab means move to previous indentation level. if indentation is represented by spaces or tabs or both in the resulting file is a serialization issue...) /F -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
you're about 10 years late The same could be said for hoping that the GIL will be eliminated. Utterly hopeless. Until... there was PyPy. Maybe now it's not so hopeless. -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
[EMAIL PROTECTED] wrote: 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. you're about 10 years late for this kind of trolling. /F -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Ed Leafe wrote: So let's say that you are using 4 spaces as your standard, but by accident type 5. You hit backspace, which deletes 4 spaces, Nope, it would delete a single space. Then an additional backspace would delete the 4. See, I can make up bizarre scenarios where spaces cause problems, too. Only if you don't know how decent editors behave. :) -- Benji York -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Ed Leafe enlightened us with: See, I can make up bizarre scenarios where spaces cause problems, too. You make me glad I'm always using tabs :) Sybren -- The problem with the world is stupidity. Not saying there should be a capital punishment for stupidity, but why don't we just take the safety labels off of everything and let the problem solve itself? Frank Zappa -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Benji York [EMAIL PROTECTED] writes: See, I can make up bizarre scenarios where spaces cause problems, too. Only if you don't know how decent editors behave. :) But the same is also true of tabs causing problems :-). mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
On 12/4/05, Mike Meyer [EMAIL PROTECTED] wrote: See, I can make up bizarre scenarios where spaces cause problems, too. Only if you don't know how decent editors behave. :) But the same is also true of tabs causing problems :-). I'm starting to suspect that the same people who are zealous about spaces are also the same people who look down on anyone who doesn't agree with their choice of text editor. -- # p.d. -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Peter Decker wrote: On 12/4/05, Mike Meyer [EMAIL PROTECTED] wrote: See, I can make up bizarre scenarios where spaces cause problems, too. Only if you don't know how decent editors behave. :) But the same is also true of tabs causing problems :-). I'm starting to suspect that the same people who are zealous about spaces are also the same people who look down on anyone who doesn't agree with their choice of text editor. Perhaps. As far as editor choice goes, I'm only fervent about people picking a good editor (equivalent to Vim or Emacs) and learning it well. Other than that I don't care. I'm not as diplomatic about tabs. :) -- Benji York -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
On Sun, 4 Dec 2005 [EMAIL PROTECTED] wrote: you're about 10 years late The same could be said for hoping that the GIL will be eliminated. Utterly hopeless. Until... there was PyPy. Maybe now it's not so hopeless. No - structuring by indentation and the global lock are entirely different kettles of fish. The lock is an implementation detail, not part of the language, and barely even perceptible to users; indeed, Jython and IronPython, i assume, don't even have one. Structuring by indentation, on the other hand, is a part of the language, and a very fundamental one, at that. Python without structuring by indentation *is not* python. Which is not to say that it's a bad idea - if it really is scaring off potential converts, then a dumbed-down dialect of python which uses curly brackets and semicolons might be a useful evangelical tool. tom -- 3118110161 Pies -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
On Fri, 2 Dec 2005, [EMAIL PROTECTED] wrote: Dave Hansen wrote: TAB characters are evil. They should be banned from Python source code. The interpreter should stop translation of code and throw an exception when one is encountered. Seriously. At least, I'm serious when I say that. I've never seen TAB characters solve more problems than they cause in any application. But I suspect I'm a lone voice crying in the wilderness. Regards, You're not alone. I still don't get why there is still people using real tabs as indentation. I use real tabs. To me, it seems perfectly simple - i want the line to be indented a level, so i use a tab. That's what tabs are for. And i've never, ever come across any problem with using tabs. Spaces, on the otherhand, can be annoying: using spaces means that the author's personal preference about how wide a tab should be gets embedded in the code, so if that's different to mine, i end up having to look at weird code. Navigating and editing the code with arrow-keys under a primitive editor, which one is sometimes forced to do, is also slower and more error-prone. So, could someone explain what's so evil about tabs? tom -- Space Travel is Another Word for Love! -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Tom Anderson wrote: On Fri, 2 Dec 2005, [EMAIL PROTECTED] wrote: Dave Hansen wrote: TAB characters are evil. They should be banned from Python source code. The interpreter should stop translation of code and throw an exception when one is encountered. Seriously. At least, I'm serious when I say that. I've never seen TAB characters solve more problems than they cause in any application. So, could someone explain what's so evil about tabs? They appear in different positions on different terminals (older hard- copy), do different things on different OS's, and in general do not behave nicely. On many (but not all) systems, they advance to the next column that is a multiple of 8, but not all, and people (and editors) use them freely to get to those positions, not understanding that they are not necessarily going to the same position. The fact that they provide an ambiguous display is enough to make them evil. --Scott David Daniels [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Scott David Daniels wrote: Tom Anderson wrote: So, could someone explain what's so evil about tabs? They appear in different positions on different terminals (older hard- copy), do different things on different OS's, and in general do not behave nicely. On many (but not all) systems, they advance to the next column that is a multiple of 8, but not all, and people (and editors) use them freely to get to those positions, not understanding that they are not necessarily going to the same position. The fact that they provide an ambiguous display is enough to make them evil. How is that a problem that some editors use 8 columns for tabs and others use less? So what? A bigger problem I see is people using only 2 or 3 spaces for indenting. That makes large amounts of code much less readable. And of course it is a problem if you mix tabs and spaces at the beginning of the same line. Tabs are easier to type (one keystroke each) and lead to visually better results (greater indentation unless you like hitting 8 spaces for each indent level). -- http://mail.python.org/mailman/listinfo/python-list
