A Suggestion for Python Colon Syntax
William Djaja Tjokroaminata
I have been using Python for some time, and I have a suggestion for the
Python Colon (:) syntax.
I have used C/C++, Tcl/Tk, Perl, etc., and really one thing that I like
about Python is its indentation-based syntax. Sure, we cannot write
one-liners like what Perl is famous for, but the code layout looks
beautiful, because I don't have to type { and } blocks which result
in various formatting conventions in C/C++. Also the fact that we don't
have to write ( and ) after if, for, etc., is wonderful, because the code
has less "punctuation" and looks more clean.
However, a lot of time when I ran my Python program, I got syntax error,
because I forgot to put colon (:) after my if (or for, etc.) clause. My
question is, is the colon really necessary, syntactically, in
Python? Because Python is line-and-indentation-based, can we just
eliminate the colons after the if, for, etc., clause?
My suggestion is as follows:
1) If the if (or for, etc.) clause is followed by a block, then the colon
is optional (for backward compatibility):
if condition is true
statement_1
statement_2
....
2) If the if (or for, etc.) clause is followed only by a single statement,
then the colon can be used to write a single line of code:
if condition is true: statement_1
next_statement
....
Any comments, anyone?
Regards,
Bill
Fredrik Lundh
> However, a lot of time when I ran my Python program, I got syntax
> error, because I forgot to put colon (:) after my if (or for, etc.) clause.
> My question is, is the colon really necessary, syntactically, in Python?
Short answer: The colon isn't there for the computer, it's
there for human readers. Just like the colons in your post:
> My suggestion is as follows:
>
> 1) If the if (or for, etc.) clause is followed by a block, then the colon
> is optional (for backward compatibility):
>
> if condition is true
> statement_1
> statement_2
> ....
(Using colons and indentations in the same way as in other written
languages is just one of many ideas Python has borrowed from the
ABC language: http://www.cwi.nl/~steven/abc )
:::
Longer answer: ... nah, I'll leave that to the "while true" crowd.
I'm sure they'll keep you entertained until the end of next year!
:::
Happy holidays, everyone!
</F>
William Djaja Tjokroaminata
: "William Djaja Tjokroaminata" wrote:
:> However, a lot of time when I ran my Python program, I got syntax
:> error, because I forgot to put colon (:) after my if (or for, etc.) clause.
:> My question is, is the colon really necessary, syntactically, in Python?
: Short answer: The colon isn't there for the computer, it's
: there for human readers. Just like the colons in your post:
Well, the colons in my post is because I am writing in English. But
Python does not have semicolon etc, just to make it "pretty", but they do
have consequences if they are omitted. I personally don't see how the
colon help me more in distinguishing the clause from the body of the
clause when reading a Python code, because the indentation is supposed to
be the marker.
:> My suggestion is as follows:
:>
:> 1) If the if (or for, etc.) clause is followed by a block, then the colon
:> is optional (for backward compatibility):
:>
:> if condition is true
:> statement_1
:> statement_2
:> ....
: (Using colons and indentations in the same way as in other written
: languages is just one of many ideas Python has borrowed from the
: ABC language: http://www.cwi.nl/~steven/abc )
Well, I don't know the rest of the people who use Python, but I
personally don't know anything about the ABC language. If a feature is
borrowed from C or Java or Perl, I think it is good. But a feature that
seems to add nothing from an obscure language to me is questionable.
: :::
: Longer answer: ... nah, I'll leave that to the "while true" crowd.
: I'm sure they'll keep you entertained until the end of next year!
I am waiting, everyone....
: :::
: Happy holidays, everyone!
: </F>
Bill
Tim Peters
> ...
> However, a lot of time when I ran my Python program, I got syntax error,
> because I forgot to put colon (:) after my if (or for, etc.) clause. My
> question is, is the colon really necessary, syntactically, in
> Python? Because Python is line-and-indentation-based, can we just
> eliminate the colons after the if, for, etc., clause?
Python's indentation rules are inherited from the ABC language (Guido was a
member of the ABC implementation team). The ABC designers tried several
styles of denoting block structure, and ran usability studies with newbies
to determine which were easiest to learn.
Guido reported that indentation worked best in these studies, but--
curiously enough! --only if the line immediately preceding the new block
ended with a colon. And that's why Python requires the colon too: it's not
because the parser needs it, but because a study once concluded *people* do
better with it.
> My suggestion is as follows:
^
> 1) If the if (or for, etc.) clause is followed by a block, then the
> colon is optional (for backward compatibility):
^
> ...
Also curious: you never forget the colon at the ends of your introductory
sentences <wink>.
without-a-colon-life-itself-is-impossible-ly y'rs - tim
Fredrik Lundh
> If a feature is borrowed from C or Java or Perl, I think it is good. But
> a feature that seems to add nothing from an obscure language to me
> is questionable.
oops. methinks you should read up on Python's history...
start here:
http://www.python.org/doc/essays/foreword.html
"I decided to write an interpreter for the new scripting
language I had been thinking about lately: a descendant
of ABC that would appeal to Unix/C hackers. I chose
Python as a working title for the project /.../
(incidentally, that text also talks a lot about readability...)
</F>
David Allen
<bil...@y.glue.umd.edu> wrote:
> My suggestion is as follows:
>
> 1) If the if (or for, etc.) clause is followed by a block, then the
> colon
> is optional (for backward compatibility):
>
> if condition is true
> statement_1 statement_2
> ....
>
> 2) If the if (or for, etc.) clause is followed only by a single
> statement,
> then the colon can be used to write a single line of code:
>
> if condition is true: statement_1 next_statement
> ....
>
> Any comments, anyone?
Me, I always want the colon to be there for one
simple reason: python-mode.el and emacs knows that
when I have a : on the end of a line, the next line
should be indented, and it does it for me. :)
Sure, that's not a *language* reason for wanting the
colon there, but it's a reason. :)
--
David Allen
http://opop.nols.com/
----------------------------------------
Q: What can a goose do, a duck can't, and a lawyer should?
A: Stick his bill up his ass.
D-Man
> Fredrik Lundh <fre...@effbot.org> wrote:
> : "William Djaja Tjokroaminata" wrote:
> :> However, a lot of time when I ran my Python program, I got syntax
> :> error, because I forgot to put colon (:) after my if (or for, etc.) clause.
> :> My question is, is the colon really necessary, syntactically, in Python?
>
> : Short answer: The colon isn't there for the computer, it's
> : there for human readers. Just like the colons in your post:
>
> Well, the colons in my post is because I am writing in English. But
> Python does not have semicolon etc, just to make it "pretty", but they do
Umm, actually you can put a semicolon at the end of each line (or only
some lines) and it will behave like the semicolon in C/C++/Java/Perl.
It is really useful (needed) if you wanted to write 2 statements on 1
line. I don't know why that would be needed, but . . .
-D
Jay O'Connor
>It is really useful (needed) if you wanted to write 2 statements on 1
>line. I don't know why that would be needed, but . . .
This is useful for small anonymous functions such as used for filter()
and map().
Take care,
--
Jay O'Connor
joco...@cybermesa.com
http://www.cybermesa.com/~joconnor
"God himself plays the bass strings first when He tunes the soul"
William Djaja Tjokroaminata
*needed*. My suggestion is to make it *optional*, like the semicolon at
the end of statements.
Yes, for people who cares about making it easier to read for newbies, they
can always put colons. Yes, for people who use emacs to automatically
indent the next line, they can put colons too.
However, as Guido wrote that he wanted an ABC that appeals to Unix/C
users, one of the unix designs is its minimalist style in terms of command
or syntax. To me, I like Python because when I want to create a function
I just write def as the first keyword and the rest follows, without much
punctuation. However, from time to time, the colons always make me come
back to fix them. For me personally, deleting the colons do not change
the readability of the code at all. Probably the study should be
conducted not only on the newbies, but also on people who have programmed
for a long time. Besides, fewer keystrokes are always better, in my
opinion. Unix C shell does not require colons for the clauses.
Therefore, my suggestion is really not to remove the colons, but to make
them optional. I want opinion of you who have programmed for a long time
whether there will be some harms if the colons are made optional. If not,
probably someone can tell me how I can forward this suggestion to the core
Python development team?
Regards,
Bill
Aahz Maruch
William Djaja Tjokroaminata <bil...@z.glue.umd.edu> wrote:
>
>I saw many replies that give the reasons why the colons are
>*needed*. My suggestion is to make it *optional*, like the semicolon at
>the end of statements.
>
>Yes, for people who cares about making it easier to read for newbies, they
>can always put colons. Yes, for people who use emacs to automatically
>indent the next line, they can put colons too.
Did you *read* the URL Fredrik gave you? What part of forcing
programmers to write intelligible code do you not understand?
--
--- Aahz (Copyright 2000 by aa...@pobox.com)
Androgynous poly kinky vanilla queer het <*> http://www.rahul.net/aahz/
Hugs and backrubs -- I break Rule 6
I don't really mind a person having the last whine, but I do mind
someone else having the last self-righteous whine. --Aahz
Nathaniel Gray
> Hi all,
>
> I have been using Python for some time, and I have a suggestion for the
> Python Colon (:) syntax.
>
> [snip suggestion for removing the colon (what an evocative sentence!)]
>
> Any comments, anyone?
I understand this problem of forgetting to care for your colons, but
perhaps seeking to change the language is the wrong path. Although "colon
neglect" is a common problem, I don't think you'll find a lot of support
for purging the colon, particularly from Guido. Without Guido's support
there's just no hope of changing Python's syntax.
What you might consider instead is customizing your text editor. Write a
macro that gets executed every time you hit enter that does the following
with the previous line:
1. If the first word is not {if, for, def, etc...} then return
2. Ignore all comments for the following three steps
3. If there is a colon on the line already, return
4. If the last character on the line is "\" then return
5. If the parens, brackets, and braces don't balance then return
6. Insert a colon after the last non-comment character
Note that this is just a first stab at the problem and it definitely won't
always work right (e.g. multi-line strings), but it will cure 90% of colon
neglect cases without a Python parser or a costly hospital visit.
Extending it to work for multi-line "colon statements" is left as an
excercise for the reader.
If you're stuck with an editor that you can't or don't know how to tweak,
try NEdit (http://www.nedit.org) instead. It has a nice Python mode and is
imminently scriptable.
maybe-they-shoulda-called-it-the-appendix-instead-ly y'rs - n8
--
_.~'^`~._.~'^`~._.~'^`~._.~'^`~._.~'^`~._
Nathaniel Gray
California Institute of Technology
Computation and Neural Systems
n8gray <at> caltech <dot> edu
_.~'^`~._.~'^`~._.~'^`~._.~'^`~._.~'^`~._
Alex Martelli
news:mailman.977429044...@python.org...
>
> >It is really useful (needed) if you wanted to write 2 statements on 1
> >line. I don't know why that would be needed, but . . .
>
> This is useful for small anonymous functions such as used for filter()
> and map().
'Anonymous functions' in Python are normally lambdas, which are
only made up of one expression (no statements); I guess one _might_
construct a 'small anonymous function' via module new, but even then,
I can't quite see how constructing the needed codeobject is specifically
eased by '2 statements on 1 line'.
As I see things, the option to put 2 statements on one line has the
specifical stylistic benefit of letting _me_, as a programmer, decide
how I want to best invest a scarce resource -- the number of program
lines I can comfortably view onscreen at once (ability to read and
follow a given function or class drops rapidly if it doesn't fit for
reading on 1 or 2 screenfuls; yet a few strategically placed empty
lines, comments, docstrings, might be a better investment of that
resource for clarity purposes).
However, the strongly dominant default Python style does _not_
include this usage -- one has to be aware of that... if one's code
is meant for others' consumption, following strongly established
precedents has its own advantages!-)
Alex
Alex Martelli
news:91trir$52l$1...@hecate.umd.edu...
[snip]
> Therefore, my suggestion is really not to remove the colons, but to make
> them optional. I want opinion of you who have programmed for a long time
> whether there will be some harms if the colons are made optional. If not,
Speaking as somebody who has been programming for a quarter of a century,
and who's fallen wildly in love with Python since about 18 months ago (and
_deeply_ appreciates by far most of its features, syntactical, semantical,
and
pragmatical), I don't think there would be any harm in making the colons
optional. Although they've become second nature for me after most of the
block-starting statements, I keep forgetting to put one after the mandatory
closing parens of each def-statement. In a language so spare of useless
punctuation as Python most often is, there's something "against the grain"
in having to write as many as _three_ punctuation marks at the end of
a function definition, as in:
def somefun():
...
Nothing major, mind you -- the compiler rapidly lets me know each and
every time I forget!-)
> probably someone can tell me how I can forward this suggestion to the core
> Python development team?
I _think_ feature requests can be placed on python.sourceforge.net,
although there may not be a specific place for them that's very
apparent -- but if you file a 'bug' I believe you can characterize it
as a feature-request.
Alex
Tim Peters
> I saw many replies that give the reasons why the colons are
> *needed*.
Not mine: it told you why the colons are *there*. It's a human-factors
thing, not a tech thing. Desirable, not necessary.
> My suggestion is to make it *optional*, like the semicolon at
> the end of statements.
Understood. Won't happen, though: Python has been around for a decade. Do
you imagine that Guido hasn't heard this suggestion before? In fact there
are very few "new syntax" ideas that weren't debated and rejected before
1991 ended. And, yes, this is one of them (ditto the whole "while 1" thread
that's been going on virtually non-stop for a decade).
> Yes, for people who cares about making it easier to read for newbies,
> they can always put colons. Yes, for people who use emacs to
> automatically indent the next line, they can put colons too.
Guido abhors gratuitous variations in coding sytle; that's largely why
indentation is used instead of curly braces or begin/end to begin with. A
choice about whether or not to use a colon is simply not something people
*need*. The few places Python allows gratuitous choices today are places
Guido regrets (although not enough to lose sleep over <wink>). For example,
Guido is unhappy that both "<>" and "!=" are accepted to mean "not equal";
the older "<>" survives only for compatibility with a very early release of
the language.
> ...
> I want opinion of you who have programmed for a long time whether
> there will be some harms if the colons are made optional.
It's Pythonic to either always require them or never allow them; the former
won 10 years ago.
> If not, probably someone can tell me how I can forward this
> suggestion to the core Python development team?
You already did <wink> -- Guido's on vacation this week, which makes me as
close as you'll get until after Christmas. You can submit a formal feature
request via the SourceForge bug manager at:
http://sourceforge.net/bugs/?group_id=5470
but you should expect it to be rejected. Besides that Guido will object on
principle, the practical support costs of adding such a thing are enormous:
editing environments from the Emacs Python mode to IDLE would be broken, and
would be difficult to fix. For a hint as to why it's difficult, study
tokenize.py in the std library. That trailing colon makes partial parsing a
whole lot easier, and especially when parsing backwards (as e.g. the Emacs
python-mode and IDLE and PythonWin need to do routinely).
if (a,
b,
c) != \
(d,
e,
f)
(a,
b,
c) = \
(d,
e,
f)
ly y'rs - tim
Brad Clements
news:mailman.977446446...@python.org...
> Guido abhors gratuitous variations in coding sytle; that's largely why
> indentation is used instead of curly braces or begin/end to begin with. A
> choice about whether or not to use a colon is simply not something people
> *need*. The few places Python allows gratuitous choices today are places
> Guido regrets (although not enough to lose sleep over <wink>). For
example,
> Guido is unhappy that both "<>" and "!=" are accepted to mean "not equal";
> the older "<>" survives only for compatibility with a very early release
of
> the language.
Horrors, I just checked some of my code and find that I use both != and <>
in the same module!
I don't know why.. Python is so easy to write for, I just use whatever is
easier to type, so if my hands are low on the keyboard, out comes <> ..
hands higher up then !=
I think I'll stick with <>, but then I'll have to *think* about the syntax,
rather than the algorithm.. something I normally don't have to do in
Python.. What a lovely language.
William Djaja Tjokroaminata
: [William Djaja Tjokroaminata]
:> I saw many replies that give the reasons why the colons are
:> *needed*.
: Not mine: it told you why the colons are *there*. It's a human-factors
: thing, not a tech thing. Desirable, not necessary.
Exactly. I just regretted the initial study that used newbies and they
preferred colons. At the present time, correct me if I am wrong, I think
it is still rare that Python is one's first programming language. People
who start to use Python may already use some other popular programming
languages. Probably if we do another survey now, the result may be
different. I don't think survey is a bad thing. Richard Stallman
sometimes asked opinions on the emacs newsgroup before he decided whether
to go one way or the other.
:> My suggestion is to make it *optional*, like the semicolon at
:> the end of statements.
: Understood. Won't happen, though: Python has been around for a decade. Do
: you imagine that Guido hasn't heard this suggestion before? In fact there
: are very few "new syntax" ideas that weren't debated and rejected before
: 1991 ended. And, yes, this is one of them (ditto the whole "while 1" thread
: that's been going on virtually non-stop for a decade).
Probably it was true a long time ago, a decade perhaps. Nowadays, there
are more programming languages around. In particular, I like the idea of
the basic syntax of Tcl. Yes, it is very simple, and too simple in a lot
of cases (thank goodness that Python syntax is not as simple as Tcl), but
it makes it just requires the bare minimum for syntax. It seems to me
that the colon is redundant, because the next-level indentation is
required afterwards. Isn't it the basic premise of Python to take the
best features of other programming languages? Probably a decade ago ABC
was around, but now I think many more people have encountered Tcl rather
than ABC.
:> Yes, for people who cares about making it easier to read for newbies,
:> they can always put colons. Yes, for people who use emacs to
:> automatically indent the next line, they can put colons too.
: Guido abhors gratuitous variations in coding sytle; that's largely why
: indentation is used instead of curly braces or begin/end to begin with. A
: choice about whether or not to use a colon is simply not something people
: *need*. The few places Python allows gratuitous choices today are places
: Guido regrets (although not enough to lose sleep over <wink>). For example,
: Guido is unhappy that both "<>" and "!=" are accepted to mean "not equal";
: the older "<>" survives only for compatibility with a very early release of
: the language.
I can see clearly the big difference (as I have experienced) between using
indentation and curly braces; it makes really consistent coding
style. However, I don't see the colons as falling into the same
category. Yes, Guido wants everybody to use colons at the end of the
clauses, but right now what prevents someone to put semicolon at the end
of every statement? Just compare the two or three formats:
xxxx xxxx xxxx:
xxxx xxxx xxxx
xxxx xxxx xxxx
xxxx xxxx xxxx:
xxxx xxxx xxxx;
xxxx xxxx xxxx;
xxxx xxxx xxxx
xxxx xxxx xxxx
xxxx xxxx xxxx
Which one do you think is the most consistent in layout? To me, it is not
the first one.
:> ...
:> I want opinion of you who have programmed for a long time whether
:> there will be some harms if the colons are made optional.
: It's Pythonic to either always require them or never allow them; the former
: won 10 years ago.
But the semicolon at the end of the statement break the Pythonic rule.
:> If not, probably someone can tell me how I can forward this
:> suggestion to the core Python development team?
: You already did <wink> -- Guido's on vacation this week, which makes me as
: close as you'll get until after Christmas. You can submit a formal feature
: request via the SourceForge bug manager at:
: http://sourceforge.net/bugs/?group_id=5470
: but you should expect it to be rejected. Besides that Guido will object on
: principle, the practical support costs of adding such a thing are enormous:
: editing environments from the Emacs Python mode to IDLE would be broken, and
: would be difficult to fix. For a hint as to why it's difficult, study
: tokenize.py in the std library. That trailing colon makes partial parsing a
: whole lot easier, and especially when parsing backwards (as e.g. the Emacs
: python-mode and IDLE and PythonWin need to do routinely).
I am not too familiar with the parsing stuff. However, in my simplistic
opinion, Python is not a free-form language like C or Perl. Therefore,
probably it is reasonable for any parser to breaks a Python code first
into lines, even in backward parsing, instead of parsing it token by
token first. In parsing backwards, can then it just detect first that the
line is at different indentation level rather than try to detect the
colon?
Regards,
Bill
D-Man
<snip>
> Exactly. I just regretted the initial study that used newbies and they
> preferred colons. At the present time, correct me if I am wrong, I think
> it is still rare that Python is one's first programming language.
I think you are right, most people have never heard of Python. It's
really too bad because python is such a nice language and much easier
to learn as a first language than many others.
> I am not too familiar with the parsing stuff. However, in my simplistic
> opinion, Python is not a free-form language like C or Perl. Therefore,
> probably it is reasonable for any parser to breaks a Python code first
> into lines, even in backward parsing, instead of parsing it token by
> token first. In parsing backwards, can then it just detect first that the
> line is at different indentation level rather than try to detect the
> colon?
If the parser (I believe you are referring to someone's emacs mode
thing) used the indentation level to infer the structure, it would
totally defeat the purpose. The purpose of that parser is with the
following input:
if 1 :<enter>print "hello"
To give the following result in the editor:
if 1:
print "hello"
I use vim myself and rather like this feature in C/C++/Java modes. It
also handles the unindent when a } is typed.
I for one rather like having the colon and I have more experience
using C++, C, and Java than Python.
-D
BTW, A python mode for vim would be a very cool thing. I also have a
habit of using a comment to identify the end of blocks (so it is
obvious what the brace is for).
Ex in C I would write :
if ( cond )
{
} /* if */
In C++/Java I use:
if ( cond )
{
} // if
In Python I write:
if ( cond) :
pass
# end if
It would be cool if the editor would recognize the "# end" like it
currently does for "}"
William Djaja Tjokroaminata
: On Fri, Dec 22, 2000 at 06:42:11PM +0000, William Djaja Tjokroaminata wrote:
.......
:> I am not too familiar with the parsing stuff. However, in my simplistic
:> opinion, Python is not a free-form language like C or Perl. Therefore,
:> probably it is reasonable for any parser to breaks a Python code first
:> into lines, even in backward parsing, instead of parsing it token by
:> token first. In parsing backwards, can then it just detect first that the
:> line is at different indentation level rather than try to detect the
:> colon?
: If the parser (I believe you are referring to someone's emacs mode
: thing) used the indentation level to infer the structure, it would
: totally defeat the purpose. The purpose of that parser is with the
: following input:
: if 1 :<enter>print "hello"
: To give the following result in the editor:
: if 1:
: print "hello"
: I use vim myself and rather like this feature in C/C++/Java modes. It
: also handles the unindent when a } is typed.
: I for one rather like having the colon and I have more experience
: using C++, C, and Java than Python.
.......
Well, I think there is not much support in making the colon optional. I
use emacs, but it does not have the python mode (yet). But the beauty of
Python is, in C or C++ I don't think I want to program without a
color-coding editor, but with Python, even in simple text mode, I can
program easily. I guess I just have to install the python mode in emacs,
and based on the automatic indentation caused by the colon, probably the
colon will help me in coding (by automating the indent) rather than keep
giving me syntax errors from time to time.
I will start another thread about another suggestion (regarding the
dictionary), and I guess it indicates how useful Python to me is.
Regards,
Bill
Vadim Zeitlin
>[William Djaja Tjokroaminata]
>> I saw many replies that give the reasons why the colons are
>> *needed*.
>
>Not mine: it told you why the colons are *there*. It's a human-factors
>thing, not a tech thing. Desirable, not necessary.
Isn't it desirable (although not necessary) to attract more people to Python?
IMveryHO any simplification of the syntax without any bad consequences (are
there any in this case?) would be welcome from this point of view.
BTW, what was the real rationale for adding composed assignment operators
(+=) to Python 2.0 (which I'm really extremely glad to have now)? Wasn't it
meant to make Python more attractive to the people coming from C-lie
languages? And, if by chance it was so, why not continue making it even more
simple to use to the very same people?
Regards,
VZ
--
def AreColonsReallyNeeded()
SyntaxError: invalid syntax
Bjorn Pettersen
> BTW, what was the real rationale for adding composed assignment operators
> (+=) to Python 2.0 (which I'm really extremely glad to have now)? Wasn't it
> meant to make Python more attractive to the people coming from C-lie
> languages? And, if by chance it was so, why not continue making it even more
> simple to use to the very same people?
The decision to implement augmented assignment is described in PEP 203
(http://python.sourceforge.net/peps/pep-0203.html). I quote:
There are two main reasons for adding this feature to Python:
simplicity of expression, and support for in-place operations.
If we wanted to make C/C++ programmers attracted to Python we'd have added curly
braces <wink>.
-- bjorn
Tim Peters
> Isn't it desirable (although not necessary) to attract more
> people to Python?
I think so, yes.
> IMveryHO any simplification of the syntax without any bad
> consequences (are there any in this case?) would be welcome from
> this point of view.
Oh, let's get real here: the only syntax change that could possibly attract
a significant number of newcomers would be to add curly braces. That's
because that's the only syntax change left that has a significant
constituency (the "optional trailing colon" thing comes up maybe two times
per year, and Bill is the first person to bother bringing it up twice
<wink>).
> BTW, what was the real rationale for adding composed assignment
> operators (+=) to Python 2.0 (which I'm really extremely glad to
> have now)?
1. According to Guido, it was the single most-requested feature in the
history of the language, and he never disapproved of it. It took several
years for "the right way" to implement it to become apparent, else it would
have gone in much earlier.
2. The NumPy people had a real problem in that
x = x + y
could end up generating multimegabyte temp arrays while
x += y
need not. That is, for them it wasn't "just another way" to write the
former; it offers crucially different semantics.
> Wasn't it meant to make Python more attractive to the people
> coming from C-lie languages?
And here I thought it was to make Python more attractive to Icon programmers
<wink>.
> And, if by chance it was so, why not continue making
> it even more simple to use to the very same people?
curly-braces-ly y'rs - tim
Tim Peters
> Exactly.
Good. Let's stop there <wink>.
> I just regretted the initial study that used newbies and they
> preferred colons. At the present time, correct me if I am wrong, I
> think it is still rare that Python is one's first programming
> language. People who start to use Python may already use some other
> popular programming languages. Probably if we do another survey now,
> the result may be different. I don't think survey is a bad thing.
> Richard Stallman sometimes asked opinions on the emacs newsgroup
> before he decided whether to go one way or the other.
So does Guido, but it's rare, and in this case you're ignoring that he
*already decided*.
A survey is not a usability study, and Guido only asks people when he
doesn't care how it turns out. For example, when complex numbers were
introduced, he asked the numeric people to pick one of "i" or "j" to
indicate the imaginary part. He couldn't care less, and they couldn't stop
arguing about it. They picked "i". People complain about that a *lot* more
than they complain about the trailing colon (although both complaints add up
to "not much"), but they're not getting a choice of "j" at this stage
either.
> ...
> It seems to me that the colon is redundant, because the next-level
> indentation is required afterwards.
Yes; I agreed to that in my first msg. It doesn't matter, though, in the
sense that Python is not about minimizing keystrokes (not even so much as
Perl is, let alone extreme one-liner languages like APL or J). It's much
more about maximizing readability. It may be that you're in a minority who
does not find that the trailing colon increases readability? It increases
readability for me, and that matches the testimony of most people who've
chimed in on this issue over the years.
> Isn't it the basic premise of Python to take the best features of
> other programming languages?
It has never seemed so to me, and I'm not aware of Guido ever having said
so. As a design principle (sometimes honored in the breach), yes, borrowing
from other languages is very apparent in Python, as it is in virtually all
language design efforts. In this particular case, Guido borrowed the rule
from ABC because he *loved* that part of ABC; most of the rest of ABC he
dropped. It's never been a popularity contest, though (if popularity or
"surveys" had any role to play, every language would use curly braces <0.3
wink>).
> Probably a decade ago ABC was around, but now I think many more
> people have encountered Tcl rather than ABC.
ABC was never popular. And I'm not sure what more people being familiar
with Tcl has to do with this. That *may* influence a decision to add
semantic features (like, say, file events) someday, but is unlikely to have
any influence on future syntax -- the languages are worlds apart
syntactically.
> I can see clearly the big difference (as I have experienced) between
> using indentation and curly braces; it makes really consistent coding
> style. However, I don't see the colons as falling into the same
> category.
Guido does. Now what?
> Yes, Guido wants everybody to use colons at the end of the clauses,
> but right now what prevents someone to put semicolon at the end
> of every statement?
Some people do. When they do it public, we ridicule them. Then they
usually stop <wink>.
> Just compare the two or three formats:
>
> xxxx xxxx xxxx:
> xxxx xxxx xxxx
> xxxx xxxx xxxx
>
> xxxx xxxx xxxx:
> xxxx xxxx xxxx;
> xxxx xxxx xxxx;
>
> xxxx xxxx xxxx
> xxxx xxxx xxxx
> xxxx xxxx xxxx
>
> Which one do you think is the most consistent in layout? To me, it
> is not the first one.
The most consistent would be this:
xxxx xxxx xxxx
xxxx xxxx xxxx
xxxx xxxx xxxx
That is, consistency is a red herring.
> ...
> But the semicolon at the end of the statement break the Pythonic
> rule.
If you put them there, yes. Happily, nobody does; for example, you won't
find a semicolon at the end of any code stmt in any .py file in the standard
distribution. When conformity is voluntarily and universally achieved,
there's no need to legislate it.
> ...
> I am not too familiar with the parsing stuff. However, in my
> simplistic opinion, Python is not a free-form language like C
> or Perl. Therefore, probably it is reasonable for any parser
> to breaks a Python code first into lines, even in backward
> parsing, instead of parsing it token by token first. In parsing
> backwards, can then it just detect first that the line is at
> different indentation level rather than try to detect the colon?
When you're writing code and hit the ENTER key, good editing environments
try to *suggest* sensible indentation for the new line. In part, that
requires guessing whether the statement just ended opens a block (in which
case the new line should be indented more) or not (in *most* of which cases
the indentation should be duplicated from the statement that just ended).
Regular expressions don't suffice for this determination, so it's a lot of
painful character-at-a-time parsing. The trailing colon is a great hint:
if the stmt that just ended doesn't end with a colon, there's no need to
endure the expense of further analysis (the line that just ended can't
possibly open a new block without that colon). Speed is important here,
because the user expects the response to the ENTER key to appear
instantaneous, and the parsing code is usually written in an interpreted
language. The Emacs Python mode is greatly helped by some parsing
primitives supplied by elisp and coded in C. IDLE (and by inheritance, also
PythonWin, which shares IDLE's auto-indent code) has a much rougher time of
it, being coded in pure Python, and having the added speed burden of needing
to talk to a Tk text widget thru the Tkinter interface layer to find out
anything about what's in the buffer (even worse, that's indirected in Python
code too, so that PythonWin can talk to the Scintilla text widget instead).
Every quirk of the syntax is exploited mercilessly to reduce processing
time, and that's a hard job (I wrote both of those parsers, so I'm not just
guessing about that); the use of colons to open blocks is one of the quirks
that can be exploited a lot. The IDLE code would need to be redone from
scratch without it (IDLE doesn't preserve any of the alphanumeric characters
now: it squashes all runs of alphanumerics into a single "x" character,
because it can do that quickly, and then chew over far fewer total
characters at Python speed).
At this point, if you want to keep pushing this the way to do it is to open
a PEP:
http://python.sourceforge.net/peps/
While a PEP needs an implementation before it can become final, the PEP
author need not write the implementation, and the PEP can be accepted before
an implementation is even started. What you would need to do is make a
compelling (to Guido) case, and identify all the consequences and how
they'll be dealt with. The process is covered in more detail in
http://python.sourceforge.net/peps/pep-0001.html
I expect the PEP will be rejected, but that doesn't mean it will be. Guido
did surprise me once, in about 1995 <wink>.
or-you-could-just-resolve-to-use-python-for-a-year-before-
improving-it-ly y'rs - tim
Tim Peters
> Horrors, I just checked some of my code and find that I use both !=
> and <> in the same module!
Dear Lord, man! We can only pray that your msg expires from Guido's
newsfeed before he returns. If not ... well, in the spirit of the season
you should be sure to tell your family how much you loved them.
> I don't know why.. Python is so easy to write for, I just use whatever
> is easier to type, so if my hands are low on the keyboard, out
> comes <> .. hands higher up then !=
>
> I think I'll stick with <>, but then I'll have to *think* about
> the syntax, rather than the algorithm.. something I normally don't
> have to do in Python..
Best guess is that "<>" will go away in P3K. I jokingly told Guido it was
clearly wrong for an inequality operator to look so symmetric, and he forgot
to laugh <wink>.
> What a lovely language.
matched-only-by-your-lovely-post-ly y'rs - tim
Steven D. Majewski
On Fri, 22 Dec 2000, Tim Peters wrote:
>
> I expect the PEP will be rejected, but that doesn't mean it will be. Guido
> did surprise me once, in about 1995 <wink>.
>
Tim,
Please save me from searching thru a years worth of python-list archives
and tell me what that 1995 surprise was!
--- Steve Majewski <sd...@Virginia.EDU>
Tim Peters
> I expect the PEP will be rejected, but that doesn't mean it
> will be. Guido did surprise me once, in about 1995 <wink>.
[Steven D. Majewski]
> Please save me from searching thru a years worth of python-list
> archives and tell me what that 1995 surprise was!
My mistake: it was 1994. That's when Guido released Amrit Prem's code
adding "lambda" in 1.0.0 without breathing a word of it on the mailing list
first. So I guess he surprised me again in 1995 by leaving it in <wink>.
So what do *you* want for Christmas, Steven? We have to do *something* to
get you back from that XLISP crap. How about optional colons, or mandatory
parentheses around 2-letter variable names?
hoping-you'll-settle-for-a-fruit-cake-ly y'rs - tim
A.M. Kuchling
from a fresh image, I think...
On Fri, 22 Dec 2000 22:57:50 -0500, Tim Peters <tim...@home.com> wrote:
>indicate the imaginary part. He couldn't care less, and they couldn't stop
>arguing about it. They picked "i". People complain about that a *lot* more
They picked "j", not "i".
>If you put them there, yes. Happily, nobody does; for example, you won't
>find a semicolon at the end of any code stmt in any .py file in the standard
>distribution. When conformity is voluntarily and universally achieved,
>there's no need to legislate it.
[amk@mira Lib]$ grep ';' shlex.py
self.pushback = [];
self.pushback = [tok] + self.pushback;
nextchar = self.instream.read(1);
self.token = ''; # past end of file
Been meaning to fix those... Ooh, and there's one in multifile.py and
netrc.py, too.
--amk
David Abrahams
> 2. The NumPy people had a real problem in that
>
> x = x + y
>
> could end up generating multimegabyte temp arrays while
>
> x += y
>
> need not. That is, for them it wasn't "just another way" to write the
> former; it offers crucially different semantics.
Yes! Any chance of getting this capability for extension classes?
-Dave
Aahz Maruch
<blink> Um, how do you think it works in NumPy?
--
--- Aahz (Copyright 2000 by aa...@pobox.com)
Androgynous poly kinky vanilla queer het <*> http://www.rahul.net/aahz/
Hugs and backrubs -- I break Rule 6
'"Crisp" is a good quality for crackers; less so for pot roast.' --pnh
David C. Ullrich
"Tim Peters" <tim...@home.com> wrote:
> [...] (ditto the whole "while 1" thread
> that's been going on virtually non-stop for a decade).
and we'll never be certain whether it was an intentional
joke or not. Keen.
--
Oh, dejanews lets you add a sig - that's useful...
Sent via Deja.com
http://www.deja.com/
Thomas Wouters
> Best guess is that "<>" will go away in P3K. I jokingly told Guido it was
> clearly wrong for an inequality operator to look so symmetric, and he forgot
> to laugh <wink>.
Well, excuse me, but it's clearly wrong for an equality test operator to
look so much like an augmented assignment statement ! I definately prefer
'<>' myself, anyway, I just wish I could use it in C without turning towards
preprocessor macros :)
+=-*=-/=-!=-ly y'rs,
--
Thomas Wouters <tho...@xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Thomas Wouters
> BTW, what was the real rationale for adding composed assignment operators
> (+=) to Python 2.0 (which I'm really extremely glad to have now)? Wasn't
> it meant to make Python more attractive to the people coming from C-lie
> languages?
No, honestly not. If that was the case, '++' and '--' would have been added
too. The funny part is that I never saw a concious decision not to add them
being made, everyone involved (Guido, Michael Hudson, me, the rest of
python-dev) seemed to naturally accept that the auto-inc/dec operators had
no place in Python, and that in itself is plenty of validation, don't you
think ? :-)
Guido-probably-made-all-decisions-about-Python-years-ago--he's-just-waiting-
-for-people-to-_implement_-them-ly y'rs,
Tim Peters
> Best guess is that "<>" will go away in P3K. I jokingly told
> Guido it was clearly wrong for an inequality operator to look
> so symmetric, and he forgot to laugh <wink>.
[Thomas Wouters]
> Well, excuse me, but it's clearly wrong for an equality test
> operator to look so much like an augmented assignment statement !
> I definately prefer '<>' myself, anyway, I just wish I could
> use it in C without turning towards preprocessor macros :)
You're missing the Big Picture, though: Guido's brother Just is a <> fan
too. That means <> is doomed. It's a sibling rivalry thing <wink>.
just-killed-stackless-and-"for-indexing"-too-ly y'rs - tim
Tim Peters
> Two errors in a timbot posting; time to dump him to disk and restart
> from a fresh image, I think...
That's what the end of the year is for -- it's scheduled but delayed due to
license haggles.
>> ... They picked "i". [for imaginary literals]
> They picked "j", not "i".
Actually, about half did pick "i" <wink>. Guess this proves that I couldn't
care less either.
>> [a claim that no code in the std library ends with ";"]
> [amk@mira Lib]$ grep ';' shlex.py
> self.pushback = [];
> self.pushback = [tok] + self.pushback;
> nextchar = self.instream.read(1);
> self.token = ''; # past end of file
>
> Been meaning to fix those... Ooh, and there's one in multifile.py and
> netrc.py, too.
I stand by my original claim -- especially since you already checked in
repairs for all the cases you found <wink>.
making-a-claim-is-a-good-way-to-make-it-happen-ly y'rs - tim
Rainer Deyke
news:mailman.977594956...@python.org...
> On Sat, Dec 23, 2000 at 12:15:25AM -0500, Tim Peters wrote:
>
> > Best guess is that "<>" will go away in P3K. I jokingly told Guido it
was
> > clearly wrong for an inequality operator to look so symmetric, and he
forgot
> > to laugh <wink>.
>
> Well, excuse me, but it's clearly wrong for an equality test operator to
> look so much like an augmented assignment statement ! I definately prefer
> '<>' myself, anyway, I just wish I could use it in C without turning
towards
> preprocessor macros :)
I dislike <> because to me A <> B implies A > B or A < B. This does not
logically apply to some data types where no ordering is defined. Of course
in Python, A <> B (and A != B) does imply A > B or A < B because of the way
comparison is implemented.
--
Rainer Deyke (ro...@rainerdeyke.com)
Shareware computer games - http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor
Thomas Wouters
> In article <CF316.26760$1t.8...@typhoon.ne.mediaone.net>,
> David Abrahams <abra...@mediaone.net> wrote:
> >"Tim Peters" <tim...@home.com> wrote in message
> >news:mailman.977544967...@python.org...
> >>
> >> 2. The NumPy people had a real problem in that
> >> x = x + y
> >> could end up generating multimegabyte temp arrays while
> >> x += y
> >> need not. That is, for them it wasn't "just another way" to write the
> >> former; it offers crucially different semantics.
> >
> >Yes! Any chance of getting this capability for extension classes?
Extention classes have this capability, ever since Python 2.0. If you look
at 'object.h' in your Python source tree, you'll notice that since 1.6 the
PyNumberMethods struct grew 11 more slots:
binaryfunc nb_inplace_add;
binaryfunc nb_inplace_subtract;
binaryfunc nb_inplace_multiply;
binaryfunc nb_inplace_divide;
binaryfunc nb_inplace_remainder;
ternaryfunc nb_inplace_power;
binaryfunc nb_inplace_lshift;
binaryfunc nb_inplace_rshift;
binaryfunc nb_inplace_and;
binaryfunc nb_inplace_xor;
binaryfunc nb_inplace_or;
And PySequenceMethods grew two similar ones:
binaryfunc sq_inplace_concat;
intargfunc sq_inplace_repeat;
The use of these is guarded by the Py_TPFLAGS_HAVE_INPLACEOPS feature-flag,
so it won't break (backwards) binary compatibility unless you did something
stupid with the typeflags word (PyTypeObject.tp_flags). You should always
initialize the 'tp_flags' with Py_TPFLAGS_DEFAULT -- they don't signify that
you implemented support for a feature, but that your struct contains those
members, and thus that they can be tested for contents without causing
SEGVs.
Each of these inplace 'methods' should be functions that act exactly like
the non-inplace versions of the same methods: they should take two
arguments, 'self' and 'other', and it should return a new reference to the
result object. Note that I said 'new reference' -- if you return 'self', you
have to INCREF it before returning.
Thomas Wouters
> In article <mailman.977446446...@python.org>,
> "Tim Peters" <tim...@home.com> wrote:
>
> > [...] (ditto the whole "while 1" thread
> > that's been going on virtually non-stop for a decade).
> and we'll never be certain whether it was an intentional
> joke or not. Keen.
No, I'm certain Tim did not make that horrible, horrible pun by accident. No
way could he inflict such amounts of nausea and pain by accident. Just not
possible :)
Alex Martelli
news:CF316.26760$1t.8...@typhoon.ne.mediaone.net...
[snip]
> > x = x + y
> >
> > could end up generating multimegabyte temp arrays while
> >
> > x += y
> >
> > need not. That is, for them it wasn't "just another way" to write the
> > former; it offers crucially different semantics.
>
> Yes! Any chance of getting this capability for extension classes?
Not sure what you mean by this question. Both Python-written
classes (by implementing __iadd__) and extension types that are
written in C (by appropriate flags in their method tables) can do
in-place additions (&c). What are 'extension classes'...? Anyway,
this stuff is underdocumented, but, study the sources... it works.
Alex
Tim Peters
> [...] (ditto the whole "while 1" thread
> that's been going on virtually non-stop for a decade).
[David C.Ullrich]
> and we'll never be certain whether it was an intentional
> joke or not. Keen.
[Thomas Wouters]
> No, I'm certain Tim did not make that horrible, horrible pun by
> accident. No way could he inflict such amounts of nausea and pain
> by accident. Just not possible :)
Winkery seems to irk some people so much that I have been experimenting with
leaving it out half the time. It's a Bad Idea, I'm afraid. Witness poor
Greg Ewing, who recently got beat up even in the presence of an explicit
";-)" thingie. So I resolve to redouble my explicit winking efforts in
2001, and those who can detect humor without it will just have to live with
the clues <wink>.
"while-1"-is-a-wonderfully-self-referential-thread-though-ly y'rs - tim
Tim Peters
> BTW, what was the real rationale for adding composed assignment
> operators (+=) to Python 2.0 (which I'm really extremely glad to
> have now)? Wasn't it meant to make Python more attractive to the
> people coming from C-lie languages?
[Thomas Wouters]
> No, honestly not. If that was the case, '++' and '--' would have
> been added too. The funny part is that I never saw a concious
> decision not to add them being made, everyone involved (Guido,
> Michael Hudson, me, the rest of python-dev) seemed to naturally
> accept that the auto-inc/dec operators had no place in Python, and
> that in itself is plenty of validation, don't you think ? :-)
++ and -- were explictly suggested and explicitly rejected innumerable times
on c.l.py, and on the Python mailing list before c.l.py came into glorious
being. In fact, when Guido is deciding whether to invite someone into
python-dev, he sends us secret email asking "hey! do you think this guy
would approve of adding ++?" <wink>.
> Guido-probably-made-all-decisions-about-Python-years-ago--he's-just-
> waiting-for-people-to-_implement_-them-ly y'rs,
Indeed, that was very much the case for augmented assignment, listcomps and
Unicode, and is currently the case for rich comparisons and reworking the
coercion model. It will be the case for healing the type/class split.
Python is like the Sistene Chapel that way: Guido already knows how it will
look in the end, it's just taking years of tedious painting to get there
<wink>.
and-nobody-guessed-brushes-would-wear-out-so-fast-ly y'rs - tim
David C. Ullrich
"Rainer Deyke" <ro...@rainerdeyke.com> wrote:
> "Thomas Wouters" <tho...@xs4all.net> wrote in message
> news:mailman.977594956...@python.org...
> > On Sat, Dec 23, 2000 at 12:15:25AM -0500, Tim Peters wrote:
> >
> > > Best guess is that "<>" will go away in P3K. I jokingly told
Guido it
> was
> > > clearly wrong for an inequality operator to look so symmetric, and
he
> forgot
> > > to laugh <wink>.
> >
> > Well, excuse me, but it's clearly wrong for an equality test
operator to
> > look so much like an augmented assignment statement ! I definately
prefer
> > '<>' myself, anyway, I just wish I could use it in C without turning
> towards
> > preprocessor macros :)
>
> I dislike <> because to me A <> B implies A > B or A < B. This does
not
> logically apply to some data types where no ordering is defined.
Well to _me_ A!=B says that A is not only equal to B, A
is _emphatically_ equal to B, no doubt about it.
> Of
course
> in Python, A <> B (and A != B) does imply A > B or A < B because of
the way
> comparison is implemented.
>
> --
> Rainer Deyke (ro...@rainerdeyke.com)
> Shareware computer games - http://rainerdeyke.com
> "In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor
>
>
--
John W. Baxter
That's probably because I used Pascal and Pascal-like languages for a
long time before subjecting myself to C.
I'd prefer still to be using Pascal over C, but the C crowd has captured
the world.
(For that matter, I prefer "not equal" and "is not equal" over != for
not equal.)
Others feel differently about the matter...I won't try to convert you
unless you try to convert me. ;-)
--John (who, sometime late in the 1990s, had to stop saying he had
been around computers more than twice as long as C had been outside AT&T)
--
John W. Baxter Port Ludlow, WA USA jwb...@scandaroon.com
Olli Rajala
<bil...@y.glue.umd.edu> wrote:
>Exactly. I just regretted the initial study that used newbies and they
>preferred colons. At the present time, correct me if I am wrong, I think
>it is still rare that Python is one's first programming language. People
>who start to use Python may already use some other popular programming
>languages.
I've tried many languages before Python: C/C++, Java, Perl, Visual
Basic (Some people says, that it's not programming language, and maybe
they're right. =), Delphi, Pascal and Php. But I didn't learned them
further, because I didn't have time and I didn't feel that they're my
thing. Perl and Php made an exception. I like Perl, and it's so
handy in some tasks, but Perl is Perl. =) Php is very handy when
static webpages are not enough for you.
Then someday I found "How To Become A Hacker FAQ" by Eric S. Raymond
and it says that you should first learn Python. And now I'm stuck
with it. I think that someday when I'll be the real hacker I can say
that Python was the first language that I learned.
I hope you understand what I tried to say, but I can't guarantee it,
because my English isn't very good.
--
Olli Rajala "Quite normal guy"
Bacgkround information about Linux
http://gamma.nic.fi/~h.rajala/linkit/links.php?linux
Steven D. Majewski
> So what do *you* want for Christmas, Steven? We have to do *something* to
> get you back from that XLISP crap. How about optional colons, or mandatory
> parentheses around 2-letter variable names?
>
> hoping-you'll-settle-for-a-fruit-cake-ly y'rs - tim
I'll settle for a couple more pyobjc developers on sourceforge,
although, as I noted in another thread, I wouldn't mind if someone
rewrote the python runtime in objective-c.
---| Steven D. Majewski (804-982-0831) <sd...@Virginia.EDU> |---
---| Department of Molecular Physiology and Biological Physics |---
---| University of Virginia Health Sciences Center |---
---| P.O. Box 10011 Charlottesville, VA 22906-0011 |---
"All operating systems want to be unix,
All programming languages want to be lisp."
David C. Ullrich
"Tim Peters" <tim...@home.com> wrote:
> [Tim]
> > [...] (ditto the whole "while 1" thread
> > that's been going on virtually non-stop for a decade).
>
> [David C.Ullrich]
> > and we'll never be certain whether it was an intentional
> > joke or not. Keen.
>
> [Thomas Wouters]
> > No, I'm certain Tim did not make that horrible, horrible pun by
> > accident. No way could he inflict such amounts of nausea and pain
> > by accident. Just not possible :)
>
> Winkery seems to irk some people so much that I have been
experimenting with
> leaving it out half the time. It's a Bad Idea, I'm afraid. Witness
poor
> Greg Ewing, who recently got beat up even in the presence of an
explicit
> ";-)" thingie. So I resolve to redouble my explicit winking efforts
in
> 2001,
That's too bad. (I mean really: Take for example a little while
ago in another place, when I was a bit exasperated at someone
who seemed to want the group to do _everything_ for him. I
stated that it wasn't possible to write a function in Pascal
that would determine whether a filename matched a filter like
*.this or that?.ext (the point being sort of it _must_ be
impossible, because if it were possible then all he had to do was
do it and his problem was solved.) If I'd included an explicit
wank it woulda spoiled it, imo. Certainly would have spoiled the
fun of reading the replies from people who thought I was serious...)
> and those who can detect humor without it will just have to
live with
> the clues
Wait, was that a joke? I'm not certain.
><wink>.
yeah, I guess it was.
DU
> "while-1"-is-a-wonderfully-self-referential-thread-though-ly y'rs -
tim
>
>
--
William Djaja Tjokroaminata
C/C++ (or Java too? Now I don't remember what is not equal in Java). I
like Python and I use it as much as I can. However, there isn't
a single language which is good for everything. I still use C/C++ a lot
(and also Perl for one-liners and some text processing), and therefore I
have to switch between the languages quite often. Isn't it great if all
the languages agree on what not equal should look like? We will get
syntax error less often and we have to open the reference books less often
too. Well, I still have to find my Java books to see what not equal is in
Java.... (sigh....)
Bill
Bjorn Pettersen
Well, then it is clear, we should never use !=, since if it was meant to mean
not equal it would certainly have been spelt !==. != should of course be
changed to the not assingment operator which would work perfectly in e.g.
loops, where nobody sane would want to have an assignment. <> of course,
should be read as either smaller or greater which everyone intuitively knows
means not equal.
this-is-all-the-timbot's-fault-and-I-should-probably-include-a-<wink>-somewhere'ly
y'rs
-- bjorn
bil...@my-deja.com
> So does Guido, but it's rare, and in this case you're ignoring that he
> *already decided*.
Tim, people opinion can change over time, and hopefully Python does not have
the principle that once a feature is already decided, it can never be
changed. I think to survive, a language has to be flexible to follow
(rapidly) changing technology and therefore modify some of its own
characteristics.
> Yes; I agreed to that in my first msg. It doesn't matter, though, in the
> sense that Python is not about minimizing keystrokes (not even so much as
> Perl is, let alone extreme one-liner languages like APL or J). It's much
> more about maximizing readability. It may be that you're in a minority who
> does not find that the trailing colon increases readability? It increases
> readability for me, and that matches the testimony of most people who've
> chimed in on this issue over the years.
I think there is some inconsitency here. If Python is really not about
minimizing keystrokes but more about maximining readability, then I have
at least one counter-point: Why don't add a pair of parentheses after the
clauses such as:
if (xxxx xxxx xxxx):
xxxx xxxx xxxx
xxxx xxxx xxxx
I think this is even more readable. Also Python is not consistent in
parentheses: No parentheses are required after if, for, etc., but parentheses
are required for function argument in a def statement:
def func (arg1, arg2):
Just like in Tcl, why not make everything consistent? Like
def func arg1 arg2:
xxxx xxxx xxxx
if xxxx xxxx xxxx:
xxxx xxxx xxxx
It will then be easier to memorize the basic syntax of Python. Because every
time I have to switch between C/C++, Perl, etc., I have to look up the
books just for syntax.
> ABC was never popular. And I'm not sure what more people being familiar
> with Tcl has to do with this. That *may* influence a decision to add
> semantic features (like, say, file events) someday, but is unlikely to have
> any influence on future syntax -- the languages are worlds apart
> syntactically.
The relationship between Tcl and Python, to me at least is, after the first
keyword such as if, for, etc., then we just add words after that without
needing any parentheses, etc., except the colon in Python. Yes, in Tcl we
need braces after if, but that is because of basic syntax of Tcl, and not
because it is for "if" or for "for" needs. I myself programmed in Tcl before
I used Python. For a more general example, the book Tkinter assumes that
some people have programmed in Tcl/Tk before they start using Tkinter. I
always see things like "Python for Tcl programmer", and not vice versa.
Therefore, in the world of Tk, I bet there are a lot people migrating from
Tcl to Python and probably almost none from Python to Tcl.
>
> > I can see clearly the big difference (as I have experienced) between
> > using indentation and curly braces; it makes really consistent coding
> > style. However, I don't see the colons as falling into the same
> > category.
>
> Guido does. Now what?
>
Guido does, but shouldn't we take also the opinions of the community? I
don't like to make this analogy, but in the history, there were/are
communities ruled by kings, and there communities ruled by
democracy. Which one works better for the welfare of the community?
> > Yes, Guido wants everybody to use colons at the end of the clauses,
> > but right now what prevents someone to put semicolon at the end
> > of every statement?
>
> Some people do. When they do it public, we ridicule them. Then they
> usually stop <wink>.
Tim, if you don't allow people to, why don't you just make it part of the
language syntax? Then everybody will be happy. People who use semicolon can
be stopped by the interpreter and immediately fix the problem, and you don't
have to "police" the people and you will have more time for other fun things
:).
The problems with C++ is a lot of software construction is based on
conventions, and not part of the language itself. But because it is based on
conventions, people can abuse them.
>
> > Just compare the two or three formats:
> >
> > xxxx xxxx xxxx:
> > xxxx xxxx xxxx
> > xxxx xxxx xxxx
> >
> > xxxx xxxx xxxx:
> > xxxx xxxx xxxx;
> > xxxx xxxx xxxx;
> >
> > xxxx xxxx xxxx
> > xxxx xxxx xxxx
> > xxxx xxxx xxxx
> >
> > Which one do you think is the most consistent in layout? To me, it
> > is not the first one.
>
> The most consistent would be this:
>
> xxxx xxxx xxxx
> xxxx xxxx xxxx
> xxxx xxxx xxxx
>
> That is, consistency is a red herring.
No, because then you lose the indentation which without question has been
advocated since the time of structured programming.
> > ...
> > But the semicolon at the end of the statement break the Pythonic
> > rule.
>
> If you put them there, yes. Happily, nobody does; for example, you won't
> find a semicolon at the end of any code stmt in any .py file in the standard
> distribution. When conformity is voluntarily and universally achieved,
> there's no need to legislate it.
>
Python could also have achieved the indentation through voluntarity, but it
forced it through the syntax. Again, I think it is better if everything is
consistent. If something is to be universal, force it through the syntax.
If syntax allows something to happen, then people, in my opinion, must be
allowed to use it. By having part rule and part voluntarism, it creates
extra work, especially in the voluntarism part. And if it has been
universally accepted, then I guess nobody will complain when you force it
through the syntax, such as from now on no semicolon is allowed at the end of
the line, unless it is followed by another statement on the same line.
I'm sorry, Tim, my background is not too strong in this parsing department.
My question is, can you just detect the first word of the line? I think
there are only a finite number of them, such as class, def, if, for, etc. If
the first word is any of these, then indent the next line, without regard of
the colon. Is detecting any of these words at the beginning of line much
harder (apart from more CPU time) than detecting a colon at the ending of
line? (I don't mean programmatically. Yes, of course there will be more
code to detect the various words than detecting the single colon. But at
least, in principle, the two are equivalent, right?)
>
> At this point, if you want to keep pushing this the way to do it is to open
> a PEP:
>
> http://python.sourceforge.net/peps/
>
> While a PEP needs an implementation before it can become final, the PEP
> author need not write the implementation, and the PEP can be accepted before
> an implementation is even started. What you would need to do is make a
> compelling (to Guido) case, and identify all the consequences and how
> they'll be dealt with. The process is covered in more detail in
>
> http://python.sourceforge.net/peps/pep-0001.html
>
> I expect the PEP will be rejected, but that doesn't mean it will be. Guido
> did surprise me once, in about 1995 <wink>.
OK, I will do it. Thanks. Hopefully Guido will be more open and generous
during the holiday season :) .
Regards,
Bill
Alex Martelli
[snip]
> > So does Guido, but it's rare, and in this case you're ignoring that he
> > *already decided*.
>
> Tim, people opinion can change over time, and hopefully Python does not
have
> the principle that once a feature is already decided, it can never be
> changed. I think to survive, a language has to be flexible to follow
> (rapidly) changing technology and therefore modify some of its own
> characteristics.
Funny enough, Python survived and thrived for 10 years based on a LOT
of respect for the installed code-base -- and therefore UTTER prudence
in "adding features", because you just don't "retract" a feature later
(breaking people's good code).
> I think there is some inconsitency here. If Python is really not about
> minimizing keystrokes but more about maximining readability, then I have
> at least one counter-point: Why don't add a pair of parentheses after the
> clauses such as:
>
> if (xxxx xxxx xxxx):
Yecch. Redundant punctuation -- the WORST kind, too... ubiquitous
parentheses!
> Just like in Tcl, why not make everything consistent? Like
Because "A foolish consistency is the hobgoblin of little minds"
(Ralph Waldo Emerson)?
> It will then be easier to memorize the basic syntax of Python. Because
every
> time I have to switch between C/C++, Perl, etc., I have to look up the
> books just for syntax.
Perl is a special case of going overboard in wild inconsistency.
Python's tasteful use of little touches of it here and there is
just my thing (except only for the horrid 'print >> bah' blotch).
> > Guido does. Now what?
> >
> Guido does, but shouldn't we take also the opinions of the community? I
No! You want a language designed by committee? Take your pick,
there's a wild abundance of THOSE around.
> don't like to make this analogy, but in the history, there were/are
> communities ruled by kings, and there communities ruled by
> democracy. Which one works better for the welfare of the community?
In a hypothetical situation where anybody is totally free to choose
which community to "be born" in, and vote with his or her feet by
moving to another with minimal inconvenience, a maximal variety of
regimes might be optimal -- give everybody more choice.
Would you rather listen to a symphony composed by one great musician,
or to one made up, one note at a time, each the fruit of some democratic
political compromise? The answer is pretty clear to ME -- particularly
since there are so many examples of the latter in the software world.
As long as some designer enjoys AND USES practical veto-right, a
committee can work to enhance a language -- the ANSI/ISO committees
for C did, and Ritchie showed the need for veto rights in his famous
"Noalias must go. This is non-negotiable" communication. The
Python community (or at least its Guido-selected inner core, the
membership of the 'Python-developers mailing list') plays a similar
role -- they take straw polls and everything. But our Benevolent
Dictator For Life (BDFL) is the one who decides in the end -- he
lets *good arguments* sway his decisions, but NOT opinions, even
widespread ones.
> The problems with C++ is a lot of software construction is based on
> conventions, and not part of the language itself. But because it is based
on
> conventions, people can abuse them.
Python is even MORE convention-based than C++ -- for example, if you
design a class with some attribute X that is only meant for subclasses'
use, in Python you just document that *and rely on people's respect for
this design-convention*, while in C++ you can try to enforce it with
the 'protected' keyword (one of the few specific design decisions that
the language designer explains he now thinks were bad mistakes in his
excellent book on "Design and Evolution of C++" -- but, fortunately for
his language's actual use if not for its theoretical elegance, he, too,
respected the installed codebase too much to ever take something away).
If you want a language where everything is strictly enforced, you may
try Eiffel, but I think even that will fail to live up to that ideal.
> I'm sorry, Tim, my background is not too strong in this parsing
department.
> My question is, can you just detect the first word of the line? I think
> there are only a finite number of them, such as class, def, if, for, etc.
If
> the first word is any of these, then indent the next line, without regard
of
That would be bad -- after I type
if chatty: print "OK so far"
I most definitely do NOT want the next line indented (that would be a
Python syntax error unless I undid the indent manually!).
Alex
Tim Peters
> Tim, people opinion can change over time,
You apparently haven't met Guido yet <wink>.
> and hopefully Python does not have the principle that once a
> feature is already decided, it can never be changed. I think
> to survive, a language has to be flexible to follow (rapidly)
> changing technology and therefore modify some of its own
> characteristics.
Bill, I spent too much time arguing about this already. You may not realize
it, but you have too <wink>. You should be able to tell from the
overwhelming lack of other response on the newsgroup that there's no
groundswell of desire (for making trailing colons optional) being suppressed
here! It's not a new suggestion, and it's never been a popular one. If you
want to put it to a vote, ya, it would lose. Write a PEP if you like, but
I'm not putting more time into this unless and until there is a PEP (a prime
purpose of the PEP process is to stop endlessly repetitive newsgroup
debates).
Just one gloss:
> ...
> Guido does, but shouldn't we take also the opinions of the
> community? I don't like to make this analogy, but in the
> history, there were/are communities ruled by kings, and there
> communities ruled by democracy. Which one works better for
> the welfare of the community?
Guido is often called "the BDFL" here. That stands for Benevolent Dictator
For Life. Python design is in fact a dictatorship, and that's widely
perceived as one of Python's greatest strengths: it gives the language an
internal coherence that committee designs rarely achieve (and, sorry, but
you haven't used Python long enough to judge this yet). It also gives us
some of Guido's charming idiosyncrasies, but the trick is to view those *as*
charming <wink>.
Note that Guido isn't telling you where to live or how many children you can
have or what ratio of genders they must be. He's just saying "here's my
language -- feel free to use it!". Most of us are delighted to.
while-the-rest-plot-against-his-life<wink>-ly y'rs - tim
Martin von Loewis
> At the present time, correct me if I am wrong, I think it is still
> rare that Python is one's first programming language. People who
> start to use Python may already use some other popular programming
> languages.
You are probably right, but many of us hope that Python becomes common
as a language to teach to children; much as Logo was at some earlier
time. The CP4E project was working towards that, and I know a few
highschool teachers are interested, as well.
So I would not throw-away to easily advantages of the language when it
comes to newcomers.
Regards,
Martin
Doug Landauer
> other response on the newsgroup that there's no groundswell
> of desire (for making trailing colons optional) being suppressed
> here!
Well, there is the fact that it's currently between Chrismas
and New Year's, and a lot of people aren't "here". But aside from
that, I suspect
- that 90% of the responses that are being suppressed are from
lack of interest and/or a confidence that The Right Thing
(i.e., No change) Will Happen; and
- that most of those responses, were they to be written, would say
something like this: "Why ever would you want to make your
code less consistent and less readable by omitting the colons?"
barely here-ly,
--
Doug Landauer land...@apple.com (work)
land...@scruznet.com (not-work)
Tim Peters
> ...
> Because "A foolish consistency is the hobgoblin of little minds"
> (Ralph Waldo Emerson)?
Nope! Guido van Rossum coined this for the subtitle of
http://www.python.org/doc/essays/styleguide.html
Unfortunately, Guido took a copy of that back with him on one of his
time-machine trips, to New England in order to pave the way for me to move
there 145 years later. He rested his head on it while making repairs
underneath, and left it there by mistake. A young Transcendentalist found
it in the woods near Concord, MA, and his friends grew quite fond of it
despite not understanding much. Thoreau went on to make that principle the
basis of his form of poetry:
# Local Variables:
# py-indent-offset: 8
# End:
# My Captain: Oh, My Captain!
Emerson liked the subtitle so much that he borrowed it for his ironically
named essay "Self-Reliance", but tacked on "adored by little statesmen and
philosophers and divines" to calm his guilty conscience.
The rest-- as they say --is history.
no-coincidence-that-emerson-and-thoreau-eschewed-tab-characters-ly
y'rs - tim
Tim Peters
[Tim]
> So what do *you* want for Christmas, Steven? ...
> ...
> hoping-you'll-settle-for-a-fruit-cake-ly y'rs - tim
[Steven D. Majewski]
> I'll settle for a couple more pyobjc developers on sourceforge,
> although, as I noted in another thread, I wouldn't mind if someone
> rewrote the python runtime in objective-c.
Your wish is my command! The fruit cake is in the mail.
if-you-can't-even-get-a-raving-objective-c-fan-like-barry-
warsaw-to-sign-up-it's-beyond-santa-tim's-powers-ly y'rs - tim
Alex Martelli
[snip]
> despite not understanding much. Thoreau went on to make that principle
the
> basis of his form of poetry:
Isn't Thoreau's poetry a rather minor part of his writings, despite
his beautiful "if men read aright, methinks they would never read
anything but poems" ... "after all, man is the great poet, and not
Homer nor Shakespeare; and our language itself, and the common arts
of life, are his work"? I always think of him mainly as a thinker,
and writer of essays, rather than a poet.
In a way, I think it's thus fortunate that the following snippet:
> # Local Variables:
> # py-indent-offset: 8
> # End:
> # My Captain: Oh, My Captain!
if, as you say, it was Thoreau's, ended up inspiring one Walt
Whitman instead. Lincoln well deserved such a memorial, after
all, and, as a versifier, I think Whitman had it all over
Thoreau (which rather appreciated his poems, isn't it?).
Alex
Grant Edwards
>I saw many replies that give the reasons why the colons are
>*needed*. My suggestion is to make it *optional*, like the
>semicolon at the end of statements.
I hate optional syntax. It just makes code harder to read when
the syntax is variable. I don't have a strong opinion about
whether there should be colons or not, but I definitely think
picking _one_ syntax is the way to go.
--
Grant Edwards grante Yow! I'm definitely not
at in Omaha!
visi.com
A.M. Kuchling
>Guido is often called "the BDFL" here. That stands for Benevolent Dictator
>For Life. Python design is in fact a dictatorship, and that's widely
>perceived as one of Python's greatest strengths: it gives the language an
Also note that there's nothing preventing anyone from forking the
Python source, and this could happen if Guido makes enough bad
decisions. However, so far most of his bad decisions --
* the __ privacy hack
* the "print >>" syntax
* wanting to deprecate the string module
-- have been fairly minor ones that can be ignored, and people don't
remain BDFL of a project for 10 years because they're stupid, so the
community is naturally reluctant to jettison such a person. (The team
of fanatically-devoted and highly-trained assassins helps.)
Introducing case-insensitivity, optional static typing, or some other
large change, may someday be the breaking point causing a fork, or it
might not.
--amk
Grant Edwards
>That's too bad. (I mean really: Take for example a little while
>ago in another place, when I was a bit exasperated at someone
>who seemed to want the group to do _everything_ for him. I
>stated that it wasn't possible to write a function in Pascal
>that would determine whether a filename matched a filter like
>*.this or that?.ext (the point being sort of it _must_ be
>impossible, because if it were possible then all he had to do was
>do it and his problem was solved.) If I'd included an explicit
>wank it woulda spoiled it, imo.
Please, no explicit wanking in the newsgroup...
--
Grant Edwards grante Yow! Now, let's SEND OUT
at for QUICHE!!
visi.com
Steve Holden
> On Fri, Dec 22, 2000 at 11:50:28PM +0000, Vadim Zeitlin wrote:
>
> > BTW, what was the real rationale for adding composed assignment
operators
> > (+=) to Python 2.0 (which I'm really extremely glad to have now)? Wasn't
> > it meant to make Python more attractive to the people coming from C-lie
> > languages?
>
added
> too. The funny part is that I never saw a concious decision not to add
them
> being made, everyone involved (Guido, Michael Hudson, me, the rest of
> python-dev) seemed to naturally accept that the auto-inc/dec operators had
> no place in Python, and that in itself is plenty of validation, don't you
> think ? :-)
>
>
> -for-people-to-_implement_-them-ly y'rs,
No. He _will_ make them years ago, once concensus has appeared in the
present.
> --
> Thomas Wouters <tho...@xs4all.net>
>
> Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
>
paradoxical-ly y'rs - steve