Addition explanation of indentation for the tutorial

[Michael McLay]

Fredrik Lundh writes:
>
> In fact, Python already supports block delimiters:
>
> if foo: #{
> foo1();
> foo2();
> foo3();
> #}
>
> Inspired by Larry Wall, Guido also made sure that the ending delimiter
> could be written in various other ways, such as #end if. Anything to
> empower the newbies, you know. But real Python programmers tend
> to omit both semicolons and curly braces, of course.

This undocumented feature of the language should be explained in the
official distribution of documentation!! How about adding the
following as an Appendix of the Python Tutorial. Also add a footnote
the explanation of indentation at the end of Chapter 3.

Appendix XXX

Python Block Delimited Notation Parsing Explained

Python incorporates a sophisticated parser and advanced notation for
recognizing block delimiters from almost any computer language. The
foreign language notations of C, Ada Pascal, TCL, and Perl will work
in most situations. The Python parser only requires two minor
modifications to the block notation rules of the foreign language's
grammar rules in order to be Python compliant.

The first change is the addition of a rule which states that
indentation of code is not simply a stylistic suggestion like it is in
other languages. It is mandatory in Python. The use of indentation
is considered good coding practice in all these languages and Python
takes this a step further by making it required by the language
grammar. In Python the meaning of a code block which is not properly
indent is not defined. Experienced Python programmers find this rule
to be very helpful in making everyone's code more readable. An added
benefit is that language sensitive editors, such as Xemacs, can assist
in writing code since they are able to automate the indentation of
code blocks.

The second change to to the grammar rules of foreign languages is that
all symbols used to indicate the beginning or end of a block must be
prefixed with the '#' character. If you are a former Pascal or Ada
programmer this will change your usual notation to:

if x: #BEGIN
x = x + 1
#END

If you are more familiar with C and C++ then you will be comfortable
with either:

if x: #{
x = x + 1
#}

or:

if x:
x = x + 1

or even:

if x: x = x + 1

C programmers will be happy to hear that the Python parser will do the
right thing even if curly braces are not included when two trailing
statements are present:

if x:
x = x + 1
y = 3 + x

This last feature will fix a common source of bugs in C, C++, and Java
programs.

Python's parser is also sophisticated enough to recognize mixed
notations, and it will even catch missing beginning or end delimiters
and correct the program for the user. This allows the following to be
recognized as legal Python:

if x: #BEGIN
x = x + 1
#}

or even:

if x: #{
x = x + 1

Now as you can see from this series of examples, Python has advanced
the state of the art of parser technology and code recognition
capabilities well beyond that of the legacy languages. It has done
this in a manner which carefully balances good coding style with the
need for older programmers to feel comfortable with look of the
language syntax.

[Paul Prescod]

I'm not sure if this is tongue in cheek or not. I'll rise to your troll
nevertheless.

Sorry, in my opinion, requiring blocks and indentation to be "in sync"
is the worst of both worlds. You can't ignore your editor's tab/space
rules but you must still waste a line for the braces. I think that
Python should have some form of brace in the language and that brace
should "turn off" the indentation rules in the same way that parentheses
currently do. I understand Pythoneers reasons for preferring the way it
is. I understand other people's reasons for being frightened of it. I
would really like to see Python support both.

Paul Prescod - http://itrc.uwaterloo.ca/~papresco

Can we afford to feed that army,
while so many children are naked and hungry?
Can we afford to remain passive,
while that soldier-army is growing so massive?
- "Gabby" Barbadian Calpysonian in "Boots"

[Fredrik Lundh]

>Sorry, in my opinion, requiring blocks and indentation to be "in sync"
>is the worst of both worlds. You can't ignore your editor's tab/space
>rules but you must still waste a line for the braces.

Well, as Michael pointed out, the last line is 100% optional.

>I think that Python should have some form of brace in the language
>and that brace should "turn off" the indentation rules in the same
>way that parentheses currently do.

As I mentioned before, there is already such a thing (pindent.py). The
only drawback is that if you use that syntax, you need to compile your
code first. But that's nothing new; C, C++, and Java all have braces,
and they all require you to compile your code before you can run it.

There's more than one way to do things in Python, you know...

Cheers /F

PS. no, we're not very serious. it's hard to take this discussion seriously ;-)

[Paul Prescod]

Fredrik Lundh wrote:
>
> Well, as Michael pointed out, the last line is 100% optional.

And if you leave it out, you're exactly back where you started.

> As I mentioned before, there is already such a thing (pindent.py). The
> only drawback is that if you use that syntax, you need to compile your
> code first.

That isn't the only drawback. Other drawbacks include:
* it isn't documented
* you can't use it in the REPL (which is where I, personally have the
most problems with indentation bugs)
* it dribbles garbage files into your directories
* it can't be used in a pipe
* it turns an interpreted language into a batch compiled one

> But that's nothing new; C, C++, and Java all have braces,
> and they all require you to compile your code before you can run it.

Perl, JavaScript, PNuts and a hundred Lisp variants do not.

> PS. no, we're not very serious. it's hard to take this discussion seriously ;-)

I do take it seriously because I think that whitespace is a major
limiter of Python's acceptance. I know that when I try to "sell" Python
I often get back the response: "Isn't that the language that uses
whitespace for indentation! Yuck." Valuing an aestethic principle over
actual popularity strikes me as the sort of thing that made Lisp so
(un)popular.

Admittedly the Python situation is not as serious of that of Lisp, but
it is an impediment nevertheless, and the solution seems to be to be
much simpler than many of the more complex things we discuss in this
newsgroup. Just overload the curly braces as we have the parenthesis and
let people code in the style they are accustomed to!

