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

2 views
Skip to first unread message

phoo...@gmail.com

unread,
Nov 28, 2005, 5:48:44 AM11/28/05
to
Dear all,

This is just to let you know that the lastest version Dao language is
released.
This Dao was previously called Tao, and now is changed to Dao to avoid
confusion
with another Tao langauge. There are a number of new features
implemented in
this version, of which the most important one is the supporting for
multi-threaded
programming. A new concurrent garbage collector is also implemented to
for the
multi-threaded interpreter. Now unicode is also supported for string
manipulation
and regular expression (regex) matching etc. The algorithm for regex
matching
is enhanced with fixing of a few bugs which prevent finding the most
reasonable
matching in some case, and allowing reverse matching from the end of
string.
The interface for creating Dao plugin in C++ is further simplified and
matured.
Of course, many bugs are also fixed. For more information,
please visite: http://www.xdao.org.

By the way, a console named DaoConsole with graphical user interface is
also released.

With best regards,

Limin Fu

-----------------------------
ChangLog for this release:
-----------------------------

+ : added
! : changed
* : fixed
- : removed

MULTITHREADING:
+ Multi-threaded programming is supported as a kernel feature of
Dao language. Posix thread library is used in the implementation.
And the thread API in Dao is similar to that in Posix thread.
Parts of the Dao interpreter is re-structured for multithreading.
+ A novel concurrent garbage collector based on reference counting
is implemented to support multithreading.
+ A upper bound for GC amount is applied to prevent memory "avalanche",
where mutators generate garbage faster than GC can collect them.
gcmin(), gcmax().

UNICODE:
+ UNICODE is supported. String quotated with double quotation symbol
is internally represented as Wide Character String(WCS), while string
quotated with single quotation symbol is internally represented
Multi Bytes String(MBS). Corresponding operations on WCS is also
supported.

REGEX:
+ Regex reverse matching is supported.
+ Now internal representation of Regex uses both MBS and WCS for both
efficiency and proper matching character class for unicode. When a
regex is applied to MBS or WCS, the corresponding representation is
used.
+ Regex datatype is added, a regex pattern can be compiled and stored
for later use, by using: define regex: rgx = /\d+\w/;
or, rgx = regex( "\\d+\\w" );
+ New character class abbreviations \u and \U are added for unicode.
+ Customized character class abbreviations are support. Users can
define
their own character class abbreviations by:
define regex: \2 = [WhateverChars];
! Algorithm for regex matching is modified to extend matching when
possible, and is also modified to match regex group correctly.

NUMERIC ARRAY:
+ Specification of precision in numeric array enumeration is supported:
num=[@{numtype} array];
! Transpose operator(right operator) is changed from ' to ~.
- Function convolute() for numeric arrays is removed.

EXTENDING AND EMBEDDING:
+ Some abstract classes are added for supporting easy embedding
of Dao interpreter ( the daoMain.cpp source file is an example
for embedding ).
+ Some wrapper classes for Dao data objects are provide in daoType.h
to faciliate the using of Dao data objects in plugins or other
programs in which Dao is embedded.
! A new technique is implemented to allow more tranparent passing
data between Dao interpreter and C++ modules. Creation of shadow
classes is also supported by the way.

IO:
+ Instead of using STL stream classes, new DaoStream classes are
added mainly for handling unicode in many places.
+ For file IO, more open modes such as "rwat" are supported, and
more methods such as eof(), seek(), tell() ... are implemented.
read() is enhanced such that it can read until meeting EOF.

OTHERS:
+ Multi inheritance is supported for OOP. And the passing parameters
and calling to parent constructor is simplified.
+ Negative subindex is supported for string.
+ Added a feature that allows using Alternate KeyWord (*.akw) to
write Dao scripts in non-english languages. The only requirement
is the character encoding for the .akw file must be the same as the
script files.
! Variable scope specification keyword "global" is added; keyword
"extern" is remove; keyword "share" is changed to "shared"
! Data states are added for constant and frozen data. Now a const
data is a really const, and can not be modified anymore. Function
freeze() is added to freeze some data structures as well as those
are reachable from them, to prevent them from being modified;
And defreeze() is added to defreeze them.
! The using namespace is simplified(compile(),eval(),source()).