[Richard Wolff]

If one is going to argue for a DEDENT/block marker in Python, then I think
it ought to be as unintrusive as possible. How about using the colon as
the end of block marker? In particular,
A line consisting of initial whitespace followed by a colon
would be parsed as DEDENT.

It's minimalist marking, it introduces no new symbols into the language,
it's visually of minimal impact (aside from the almost blank line) so those
of use who don't want to see it won't and those who do will, and it seems
as though it ought to be a minimal change in the parser.

One might also allow multiple adjacent colons to collapse into one, allowing
for more emphatic block marking. Over time, one would hope the one true
(and current) block marking style would prevail as the user tires of typing
what (s)he knows to be extraneous characters.
--
Richard Wolff, National Optical Astronomy Observatories, Tucson, AZ
Internet: rwo...@xyzzy.noao.edu Phonenet: +1 520 318 8392
(Remove the adventure password from the internet address to email me)

[D. Michael McFarland]

Paul Prescod <papr...@technologist.com> writes:

> I do take it seriously because I think that whitespace is a major
> limiter of Python's acceptance. I know that when I try to "sell" Python
> I often get back the response: "Isn't that the language that uses
> whitespace for indentation! Yuck." Valuing an aestethic principle over
> actual popularity strikes me as the sort of thing that made Lisp so
> (un)popular.

I'd like to whole-heartedly second this. (I'm a bit surprised to see
it being discussed--I'd thought this was a religious issue. Maybe
I'll be flamed at the stake for heresy.) I've recently begun to use
Python for some projects, after running out of patience with Perl's
syntax, and I've been very pleased. But I ignored Python *for years*
mostly because of this issue of significant whitespace.

As a concrete example, when I began playing with Python I wanted to
cut and paste code snippets from web pages into an editor, but found
this was unreliable because of how leading white space was treated by
different apps. This shouldn't ever be an issue.

I'd be much more comfortable with (optional) block delimiters, and for
historical reasons I favor curly braces for this. (And no, pyindent,
as I understand it, doesn't fill the bill.)

Thanks for letting me sound off.

Michael

--
D. Michael McFarland <mcfa...@creativedestruction.com>
Vice President, Strategic Technologies Incorporated
http://www.creativedestruction.com/

[garry hodgson]

D. Michael McFarland wrote:
>
> Paul Prescod <papr...@technologist.com> writes:
>
> > I do take it seriously because I think that whitespace is a major
> > limiter of Python's acceptance. I know that when I try to "sell" Python
> > I often get back the response: "Isn't that the language that uses
> > whitespace for indentation! Yuck." Valuing an aestethic principle over
> > actual popularity strikes me as the sort of thing that made Lisp so
> > (un)popular.
>
> I'd like to whole-heartedly second this. (I'm a bit surprised to see
> it being discussed--I'd thought this was a religious issue. Maybe
> I'll be flamed at the stake for heresy.) I've recently begun to use
> Python for some projects, after running out of patience with Perl's
> syntax, and I've been very pleased. But I ignored Python *for years*
> mostly because of this issue of significant whitespace.

i'd like to whole-heartedly disagree. there are more than enough
languages
full of this sort of cruft. uglifying the one that got it right is the
wrong approach. if this is so offensive to others that they won't use
the language, too bad. but don't mess it up for the rest of us.

this kind of notion seems to come up repeatedly in this group. "if only
python looked more like perl, or c++, or java, or cobol, more people
would
use it". if people want to use these other languages, let 'em. indeed,
i use several of 'em myself (guess which one of those i don't?) when
appropriate.
but i use python wherever i can, because i like what it offers. not the
least
of which is the relative absence of visual noise.

> But I ignored Python *for years*
> mostly because of this issue of significant whitespace.

so did i. my mistake, my loss. i'm glad guido didn't change it to get
me on board.

---

Garry Hodgson Sometimes we ride on your horses
ga...@sage.att.com Sometimes we walk alone
Software Innovation Services Sometimes the songs that we hear
AT&T Labs Are just songs of our own

[Fredrik Lundh]

>> PS. no, we're not very serious. it's hard to take this discussion seriously ;-)
>

>I do take it seriously because I think that whitespace is a major
>limiter of Python's acceptance.

Well, people have always put forward lots of reasons why Python
cannot be used, mostly with the same argument: "if we don't add
that, Python will be dead within a year". Here's a short list:

- no real garbage collection
- the scoping rules are too limiting
- too slow for any serious task
- the object model isn't strong enough
- too strong typing
- no explicit block delimiters
- not enough commercial support
- no static typing
- the module system gets in your way if you only write small scripts
- not enough books
- regular expressions are not powerful enough (or too slow)

etc. etc. Check the archives for in-depth discussions of all of these
topics, and much more.

>Just overload the curly braces as we have the parenthesis and
>let people code in the style they are accustomed to!

The point is that they cannot do that in Python anyway. They still
have to learn about scoping rules, that everything's a reference, when
reference counting works and when it doesn't, the class/type model,
the module system, how to efficiently debug dynamically typed code,
etc, etc.

It's pretty interesting that Python has hardly changed at all since it
made its first public appearance, and is still growing like crazy. For
example, the first reference to "optional alternate block structuring
syntax" I've seen is from December 1991 (where Guido responds that
he'd heard the same arguments before). Nothing's happened since
then...

There are lots of things to do to make Python more useful, but
I don't think changing the language is very high on that list. And
of the possible changes, introducing alternate syntaxes doesn't feel
like a good solution.

Cheers /F

[Thomas hamelryck]

Paul Prescod (papr...@technologist.com) wrote:

[knip]

: I do take it seriously because I think that whitespace is a major
: limiter of Python's acceptance. I know that when I try to "sell" Python

: I often get back the response: "Isn't that the language that uses
: whitespace for indentation! Yuck." Valuing an aestethic principle over
: actual popularity strikes me as the sort of thing that made Lisp so
: (un)popular.

[knip]

This sounds very familiar to me. I got exectly the same response from
my colleagues. The use of indentation in Python is one of the few features
I really hate. I've never had any trouble using braces in C++ or C, but I'm
constantly generating errors in my code with these $@! whitespaces! I would
also like to see {} available in Python.

Cheers,

--
------------------------------------------
Thomas Hamelryck, tham...@vub.ac.be
Laboratorium voor Ultrastructuur, VIB-VUB
Paardenstraat 65, B-1640 St-Genesius-Rode
"Sunday morning I'm waking up
Can't even focus on a coffee cup
Don't even know whose bed I'm in
Where do I start, where do I begin?"

[Jan Decaluwe]

Thomas hamelryck wrote:
>
> This sounds very familiar to me. I got exectly the same response from
> my colleagues. The use of indentation in Python is one of the few features
> I really hate. I've never had any trouble using braces in C++ or C, but I'm
> constantly generating errors in my code with these $@! whitespaces! I would
> also like to see {} available in Python.
>
> Cheers,
>
> --
> ------------------------------------------
> Thomas Hamelryck, tham...@vub.ac.be
> Laboratorium voor Ultrastructuur, VIB-VUB
> Paardenstraat 65, B-1640 St-Genesius-Rode
> "Sunday morning I'm waking up
> Can't even focus on a coffee cup
> Don't even know whose bed I'm in
> Where do I start, where do I begin?"

With using a good editor perhaps?

--
===================================================================
Jan Decaluwe === Easics ===
Design Manager === VHDL-based ASIC design services ===
Tel: +32-16-395 600 ===================================
Fax: +32-16-395 619 Interleuvenlaan 86, B-3001 Leuven, BELGIUM
mailto:ja...@easics.be http://www.easics.com

[Thomas hamelryck]

Jan Decaluwe (ja...@easics.be) wrote:

: With using a good editor perhaps?

I use an obscure editor with limited capabilities.
It's called "vi".

[Georg Mischler]

Thomas hamelryck wrote:

> Jan Decaluwe wrote:
>
>: With using a good editor perhaps?
>
> I use an obscure editor with limited capabilities.
> It's called "vi".

So do I, and I have no troubles at all with indenting.
I can indent and dedent any block of code with three
key strokes, and that's all I need for that part.

Hmmmm, if just someone could tell me the right "paragraphs"
settings so I can jump to the beginning of the next and
previous method with "[[" or "]]"...

-Georg

[Thomas hamelryck]

Georg Mischler (g...@hl-technik.de) wrote:

: Thomas hamelryck wrote:
: > Jan Decaluwe wrote:
: >
: >: With using a good editor perhaps?
: >
: > I use an obscure editor with limited capabilities.
: > It's called "vi".
:
: So do I, and I have no troubles at all with indenting.
: I can indent and dedent any block of code with three
: key strokes, and that's all I need for that part.

It's got nothing to do with the editor. I always do a lot of
cutting and pasting when I code, and it's really annoying to adjust the
indentation all the time.

[knip]