Colin J. Williams

unread,
Nov 29, 2005, 8:24:29 AM11/29/05
to
How does Dao compare with Python? What does Dao permit one to do which
cannot conveniently be done in Python?

Colin W.

ssz...@netwvcom.com

unread,
Nov 30, 2005, 8:53:50 PM11/30/05
to pytho...@python.org
Please trim replies... ; )

--

Steve

phoo...@gmail.com

unread,
Dec 1, 2005, 6:26:36 AM12/1/05
to
The best way to compare Dao with Python in detail would be, join a SF
project PLEAC, and provide solutions in Dao to those common programming
problems listed in Perl Cookbook(by Tom Christiansen & Nathan
Torkington, published by O'Reilly). The solutions in Python is there,
when solutions in Dao would be available, one can quickly compare it
with other languages using PLEAC project. But unfortunately, I don't
have enough time to it. So I will spend some time to grab some examples
from python tutorials, and show how they can be done in Dao, but you
have to wait for some days :-)

For the second question, I will list some. First I should admit I don't
know well python, so maybe there are convenient solutions for something
that I think not convenient in python.

1. Multi-threaded programming:

In Dao, for any function or expression, one can evaluate them in an
independent thread as: thread.create( myfunc() ); or thread.create(
myexprs );

In python, probably one have to subclass from a thread class, and
reimplement a method (something like run(), if I remember correctly),
and then call that method.

In Dao, one can create and access thread specific data through a
hash/dictionary data structure thread.my["data_key"], which is thread
global. In python, I don't know how to do it yet.

2. Numeric array:
Dao have built-in numeric array type, one can create a numeric array in
the following ways:
array1 = [ 1, 2, 3 ]; # {1,2,3} will create a normal array
array2 = [ 0: 2 :4 ]; # create [0,2,4,6]
array3 = [5] : 1; # [1,1,1,1,1]
array4 = [3] : [1,2]; # [[1,2],[1,2],[1,2]]
...
one can use normal operators +,-,*,/,++,--, +=,-=,etc. to operate on
numeric array and scale number, or two numeric array of the same size,
or two numeric array with different size but constraint the operations
on specific elements by subindex. There are also other features make
operations on numeric array convenient.

I am sure python can do them, but I wonder if they are convenient.

3.Transient variable and "magic" functions:
Dao provides so called features such transient variable (composed of @
and digits) and "magic" functions, which are provided as a kind of
functionaly programming tools, and in particular, transient variable
provides an explicit control during implicit parameter passing in such
"magic" functions. I think this is not something available in python.

As exmaples:
sort( array, @1<@2 ); Or: sort( array, exprs( @1, @2 ) );
where @1 represents the first of the two elements for comparison during
sorting, and @2 represents the second. It will sort array so that any
two neighbors elements satisfy (if possible) the second expression in
sort().

iterate( array, exprs( @1 ) ); will iterate on array and execute the
expressions after the first parameter. Here @1 represents each element
of the array. This function can be nested, in this case one may use @1,
@2, @3 ...

These two features are even more useful in numeric array operations, I
will not show example here. If you want to find it out, please have a
look at the documentation for Dao.

4. Extending using C++:
To extend Dao, one must use C++ (at least as an intermediate
interface). However, the C++ to extend Dao is very simple, and
transparent. And one only need two header files to build a Dao plugin
WITHOUT linking to Dao library! I believe the extending of Dao using
C++ is much simpler and more convenient than python.

That's enough. If I say something wrong about python, please point out.

Limin

bearoph...@lycos.com

unread,
Dec 1, 2005, 8:46:25 AM12/1/05
to
>From "An Introduction to Dao":
>So I realized the goodness of scripting languages, and spent about two weeks to write some Perl scripts to retrieve informa- tion from GO and construct the DAG. But that experience with Perl was not very nice, because of its complicated syntax. Then I started to think about the possiblity to design a new language with simple syntax, and formed some rough ideas.<