[D'Arcy J.M. Cain]

Thomas hamelryck wrote:
> It's got nothing to do with the editor. I always do a lot of
> cutting and pasting when I code, and it's really annoying to adjust

Umm, if a significant amount of your coding is cutting and pasting
then perhaps that's your problem. If there is something that you
find yourself cutting out of other programs then look at putting it
into a module. That's the whole point of OO programming.

--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.

[Andrew Kuchling]

Fredrik Lundh writes:
>It's pretty interesting that Python has hardly changed at all since it
>made its first public appearance, and is still growing like crazy.

^^^^^^^^^^^^^^^^^^^^^^^^^^^
I wonder about that; comp.lang.python was created by 241 YES votes and
27 NO votes. comp.lang.python.announce was created by 227 YES and 15
NO. Now, that certainly doesn't mean the Python community shrank
between those two votes; that would be insane. But I did expect the
vote count to be significantly higher.

On the other hand, Usenet votes don't seem to be very
indicative of the size of communities. The comp.os.linux
reorganization got only 1,824 votes back in 1993, and the community
was larger than that even back then.

>There are lots of things to do to make Python more useful, but
>I don't think changing the language is very high on that list. And

Strong agreement here. People decide to use languages for
many reasons; quality of implementation, available documentation and
ease of learning, the user community, mindshare, and interfaces to
existing software are all important factors, along with the actual
features of the language. IMHO Python ranks quite highly in all of
these criteria except mindshare, and that's changing, too.

A.M. Kuchling http://starship.skyport.net/crew/amk/
"Emberella," thought Magrat. "I'm fairy godmothering a girl who sounds like
something you put up in the rain."
-- Terry Pratchett, _Witches Abroad_

[Paul Prescod]

I'm not predicting the downfall of Python. Python has many things to
recommend it. But of course we can influence its rate of adoption. I
guess we just value aestethic purity and popularity differently. That
also goes for the guy who said that he personally avoided Python because
of it but is *still* glad that it didn't change. That strikes me as the
point of view of a real purist. That's not an insult...I respect
purists.

Note that most of the complaints you mention are actually being
addressed:

- not enough commercial support

- not enough books
- regular expressions are not powerful enough (or too slow)

- too slow for any serious task

Most of these are complaints against the whole *genre* of scripting
language:

- the object model isn't strong enough

- no static typing

Some others will only be discovered after some serious investigation (at
which point you are probably already in love):

- no real garbage collection
- the scoping rules are too limiting

- too strong typing

- the module system gets in your way if you only write small scripts

Which leaves

- no explicit block delimiters

as the only thing that most other scripting languages have that Python
does not and is blatantly obvious to the casual observer.

But anyhow, I'm willing to agree to disagree. In other purity/popularity
debates I come out on the side of purity. It's unlikely Guido is going
to reverse his decision now.

[Guido van Rossum]

If you are *really* serious about changing Python's syntax, there's an
example. A french research group has developed CorbaScript, which is
clearly a Python derivative, but with a more conventional syntax.

Check out their website, http://corbaweb.lifl.fr/.

--Guido van Rossum (home page: http://www.python.org/~guido/)

[Kip Lehman]

I'd like to echo many of Garry's comments if only to add another voice for
preserving the status quo with respect to Python's using whitespace to
denote code blocking (since there seems to be some call for changing it).
After years of frustration with languages that detracted from solving business
problems by obscuring intent with obtuse syntax, I *specifically* was drawn
to Python *because* of the whitespace blocking (... along with the simple, clear,
and straightforward object model). My main interest in that regard is to be
able to read my own code weeks after I've moved on to something else, or
more importantly, to be able to read someone else's code without having to
reformat the code according to my own religious bent.

Most of the sentiments for changing the whitespace blocking seem to be of
genre that new users coming to Python say, "Yuck", when presented with a
new way of structuring their code. To that my perspective is, "tough".
Stay with your current language and it's idiosyncracies. Don't demand
that Python conform to your tastes before you've given it a fair shot.
It seems to me that those asking for Python to change have to give
a *compelling* reason for the change and present evidence of benefit.
So far, I haven't seen any compelling argument for Python to change it's
use of whitespace for blocking to accommodate C/C++ and Perl programmers
attempting to assimilate Python, and I don't believe there'll be any.

A colleague once classified developers into syntax processors and spatial
processors. Those who like syntax elements to control structure and intent
seem to be more comfortable with langs like C/C++/Perl with their use of curly
braces that can be placed in a variety of spatial locations as long as they are
in the correct syntactical sequence. As more of a spatially oriented
processor, that drives me crazy. Representing my constituency of one, I'd
like to lobby Guido (and the worldwide network of contributors)
to not abandon the installed base of current users in search of
new converts by toasting a *major* point of appeal.

Garry Hodgson wrote:
> D. Michael McFarland wrote:
> >
> > Paul Prescod <papr...@technologist.com> writes:
> >

> > > I do take it seriously because I think that whitespace is a major
> > > limiter of Python's acceptance. I know that when I try to "sell" Python
> > > I often get back the response: "Isn't that the language that uses
> > > whitespace for indentation! Yuck." Valuing an aestethic principle over
> > > actual popularity strikes me as the sort of thing that made Lisp so
> > > (un)popular.
> >

[Christopher G. Petrilli]

Paul Prescod <papr...@technologist.com> wrote:
> I'm not predicting the downfall of Python. Python has many things to
> recommend it. But of course we can influence its rate of adoption. I
> guess we just value aestethic purity and popularity differently. That
> also goes for the guy who said that he personally avoided Python because
> of it but is *still* glad that it didn't change. That strikes me as the
> point of view of a real purist. That's not an insult...I respect
> purists.

It really isn't an issue of purity necessarily, but I think that anyone who
throws out a language based on one difference, is so small minded as to not
be able to grasp the REST of the differences, which are much more profound.

I personally have used damned near every language known to man (Icon? PROLOG?
PL/1? DCL?) and keep coming back to the fact that programming CORRECTLY in
Python seems to come more naturall than in any other language... one of the
things that I hate intensely about Perl is that it allows you 500 options
on how you implement something, 490 of which are bad, but seem to appeal
to the obfusciator in all of us.

I would rather have 1 option, which is CORRECT, than 500 which are bad. This
is of course each person's perogative, but let's face it, Python is NEVER
going to be 100% of the world, I just know that when I introduce people
to the language, they love it, quite quickly... I've probably converted 40-50
people, some of whom you'll never hear from.

> Note that most of the complaints you mention are actually being
> addressed:

> - not enough commercial support

This is true of many scripting languages, and freeware in general, maybe
we need to try and interest Cygnus or someone in it. On the other hand,
Python tends to be pretty cleanly written and is actually not ugly on
the inside (unlike most code).

> - not enough books

Agreed, and not enough online information (HOWTOs which Andrew and others
are trying to fix).

> - regular expressions are not powerful enough (or too slow)

This is fixed now largely, but it's still not fast enough :-) But then again
nothing ever is. But here's a real world comparison of something I did in
Python and Perl as well (was forced to do a perl verison)...

Python Perl
Coding time 45 minutes 1 hour
Debug time 5 minutes 2 hours
Run time 45 seconds 20 seconds

How many times do you have to run it before it makes up for the extra cost
in coding and debugging? Remember people, it's about the whole lifecycle.

> - too slow for any serious task

See above.

> Some others will only be discovered after some serious investigation (at
> which point you are probably already in love):

> - no real garbage collection

Tis is a ideological complaint... most languages people use don't have ANY
form of GC at all. Witness the proliferation of tools like Purify.

> - the scoping rules are too limiting
> - too strong typing

Too strong? UH ok :-)

I think there are more improtant things to worry about than whether Python
has block delimeters to clutter the code up.

Chris
--
| Christopher Petrilli
| petr...@amber.org

[Greg Stein (Exchange)]

> From: Christopher G. Petrilli [SMTP:petr...@dworkin.amber.org]
> Sent: Wednesday, March 11, 1998 10:50 AM
> To: pytho...@cwi.nl
> Subject: Re: Addition explanation of indentation for the
tutorial
> ...

> > Note that most of the complaints you mention are actually being
> > addressed:
>
> > - not enough commercial support
>
> This is true of many scripting languages, and freeware in general,
maybe
> we need to try and interest Cygnus or someone in it. On the other
hand,
> Python tends to be pretty cleanly written and is actually not ugly
on
> the inside (unlike most code).

At least two companies, Python Professional Services
(http://www.pythonpros.com) and PythonWare (http://www.pythonware.com
<http://www.pythonware.com> ) offer commercial support, today.

> > - not enough books
>
> Agreed, and not enough online information (HOWTOs which Andrew and
others
> are trying to fix).

New books are arriving and more and more information is online. I think
there is a *sufficient* amount of information, however, that somebody cannot
readily make this claim.

-g

[Samuel L. Bayer]

|> Thomas hamelryck wrote:
|> > It's got nothing to do with the editor. I always do a lot of
|> > cutting and pasting when I code, and it's really annoying to adjust

Two things:

(1) If you cut and paste in C, and you're behaving yourself, you have to
redo the indentation anyway. Which is the whole point of using indentation
semantically, I think: any good programmer will use it to indicate block
structure no matter what language they're coding in, so what's the point of the
delimiter symbols?

(2) However, I think there's a good point here, in that I can't figure out how to
make python-mode.el (for example) unindent a region 1 tab stop while preserving
the RELATIVE indentation. Can this be done? That seems to be the basic problem
with cutting and pasting.

Cheers,
Sam Bayer
s...@mitre.org

[jer...@cnri.reston.va.us]

> :

> : So do I, and I have no troubles at all with indenting.

> : I can indent and dedent any block of code with three

> : key strokes, and that's all I need for that part.
>

> It's got nothing to do with the editor. I always do a lot of

> cutting and pasting when I code, and it's really annoying to adjust the
> indentation all the time.

It may have something to do with the editor. I also cut-and-paste fairly
often, often just to re-organize my code. I use Emacs and can change the
indentation of a block of code with a single keystroke. No trouble at all.

Jeremy

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading

[Barry A. Warsaw]

>>>>> "SLB" == Samuel L Bayer <s...@linus.mitre.org> writes:

SLB> (2) However, I think there's a good point here, in that I
SLB> can't figure out how to make python-mode.el (for example)
SLB> unindent a region 1 tab stop while preserving the RELATIVE
SLB> indentation. Can this be done?

But of course!

Try C-c C-l and C-c C-r which also bound to C-c < and C-c > (these
keys run py-shift-region-left and py-shift-region-right respectively
and operate on the current line if there is no active region). I
couldn't Pythontificate without these ;-)

-Barry

[Jan Decaluwe]

Samuel L. Bayer wrote:

> (2) However, I think there's a good point here, in that I can't figure out how to
> make python-mode.el (for example) unindent a region 1 tab stop while preserving
> the RELATIVE indentation. Can this be done? That seems to be the basic problem
> with cutting and pasting.

C-c C-k C-c <

[Barry A. Warsaw]

>>>>> "GM" == Georg Mischler <g...@hl-technik.de> writes:

GM> Hmmmm, if just someone could tell me the right "paragraphs"
GM> settings so I can jump to the beginning of the next and
GM> previous method with "[[" or "]]"...

Emacs also has a definition of paragraphs and pages. I often add ^L's
to my code (both C and Python) to indicate page breaks for Emacs'
forward-page and backward-page commands. I even lobbied Guido a few
years ago to treat embedded ^L's as whitespace (which he thanksfully
did!)

By default, Emacs uses ^L as it's page-delimiter. Lately I've played
with the following definition:

(setq page-delimiter "^\\(\\|\\(class\\|def\\)[^_]\\)")

but I'm not entirely happy with it, at least not enough to make it the
default for python-mode.el.

-Barry

[Greg Ewing]

Christopher G. Petrilli wrote:
>
> > - no real garbage collection
>
> Tis is a ideological complaint... most languages people use don't have ANY
> form of GC at all.

I think it's more than ideology. There is very real hassle
in constantly having to worry about whether you're leaving
loops in your garbage.

Granted, it's a lot better than having to worry about
dangling pointers, but it's so frustrating having to make
do with a half-baked solution to the problem when a
well-understood and proven total solution exists.

I'm still hoping that Guido will decide to use it
some time during my life...

--
Greg Ewing, Computer Science Dept, | The address below is
spam-protected.
University of Canterbury, | To decode it, replace "splodge" with "."
Christchurch, New Zealand | and "curly" with "@".
greg curly cosc splodge canterbury splodge ac splodge nz

[Guido van Rossum]

> I think it's more than ideology. There is very real hassle
> in constantly having to worry about whether you're leaving
> loops in your garbage.
>

Strange, I only start to worry when I see my process growing without
bounds... Which isn't that often...

> dangling pointers, but it's so frustrating having to make
> do with a half-baked solution to the problem when a
> well-understood and proven total solution exists.

Now, now. Some people beg to differ. Experiments with the the
Boehm-Weiser collector have yielded mixed results at best. And if you
want it, I believe there's a port avaiable on Vladimir Ulogov's site.

> I'm still hoping that Guido will decide to use it
> some time during my life...

Sometime during your (and mine) lifetime, JPython will probably
overtake CPython completely. When that happens, I'll consider my job
done and retire. :-)

[Tim Peters]

[guido]

> If you are *really* serious about changing Python's syntax,
> there's an example. A french research group has developed
> CorbaScript, which is clearly a Python derivative, but with
> a more conventional syntax.
>
> Check out their website, http://corbaweb.lifl.fr/.

Ewwww! This is truly a fascinating exercise for fans of language
(de?)evolution. Here's an example from their submission (my mailer will
doubtless break lines in inconvenient places, but thanks to the magic of
curly braces the result will remain easily readable <wink> -- by the
way, best I can make out from the CorbaScript definition, while
indentation isn't significant, newlines *are* -- they don't mention a
way to split a statement across lines, and don't actually say what
terminates a statement although in every example it's clearly a
newline):

proc DisplayGrid (grid) {
dim = grid.dimension
h = dim.y
w = dim.x
print "The dimensions of this grid are ", w, "*", h, "\n\n"
# iterate to get each values of the grid
for i in range (0, h-1) {
for j in range (0, w-1) {
print ’ ’, grid.get([i,j])
}
print ’\n’
}
}
>>> import gridTools
>>> gridTools.DisplayGrid(grid)
The dimensions of this grid are 20*5
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

Of course if they *had* derived this from Python, it would have said
"def" instead of "proc" <cackle>.

More is going on there, though, and I encourage anyone who doesn't
appreciate the irrevocable pronouncements of our Benevolent Dictator to
study their submission. E.g.,