Maybe trying Python requires less time :-)
But trying to implement new languages (like Dao, Boo, etc) is useful
because they can start again with fresh ideas and less legacy syntax
(and some of the new ideas can be backported to Python).


>sort( array, exprs( @1, @2 ) );

This @ syntax reminds me of a similar one into Mathematica. It can be
useful, but using lambdas is acceptable enough, I think.


>I believe the extending of Dao using C++ is much simpler and more convenient than python.<

If this is true, then this is an interesting (useful) advantage. Maybe
Python can learn something from Dao.

Bye,
bearophile

phoo...@gmail.com

unread,
Dec 1, 2005, 9:53:24 AM12/1/05
to
> Maybe trying Python requires less time :-)

Yes. Maybe if I tried python instead of perl, probably there would be
no Dao language :). 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

Bengt Richter

unread,
Dec 1, 2005, 11:47:28 PM12/1/05
to
On Wed, 30 Nov 2005 20:53:50 -0500, ssz...@netwvcom.com wrote:

>Please trim replies... ; )
>
Not quite so far ;-)

Regards,
Bengt Richter

John...@gmail.com

unread,
Dec 2, 2005, 1:08:21 PM12/2/05
to
Here it is again... Python bypassed/discounted because, of all things,
scoping by indentation!?!?

This used to surprise me. Until I hear more and more otherwise
reasonable programmers list this as their number one reason for
shunning Python.

I gauge design defects by how much after market
discussion/documentation a feature generates/requires. Scoping by
indentation is a whopper of a defect.