1. Unlike the Python "print", this one does not stick a space between
elements (& I would have defined it that way myself <wink>).
2. CorbaScript distinguishes between strings (in double quotes) and
characters (in single quotes) (*why* is not apparent).
3. They redefined "range" to *include* the endpoint, so all their
examples have to keep subtracting 1 from the second range argument (bad
idea).

If you go into it deeper, it starts to look like a mix of Python and
JavaScript, with a pile of mysterious (because seemingly gratuitous)
semantic changes, along with baffling omissions (e.g., no "break" or
"continue", no matter how spelled), & some good ideas too (you tell me
...).

None of which is to say it's a bad language, just that this is what
happens when you let intelligent grownups play without being crushed by
the Iron Hand of Guido <wink>.

I'll attach their first example of a CorbaScript class definition,
because it actually relates to the indentation issue: when you have a
lot of small methods, a profusion of brackets is plain ugly -- and a
waste of precious screen height.

python-like-pascal-may-be-a-great-improvement-over-
its-successors-ly y'rs - tim

class GRID { # GRID instance initialization
proc __GRID__ (self, dim, init_value)
{ # This GRID instance (self) is a GridService.Grid CORBA object
CSOA.create (self, GridService.Grid)
# set the GRID instance attributes
self.dim = dim
self.values = create_matrix (dim, init_value)
}
# Creation of a matrix
proc create_matrix (l, w, init_value)
{
values = array.create(w)
for i in range(0,w-1) {
tmp = array.create(l)
for j in range(0,l-1) { tmp[j] = init_value }
values[i] = tmp
}
return values
}
# Implementation of the GridService::Grid IDL specification
proc _get_dimension (self) # implements the readonly ‘dimension’
attribute
{
return self.dim
}
proc set (self, pos, val) # implements the ‘set’ operation
{
try {
self.values[pos.y][pos.x] = val
} catch (BadIndex excep) {
throw GridService.InvalidCoord(pos)
}
}
proc get (self, pos) # implements the ‘get’ operation
{
try {
return self.values[pos.y][pos.x]
} catch (BadIndex excep) {
throw GridService.InvalidCoord(pos)
}
}
proc destroy (self) # implements the ‘destroy’ operation
{
CSOA.dispose (self)
}
}
class FACTORY {
proc __FACTORY__ (self)
{
CSOA.create (self, GridService.Factory)
}
proc create_grid (self, dim, init_value) # the ‘create_grid’
operation
{
grid = GRID(dim, init_value)
return grid._this
}
}

[garry hodgson]

Christopher G. Petrilli wrote:
>
> Paul Prescod <papr...@technologist.com> wrote:
> > I'm not predicting the downfall of Python. Python has many things to
> > recommend it. But of course we can influence its rate of adoption. I
> > guess we just value aestethic purity and popularity differently. That
> > also goes for the guy who said that he personally avoided Python because
> > of it but is *still* glad that it didn't change. That strikes me as the
> > point of view of a real purist. That's not an insult...I respect
> > purists.
>
> It really isn't an issue of purity necessarily, but I think that anyone who
> throws out a language based on one difference, is so small minded as to not
> be able to grasp the REST of the differences, which are much more profound.

well, speaking as the "guy", i should point out that i overstated the
case somewhat
in my original post. it wasn't that i "threw out" the language based on
that,
but that i never investigated it based on its description as "that odd
language
that uses indentation for scoping". this was the one characteristic
that stuck
in the mind of the person who described it to me.

of course, i have since seen the light...

> I personally have used damned near every language known to man (Icon? PROLOG?
> PL/1? DCL?)

me too.

> and keep coming back to the fact that programming CORRECTLY in
> Python seems to come more naturall than in any other language...

i agree. it's got the features i want, without any excess uglitude.

--

[Paul Prescod]

Christopher G. Petrilli wrote:
>
> It really isn't an issue of purity necessarily, but I think that anyone who
> throws out a language based on one difference, is so small minded as to not
> be able to grasp the REST of the differences, which are much more profound.

People don't throw out a language based on one little thing, or most of
us who say we were scared of Python would never have started using it.
But there are hundreds of languages out there, many of them are useful
and every programmer must choose which to learn in which order. Little
things can influence that quite a bit.

If Python had a well defined "niche" as Perl or Java does, then small
things would not matter much. But when you promote Python as "like Perl,
only sane" and then the first thing someone sees is something they
consider insane...

> > - no real garbage collection
>
> Tis is a ideological complaint... most languages people use don't have ANY

> form of GC at all. Witness the proliferation of tools like Purify.

"Most languages" or "popular languages"? Most modern languages (designed
in the last 5 years) have either garbage collection or reference
counting. This is ideology -- it's an important technical issue. Python
doesn't implement GC for important technical reasons (primarily
portability) and I respect that.

> > - too strong typing
>
> Too strong? UH ok :-)

Sure. Some languages allow you to do this:

a = 5 + "6"

I won't argue that that is an important feature (or a feature at all),
but some people might.

Paul Prescod - http://itrc.uwaterloo.ca/~papresco

Our lives shall not be sweated from birth until life closes;
Hearts starve as well as bodies; give us bread, but give us roses.
- http://www.columbia.edu/~melissa/petronella/songs/bread-roses.html

[Mike Meyer]

[Author deleted, as a number of people are pushing this one.]

> People don't throw out a language based on one little thing, or most of
> us who say we were scared of Python would never have started using it.
> But there are hundreds of languages out there, many of them are useful
> and every programmer must choose which to learn in which order. Little
> things can influence that quite a bit.

Ok, what's the big deal with popularity? Python is a perfectly viable
(and valuable) tool as is. What's so important about attracting more
users that it's worth making fundamental changes in the language to
do?

Sure, it'd be nice if everyone knew python, and I didn't have to fight
an uphilll battle to use it. But that's going to be true so long as I
keep choosing tools based on utility and not popularity. If I really
hated that battle, I'd be writing VB on Windows and be done with it.

What's the point of pushing Python in that direction - or even slowing
it down by adding features that go in that direction - when the total
gain for all such things will be a marginal addition to a set whose
size is already marginal to being with?

Not that more is bad, mind you - it's definitely better. It's just not
clear that it can ever be enough better to override any technical
concern.

<mike

--
Do NOT reply to the address in the From: header. Reply to mwm instead of
bouncenews at the same machine. Mail to bouncenews will be returned with
instructions on reaching me. Sending unsoliticed email I consider commercial
gives me permission to subscribe you to a mail list of my choice.

[Paul Prescod]

Guido van Rossum wrote:
> Sometime during your (and mine) lifetime, JPython will probably
> overtake CPython completely. When that happens, I'll consider my job
> done and retire. :-)

I look forward to there being one Python with the best features of both,
but I certainly hope you won't go away when that happens!

[Roman Milner]

>>>>> "MM" == Mike Meyer <bounc...@contessa.phone.net> writes:

MM> Ok, what's the big deal with popularity? Python is a perfectly
MM> viable (and valuable) tool as is. What's so important about
MM> attracting more users that it's worth making fundamental
MM> changes in the language to do?

Now, I'm not saying it justifies making fundamental changes to the
language, I'm all for keeping python python, but pretty much I think
anything than can be done for popularity should.
My employer won't let me use python because they are terrified
they won't be able to find anyone to maintain the code I write if I
jump ship, or get hit by a bus - even though I have persistently
explained that any real programmer can read python code with in a few
days and besides, python's a lot easier to maintain than perl and blah
blah blah. So, all day I am forced to programmer in perl and each
keystroke is like finger nails on the chalk board of my brain. I
*know* I could be more productive using python but my hands are tied.
So, if python were more popular, and more people had it on their
resumes then I could use it at work and I would be a lot less likely
to have a postal experience in my future.

^Roman

--
My grandfather invented Cliff's Notes. It all started back in 1912...Well, to
make a long story short...

-- Steven Wright
------------------
Roman Milner ro...@speeder.com

[Jean-Claude Wippler]

Roman Milner wrote:
> [...] I think anything that can be done for popularity should.

> My employer won't let me use python because they are terrified
> they won't be able to find anyone to maintain the code I write if I
> jump ship, or get hit by a bus - even though I have persistently
> explained that any real programmer can read python code with in a few

> days and besides, python's a lot easier to maintain than perl [...]

Why not build a generator from Python to Perl, Java, C++, whatever?
That way, everyone with bosses could convince them that Python can be
used as generator for whatever language *they* think is important.
It would be a "press here when I leave the company" tool... :)

It could also solve the freezing and source-code hiding issues that
often come up in commercial settings. Making Python succeed in these
environments is the way to grow the Python user-base, much more than
adding features to please everyone on this planet, IMNSHO.

-- Jean-Claude Wippler

[Gordon McMillan]

Jean-Claude Wippler wrote:

> Why not build a generator from Python to Perl, Java, C++, whatever?

And what does the generator do when it encounters:

class foo:
def __call__(self, *args, **kwargs)

or a class that emulates a sequence or....

When I do Java or C++, I prototype in Python first. But I am careful
only to use those features of Python that I know have a
straightforward translation to the target language. And even then I
usually end up having to create a hierarchy of base / derived classes
where, in Python, one class will do.

- Gordon