Could the PyPy people find some way (I don't how) to eliminate this
stumbling block going forward?? That is, after they eliminate the GIL!

John

Paul Boddie

unread,
Dec 2, 2005, 1:23:24 PM12/2/05
to
JohnBM...@gmail.com wrote:
> Here it is again... Python bypassed/discounted because, of all things,
> scoping by indentation!?!?

[...]

> Could the PyPy people find some way (I don't how) to eliminate this
> stumbling block going forward??

No: I believe they could only eliminate it "going backward". ;-)

Paul

P.S. I will admit that the first thing I do when editing someone else's
code (in any language) is to make sure the tab settings are sane in my
editor, but should basic editing skills really be so far beyond the
person/people entrusted with writing the software that runs your
business/organisation/lifestyle? Is Mr Rocket Scientist really
incapable of tying his own shoelaces?

Dave Hansen

unread,
Dec 2, 2005, 1:43:31 PM12/2/05
to
On 2 Dec 2005 10:08:21 -0800 in comp.lang.python, John...@gmail.com
wrote:

>Here it is again... Python bypassed/discounted because, of all things,
>scoping by indentation!?!?
>
>This used to surprise me. Until I hear more and more otherwise
>reasonable programmers list this as their number one reason for
>shunning Python.
>
>I gauge design defects by how much after market
>discussion/documentation a feature generates/requires. Scoping by
>indentation is a whopper of a defect.

FWIW, indentation scoping one one of the features that _attracted_ me
to Python.

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.

Of these, only (2) is valid. And the only reason it's valid is that
Python recognizes the TAB character as valid indentation. 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,
-=Dave

--
Change is inevitable, progress is not.

paulo....@gmail.com

unread,
Dec 2, 2005, 2:15:36 PM12/2/05
to
You're not alone.
The first thing I do after installing an IDE or programmers editor is
to change the configuration to use spaces as identantion.

I still don't get why there is still people using real tabs as
indentation.

--
Paulo

Dave Hansen wrote:
> On 2 Dec 2005 10:08:21 -0800 in comp.lang.python, John...@gmail.com
> wrote:

> ... (cutted)

Tony Nelson

unread,
Dec 2, 2005, 2:27:24 PM12/2/05
to
In article <8441p15lu4h7u0gd0...@4ax.com>,
Dave Hansen <id...@hotmail.com> wrote:

> On 2 Dec 2005 10:08:21 -0800 in comp.lang.python, John...@gmail.com
> wrote:
>
> >Here it is again... Python bypassed/discounted because, of all things,
> >scoping by indentation!?!?
> >
> >This used to surprise me. Until I hear more and more otherwise
> >reasonable programmers list this as their number one reason for
> >shunning Python.
> >
> >I gauge design defects by how much after market
> >discussion/documentation a feature generates/requires. Scoping by
> >indentation is a whopper of a defect.
>
> FWIW, indentation scoping one one of the features that _attracted_ me
> to Python.

Me too. Or rather, Python code is much more readable because every
nincompoop has to use indentation correctly whether they want to or not,
and I like readable code.
________________________________________________________________________
TonyN.:' *firstname*nlsnews@georgea*lastname*.com
' <http://www.georgeanelson.com/>

Micah Elliott

unread,
Dec 2, 2005, 4:04:13 PM12/2/05
to Dave Hansen, pytho...@python.org
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 interpreter should stop translation of code and throw an
> exception when one is encountered.

You could file a "Parser/Compiler" Feature Request for this (Hmm,
sf.net appears to have just renamed "Request For Enhancment" to
"Feature Request"). Seems the present enformencement of
disallowing tab/space mixing is with -t and -tt. From PEP-8
<URL:http://www.python.org/peps/pep-0008.html>:

...
Tabs or Spaces?

Never mix tabs and spaces. The most popular way of indenting
Python is with spaces only. ... Code indented with a mixture
of tabs and spaces should be converted to using spaces
exclusively. ... When invoking the python command line
interpreter with the -t option, it issues warnings about code
that illegally mixes tabs and spaces. When using -tt these
warnings become errors. These options are highly recommended!

For new projects, spaces-only are strongly recommended over
tabs. Most editors have features that make this easy to do.

If your "FR" is approved, -t and -tt could apply to any use of tabs.
+1 from me.

--
_ _ ___
|V|icah |- lliott <>< m...@micah.elliott.name
" " """

Gerhard Häring

unread,
Dec 2, 2005, 3:45:10 PM12/2/05
to pytho...@python.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Micah Elliott 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 interpreter should stop translation of code and throw an
>>exception when one is encountered.
>
>

> You could file a "Parser/Compiler" Feature Request for this [...]

Read PEP 666 first.

- -- Gerhard
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDkLJWdIO4ozGCH14RAiOyAJ4gNZrf5rjv5Cqk2cj/hFGXRaeCZwCdEL/X
ITGPnj6tXblSY1r04zS5djY=
=z37M
-----END PGP SIGNATURE-----

Simon Brunning

unread,
Dec 2, 2005, 4:22:12 PM12/2/05
to pytho...@python.org
On 12/2/05, Dave Hansen <id...@hotmail.com> wrote:
> FWIW, indentation scoping one one of the features that _attracted_ me
> to Python.

+1 QOTW

OK, it's a bit of a cliche. But it's a cliche because it's *true*.

--
Cheers,
Simon B,
si...@brunningonline.net,
http://www.brunningonline.net/simon/blog/

Inyeol Lee

unread,
Dec 2, 2005, 4:34:38 PM12/2/05
to pytho...@python.org
On Fri, Dec 02, 2005 at 09:45:10PM +0100, Gerhard Häring wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Micah Elliott 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 interpreter should stop translation of code and throw an
> >>exception when one is encountered.
> >
> >
> > You could file a "Parser/Compiler" Feature Request for this [...]
>
> Read PEP 666 first.
>

And this one too ;-)
http://www.artima.com/weblogs/viewpost.jsp?thread=101968

--Inyeol

Alexander Zatvornitskiy

unread,
Dec 2, 2005, 6:50:48 PM12/2/05
to
Hello, phoo...@gmail.com!

28 nov 2005 at 02:48, phoo...@gmail.com wrote:

p> This is just to let you know that the lastest version Dao language is
p> released.

Please wrote "hello world" example for us, and some more simple examples which
highlight major features of this language. I think, it is the best way to
evaluate new language.


Alexander, za...@bk.ru

Tom Anderson

unread,
Dec 3, 2005, 2:55:05 PM12/3/05
to
On Fri, 2 Dec 2005, paulo....@gmail.com 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!

Scott David Daniels

unread,
Dec 3, 2005, 3:37:31 PM12/3/05
to
Tom Anderson wrote:
> On Fri, 2 Dec 2005, paulo....@gmail.com 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
scott....@acm.org

D H

unread,
Dec 3, 2005, 4:54:23 PM12/3/05
to
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).

Sybren Stuvel

unread,
Dec 3, 2005, 5:55:37 PM12/3/05
to
D H enlightened us with:

> How is that a problem that some editors use 8 columns for tabs and
> others use less? So what?

I don't care either. I always use tabs, and my code is always
readable. Some people suggest one indents with four spaces, and
replaces eight spaces of indenting with a tab. Now _that_ is
irritating, since my editor's tab size is set to 4.

> Tabs are easier to type (one keystroke each)

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.

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

Ed Leafe

unread,
Dec 4, 2005, 3:25:32 AM12/4/05
to pytho...@python.org
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

Ed Leafe

unread,
Dec 4, 2005, 3:28:03 AM12/4/05
to pytho...@python.org
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.

Björn Lindström

unread,
Dec 4, 2005, 3:34:36 AM12/4/05
to
Ed Leafe <e...@leafe.com> writes:

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

This article should explain it:

http://www.jwz.org/doc/tabs-vs-spaces.html

--
Björn Lindström <bk...@stp.lingfil.uu.se>
Student of computational linguistics, Uppsala University, Sweden

Roel Schroeven

unread,
Dec 4, 2005, 5:36:20 AM12/4/05
to
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

Sybren Stuvel

unread,
Dec 4, 2005, 6:18:28 AM12/4/05
to
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 Stuvel

unread,
Dec 4, 2005, 6:32:58 AM12/4/05
to
Björn Lindström enlightened us with:

> This article should explain it:
>
> http://www.jwz.org/doc/tabs-vs-spaces.html

To me it doesn't. I use a single tab character for a single indent
levell. That is unambiguous, and also ensures the file is indented as
the reader likes it. People who have their tab size set to 'n' will
see n-space sized indents,

No matter what setting, the order of the indents is kept. This is not
the case if tabs and spaces are intermixed, as some style guides
suggest.

Fredrik Lundh

unread,
Dec 4, 2005, 6:40:19 AM12/4/05
to pytho...@python.org
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>

John...@gmail.com

unread,
Dec 4, 2005, 6:49:31 AM12/4/05
to
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

Fredrik Lundh

unread,
Dec 4, 2005, 6:59:07 AM12/4/05
to pytho...@python.org
John...@gmail.com 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>

John...@gmail.com

unread,
Dec 4, 2005, 8:29:26 AM12/4/05
to
> 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.

Benji York

unread,
Dec 4, 2005, 9:01:12 AM12/4/05
to pytho...@python.org
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

Lee Harr

unread,
Dec 4, 2005, 12:24:27 PM12/4/05
to
> No matter what setting, the order of the indents is kept. This is not
> the case if tabs and spaces are intermixed, as some style guides
> suggest.
>


I have never seen anyone suggest mixing tabs and spaces, and I
have read a lot of tabs-vs-spaces flamewars in my time.

Everyone agrees that mixing is bad. I might even go so far as to
say that the only real problem is mixing. The question is, if we
are trying to pick only one, which one causes fewer problems.

For me, it is spaces.

(oh, and unix line endings ;o)

Peter Decker

unread,
Dec 4, 2005, 2:02:25 PM12/4/05
to pytho...@python.org
On 12/4/05, Lee Harr <l...@example.com> wrote:

> Everyone agrees that mixing is bad. I might even go so far as to
> say that the only real problem is mixing. The question is, if we
> are trying to pick only one, which one causes fewer problems.
>
> For me, it is spaces.

Why is it that the only people who complain about this issue, and who
act all religious and self-righteous about it, are the ones who prefer
spaces?

I never cared one way or the other; I just used spaces because it
seemed that everyone else did. I recently switched to tabs because I'm
working a lot in Dabo, and they use tabs as their standard. But I must
say that listening to the space-zealots here has turned me off to
their arguments. My rule-of-thumb is that people only resort to such
zealotry when they have nothing better to offer. I've *never* seen any
of the problems they cite, and I hate to say how long I've been
around.

--

# p.d.

Mike Meyer

unread,
Dec 4, 2005, 2:33:47 PM12/4/05
to
Benji York <be...@benjiyork.com> 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 <m...@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

Peter Decker

unread,
Dec 4, 2005, 3:11:05 PM12/4/05
to pytho...@python.org
On 12/4/05, Mike Meyer <m...@mired.org> 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.

Benji York

unread,
Dec 4, 2005, 4:00:02 PM12/4/05
to Peter Decker, pytho...@python.org
Peter Decker wrote:
> On 12/4/05, Mike Meyer <m...@mired.org> 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

Tom Anderson

unread,
Dec 4, 2005, 5:00:18 PM12/4/05
to
On Sun, 4 Dec 2005, [utf-8] Björn Lindström wrote:

> This article should explain it:
>
> http://www.jwz.org/doc/tabs-vs-spaces.html

Ah, Jamie Zawinski, that well-known fount of sane and reasonable ideas.

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. Does that match up with people's attitudes? Is it the case that
the space cadets want to control how their code looks to others, and the
tabulators want to control how others' code looks to them?

I wonder if there's a further correlation between preferring spaces to
tabs and the GPL to the BSDL ...

tom

Lexicographical PS: 'tabophobia' is, apparently, fear of the
neurodegenerative disorder tabes dorsalis.

--
3118110161 Pies

Tom Anderson

unread,
Dec 4, 2005, 5:15:59 PM12/4/05
to

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

Steven D'Aprano

unread,
Dec 4, 2005, 10:48:33 PM12/4/05
to
Björn Lindström wrote:

> Ed Leafe <e...@leafe.com> writes:
>
>
>>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".
>
>
> This article should explain it:
>
> http://www.jwz.org/doc/tabs-vs-spaces.html


Not even *close* to explaining it. The author doesn't
mention a single problem that happens because of using
tabs. He doesn't even try to explain what Bad Things
could happen. He just *assumes* that Tabs Are Bad, M'kay.

He says:

"My opinion is that the best way to solve the technical
issues is to mandate that the ASCII #9 TAB character
never appear in disk files"

How nice. And his option is worth the photons I read
them by why? It is possible that Jamie Zawinski has the
best, most logical, inarguable reasons for his opinion.
But we mere mortals will never know what those reasons
are from his essay, because he doesn't tell us.


He also says:

"I just care that two people editing the same file use
the same interpretations"

which is fair enough

"and that it's possible to look at a file and know what
interpretation of the TAB character was used, because
otherwise it's just impossible to read."

"Impossible to read" hey? That wouldn't be just a teeny
tiny overstatement, perhaps?

Out of curiosity, finding a line of text indented with
spaces (say, " "), how do you know whether that
is meant to be a single 8-space indent, two 4-space
indents, or even eight 1-space indents? Perhaps if it
is a Python program you might be able to infer correct
indentation from the program structure, but in an
arbitrary free-form text file... well, perhaps all text
files with indents are "impossible to read".

It seems to me that "one tab per indent level" is far
more logical than "some arbitrary number, N, of spaces,
often a multiple of eight, or four, or two, per indent
level, and hope that the number of spaces is a multiple
of that arbitrary N". But maybe that's just me.


He also describes tabs characters being used "for
compression". That's a strange argument -- it *assumes*
that the "real" indent is N spaces, and that an ASCII 9
tab is some sort of faux replacement. Is it not just as
likely that tabs are the real deal, and N spaces is
some sort of tab expansion?

Of course, having told the reader that ASCII 9
characters should be prohibited from text files, it
makes the author's original disclaimer "I'm trying to
avoid espousing my personal religion here" rather amusing.


For the record, I started using tabs, shifted to using
spaces because it was "recommended", got frustrated
with having to hit multiple key presses to indent and
deindent (I use lots of different editors, ranging from
kwrite to gedit to nano and even, may Wodan help me,
Windows Notepad -- not only do some editors *not* allow
auto conversion of tabs, but the ones that do are
annoyingly inconsistant in how -- and whether -- they
work), went back to tabs, got frustrated with people
complaining that indentation was being mangled by
various webmail and News clients (I never saw it
myself, mind), and went back to spaces again. I'm now
feeling sufficiently frustrated that I'm seriously
thinking of changing back to tabs, and people using
brain-dead News readers can change their client instead
of telling me to change my editor.

I'm almost fired up enough about this to start the
Society For The Treatment Of Tabs As First Class
Characters. *wink*


--
Steven.

Sybren Stuvel

unread,
Dec 5, 2005, 3:18:53 AM12/5/05
to
Steven D'Aprano enlightened us with:

> It seems to me that "one tab per indent level" is far more logical
> than "some arbitrary number, N, of spaces, often a multiple of
> eight, or four, or two, per indent level, and hope that the number
> of spaces is a multiple of that arbitrary N". But maybe that's just
> me.

It's me too. One tab per indent makes perfect sense.

> went back to tabs, got frustrated with people complaining that
> indentation was being mangled by various webmail and News clients

This is about the only place where I use four spaces (typed as one
tab, expanded by Vim): email and Usenet. The reason? I don't want my
post to become too wide. If my stuff is read by someone with tab sizes
larger than four, it might become too wide, so to prevent that I use
spaces. For all other things (like real source code instead of a
pasted snippet) I use tabs.

> I'm almost fired up enough about this to start the Society For The
> Treatment Of Tabs As First Class Characters. *wink*

LOL count me in ;-)

John...@gmail.com

unread,
Dec 5, 2005, 4:53:36 AM12/5/05
to
> 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.

ant...@mnt.org

unread,
Dec 5, 2005, 4:59:07 AM12/5/05
to

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

Ben Sizer

unread,
Dec 5, 2005, 5:01:57 AM12/5/05
to
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

John...@gmail.com

unread,
Dec 5, 2005, 8:16:04 AM12/5/05
to
> 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

Rick Wotnaz

unread,
Dec 5, 2005, 10:17:32 AM12/5/05
to
John...@gmail.com wrote in
news:1133788564.1...@g49g2000cwa.googlegroups.com:

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

Magnus Lycka

unread,
Dec 5, 2005, 10:16:24 AM12/5/05
to
ant...@mnt.org 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...

John...@gmail.com

unread,
Dec 5, 2005, 11:11:36 AM12/5/05
to
> 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

Richard Brodie

unread,
Dec 5, 2005, 11:20:46 AM12/5/05
to

"Tom Anderson" <tw...@urchin.earth.li> wrote in message
news:Pine.LNX.4.62.05...@urchin.earth.li...

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


Paul McNett

unread,
Dec 5, 2005, 11:39:13 AM12/5/05
to pytho...@python.org
John...@gmail.com 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

Steve Holden

unread,
Dec 5, 2005, 11:24:42 AM12/5/05
to pytho...@python.org
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/

John...@gmail.com

unread,
Dec 5, 2005, 12:29:27 PM12/5/05
to
> 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

Paul Boddie

unread,
Dec 5, 2005, 1:15:46 PM12/5/05
to
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

Sybren Stuvel

unread,
Dec 5, 2005, 1:32:59 PM12/5/05
to
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?

Christopher Subich

unread,
Dec 5, 2005, 1:40:17 PM12/5/05
to
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

D H

unread,
Dec 5, 2005, 2:37:45 PM12/5/05
to
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

John...@gmail.com

unread,
Dec 5, 2005, 2:41:42 PM12/5/05
to
> 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

John...@gmail.com

unread,
Dec 5, 2005, 2:46:05 PM12/5/05
to
> 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

Christopher Subich

unread,
Dec 5, 2005, 2:56:18 PM12/5/05
to
John...@gmail.com 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.

Paul McNett

unread,
Dec 5, 2005, 3:13:55 PM12/5/05
to pytho...@python.org
Christopher Subich wrote:
> John...@gmail.com 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.

Ed Leafe

unread,
Dec 5, 2005, 3:25:33 PM12/5/05
to pytho...@python.org
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


John...@gmail.com

unread,
Dec 5, 2005, 3:31:55 PM12/5/05
to
> 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

Fredrik Lundh

unread,
Dec 5, 2005, 3:34:28 PM12/5/05
to pytho...@python.org
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 poste