[Kevin Huber]

"Tim" == Tim Peters <tim...@email.msn.com> writes:
Tim> If you go into it deeper, it starts to look like a mix of Python
Tim> and JavaScript, with a pile of mysterious (because seemingly
Tim> gratuitous) semantic changes, along with baffling omissions
Tim> (e.g., no "break" or "continue", no matter how spelled), & some
Tim> good ideas too (you tell me ...).

I noticed one potentially good idea in GOODE (aka CorbaScript) went
awry:

if (args.length == 0) path = ""

So here we have a nice little length instance variable for lists.
Cool and OO, huh? But wait:

anInteger = aStack.length()

Drat. I guess it should have been a function! <g> aStack is an
instance of a user defined class and could have had .length instead of
.length() of course, but it's interesting how subtle design decisions
like that affect a language -- now length must always be an instance
variable instead of a polymorphic function like it really should be.

There are other ideas that are interesting like the print Tim
mentioned. It seems to be a rather shallow, lightweight
reimplementation of Python-like syntax, but not really with Python
capabilities. Slices are notably missing. I liked this comment:

#
# This demo shows how CorbaScript is slow :-)
#

Well, fast execution ain't everything.

-Kevin

[Gary Capell]

Jean-Claude Wippler <j...@meta4.com> writes:

>Why not build a generator from Python to Perl, Java, C++, whatever?

>[...]

>It could also solve the freezing and source-code hiding issues that

You mean convert the source to Perl source and distribute that,
as a simple form of obfuscation? ;-)

I've used a commercial product which was distributed as Perl
source, but with all the identifiers munged to make it harder
to reverse engineer. Seemed like overkill to me ;-)

--
http://www.cs.usyd.edu.au/~gary/
Python: executable pseudo-code; Perl: executable line noise

[garry hodgson]

Roman Milner wrote:

> My employer won't let me use python because they are terrified
> they won't be able to find anyone to maintain the code I write if I
> jump ship, or get hit by a bus -

...

> So, all day I am forced to programmer in perl

this is really funny (if you're not you, anyway). they believe
that it's *easier* for other folks to maintain your (or anyone's)
perl code? you need a better class of employer.

[LD Landis]

Hi,

As we all know, *EVERYONE* in the world speaks United States American
English, as long as you do it slowly and loudly enough!

Let Python be Python. Nicht wahr?

These old-newbie things... Banana poor naadaa! (spelled in US English ;-)
"Git over it". Da!

Fredrik Lundh wrote:
>
> The point is that they cannot do that in Python anyway. They still
> have to learn ___!!!!___

--
Cheers,
--ldl
-----------------------------------------------------------------------------
LD Landis l...@HealthPartners.Com N0YRQ Voice 612/883-5511 Fax 612/883-6363
HealthPartners, 8100 34th Avenue So, PO Box 1309, Minneapolis, MN 55440-1309
Shape your life not from your memories, but from your hopes. (Borrowed)
-----------------------------------------------------------------------------

[John W. M. Stevens]

On Fri, 13 Mar 1998, garry hodgson <garry-...@sage.att.com> wrote:
>Roman Milner wrote:
>
>> My employer won't let me use python because they are terrified
>> they won't be able to find anyone to maintain the code I write if I
>> jump ship, or get hit by a bus -
>...
>> So, all day I am forced to programmer in perl
>
>this is really funny (if you're not you, anyway). they believe
>that it's *easier* for other folks to maintain your (or anyone's)
>perl code? you need a better class of employer.

Sigh. Another "Perl Flaming Thread".

Whether or not Perl is more readable than Python is a subjective issue. . .

But whether or not it is easier to get Perl programmers, is not.

By all objective measurements, it is easier to find a Perl programmer,
than a Python programmer. I've seen a lot more "Learn Perl" seminars,
courses, books, etc. than I have seen "Learn Python" seminars, books,
etc.

See, it's more complicated than "Python is easier to read or maintain
than Perl". It's also about things like: money, staffing, sharing, etc. . .

Personally, I find the two languages about equally readable. . . with the
exception that I still think of Python as an OOPL, and Perl as a Procedural
language (yeah, yeah, Perl 5.xxx can do objects. . . but the syntax is,
well, confusing, to say the least).

What ever.

John s.

[Richard Smol]

In a previous article, ro...@speeder.com (Roman Milner) says:

>blah blah. So, all day I am forced to programmer in perl and each
>keystroke is like finger nails on the chalk board of my brain. I
>*know* I could be more productive using python but my hands are tied.

Yeah, I know what you mean. Perl SUCKS for any REAL programmming task
(like database-apps, real-time systems, prototyping andsoforth). It's
a great tool for lil stuff like putting a file from one format
into another... and I used it for that quite a bit. But I noticed
that for any heavier job, Python is by FAR the better choice...
I am now spending, say, two weeks on a project in Perl from which
I *know* I could have done it in 4-5 days using Python. Pretty
frustrating to say the least.

And for the Intranet here in the company they used Cold Fusion.
I have no idea why THAT became so popular: it's proprietary,
inefficient, hard to maintain and not suited for anything more
than showing nicely formatted database-tables. I have now been
spending 3 months with it and know for sure that Bobo, the
Python object-publisher, would have been a much better choice.
I would have had more accomplished, it would have been more reliable
and easier to maintain and also safety would have been much higher.

So far for my complaining ;) I keep on waving issues of
Dr. Dobb's in the faces of my employers, but they just won't
see the light.

So, Python *has* to become more popular. To start with, there
should be more books available ...

Greetz,

RS