Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #110513 > unrolled thread

Assignment Versus Equality

Back to article view | Back to comp.lang.python

Contents

  Assignment Versus Equality Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-26 00:36 -0700
    Re: Assignment Versus Equality BartC <bc@freeuk.com> - 2016-06-26 11:48 +0100
      Re: Assignment Versus Equality Steven D'Aprano <steve@pearwood.info> - 2016-06-26 23:21 +1000
        Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-26 07:26 -0700
          Re: Assignment Versus Equality Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-06-26 11:31 -0400
        Re: Assignment Versus Equality Christopher Reimer <christopher_reimer@icloud.com> - 2016-06-26 11:47 -0700
        Re: Assignment Versus Equality Michael Torrie <torriem@gmail.com> - 2016-06-26 15:28 -0600
        Re: Assignment Versus Equality Bob Gailer <bgailer@gmail.com> - 2016-06-27 08:22 -0400
          Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-27 05:48 -0700
            Re: Assignment Versus Equality Steven D'Aprano <steve@pearwood.info> - 2016-06-27 23:28 +1000
              Re: Assignment Versus Equality Marko Rauhamaa <marko@pacujo.net> - 2016-06-27 16:58 +0300
              Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-27 07:23 -0700
                Re: Assignment Versus Equality Steven D'Aprano <steve@pearwood.info> - 2016-06-28 11:05 +1000
                  Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-27 21:31 -0700
                    Re: Assignment Versus Equality Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-06-28 15:42 +1000
                      Re: Assignment Versus Equality Chris Angelico <rosuav@gmail.com> - 2016-06-28 16:04 +1000
                        Re: Assignment Versus Equality Marko Rauhamaa <marko@pacujo.net> - 2016-06-28 09:12 +0300
                          Re: Assignment Versus Equality Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-06-28 11:04 +0300
                      Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-27 23:09 -0700
                        Re: Assignment Versus Equality Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-28 00:12 -0700
                          Re: Assignment Versus Equality Chris Angelico <rosuav@gmail.com> - 2016-06-28 17:26 +1000
                            Re: Assignment Versus Equality Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-28 01:49 -0700
                              Re: Assignment Versus Equality Chris Angelico <rosuav@gmail.com> - 2016-06-28 20:34 +1000
                                Re: Assignment Versus Equality Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-28 17:42 -0700
                    Re: Assignment Versus Equality Random832 <random832@fastmail.com> - 2016-06-28 10:13 -0400
                      Re: Assignment Versus Equality Marko Rauhamaa <marko@pacujo.net> - 2016-06-28 19:39 +0300
                        Re: Assignment Versus Equality Marko Rauhamaa <marko@pacujo.net> - 2016-06-28 19:41 +0300
                        Re: Assignment Versus Equality Random832 <random832@fastmail.com> - 2016-06-28 13:19 -0400
                        Re: Assignment Versus Equality Ian Kelly <ian.g.kelly@gmail.com> - 2016-06-28 12:27 -0600
                          Re: Assignment Versus Equality Marko Rauhamaa <marko@pacujo.net> - 2016-06-28 22:40 +0300
                            Re: Assignment Versus Equality Gene Heskett <gheskett@shentel.net> - 2016-06-28 16:59 -0400
                        Re: Assignment Versus Equality Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-30 12:29 +1200
                          Re: Assignment Versus Equality Steven D'Aprano <steve@pearwood.info> - 2016-06-30 12:50 +1000
                          Re: Assignment Versus Equality Marko Rauhamaa <marko@pacujo.net> - 2016-06-30 09:22 +0300
                      Re: Assignment Versus Equality Steven D'Aprano <steve@pearwood.info> - 2016-06-29 12:27 +1000
                        Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-28 20:52 -0700
                          Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-28 21:03 -0700
                        Re: Assignment Versus Equality Random832 <random832@fastmail.com> - 2016-06-29 00:52 -0400
                Re: Assignment Versus Equality Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-27 18:14 -0700
              Re: Assignment Versus Equality Gene Heskett <gheskett@shentel.net> - 2016-06-27 11:21 -0400
            Re: Assignment Versus Equality Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-06-27 20:04 -0400
      Re: Assignment Versus Equality Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-06-26 11:21 -0400
        Re: Assignment Versus Equality Cousin Stanley <HooDunnit@didly42KahZidly.net> - 2016-06-26 08:47 -0700
          Re: Assignment Versus Equality BartC <bc@freeuk.com> - 2016-06-26 16:56 +0100
            Re: Assignment Versus Equality Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-27 11:38 +1200
            Re: Assignment Versus Equality Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-06-27 07:30 -0400
              Re: Assignment Versus Equality Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-28 18:17 +1200
            Re: Assignment Versus Equality Grant Edwards <grant.b.edwards@gmail.com> - 2016-06-27 13:59 +0000
              Re: Assignment Versus Equality Marko Rauhamaa <marko@pacujo.net> - 2016-06-27 17:09 +0300
                Re: Assignment Versus Equality sohcahtoa82@gmail.com - 2016-06-27 17:33 -0700
                  Re: Assignment Versus Equality Marko Rauhamaa <marko@pacujo.net> - 2016-06-28 07:25 +0300
                    Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-27 23:54 -0700
              Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-27 07:10 -0700
                Re: Assignment Versus Equality Steven D'Aprano <steve@pearwood.info> - 2016-06-29 12:35 +1000
                  Re: Assignment Versus Equality Chris Angelico <rosuav@gmail.com> - 2016-06-29 14:19 +1000
                    Re: Assignment Versus Equality Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-28 21:51 -0700
                      Re: Assignment Versus Equality Chris Angelico <rosuav@gmail.com> - 2016-06-29 15:07 +1000
                        Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-28 22:55 -0700
                          Re: Assignment Versus Equality Chris Angelico <rosuav@gmail.com> - 2016-06-29 16:26 +1000
                            Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-28 23:33 -0700
                              Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-28 23:37 -0700
                      Re: Assignment Versus Equality Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-06-29 15:26 +1000
                        Re: Assignment Versus Equality Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-28 22:51 -0700
                          Re: Assignment Versus Equality Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-06-29 16:45 +1000
                            Re: Assignment Versus Equality Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-29 01:07 -0700
                            Re: Assignment Versus Equality Chris Angelico <rosuav@gmail.com> - 2016-06-29 18:09 +1000
                              Re: Assignment Versus Equality Steven D'Aprano <steve@pearwood.info> - 2016-06-29 22:36 +1000
                                Re: Assignment Versus Equality BartC <bc@freeuk.com> - 2016-06-29 14:24 +0100
                                  Re: Assignment Versus Equality Chris Angelico <rosuav@gmail.com> - 2016-06-29 23:35 +1000
                                    Re: Assignment Versus Equality BartC <bc@freeuk.com> - 2016-06-29 15:47 +0100
                                Re: Assignment Versus Equality Chris Angelico <rosuav@gmail.com> - 2016-06-29 23:34 +1000
                        Re: Assignment Versus Equality BartC <bc@freeuk.com> - 2016-06-29 10:49 +0100
                          Re: Assignment Versus Equality Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-29 02:56 -0700
                            Re: Assignment Versus Equality BartC <bc@freeuk.com> - 2016-06-29 11:10 +0100
                  Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-29 03:24 -0700
              Re: Assignment Versus Equality Alain Ketterlin <alain@universite-de-strasbourg.fr.invalid> - 2016-06-27 16:48 +0200
                Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-27 22:00 -0700
              Re: Assignment Versus Equality Steven D'Aprano <steve@pearwood.info> - 2016-06-28 11:34 +1000
            Re: Assignment Versus Equality MRAB <python@mrabarnett.plus.com> - 2016-06-27 16:27 +0100
              Re: Assignment Versus Equality Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-27 14:56 -0700
              Re: Assignment Versus Equality Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-27 15:45 -0700
                Re: Assignment Versus Equality BartC <bc@freeuk.com> - 2016-06-28 00:08 +0100
                  Re: Assignment Versus Equality Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-06-27 20:11 -0400
                    Re: Assignment Versus Equality BartC <bc@freeuk.com> - 2016-06-28 11:35 +0100
                  Re: Assignment Versus Equality Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-28 18:59 +1200
              Re: Assignment Versus Equality Steven D'Aprano <steve@pearwood.info> - 2016-06-28 11:28 +1000
            Re: Assignment Versus Equality Grant Edwards <grant.b.edwards@gmail.com> - 2016-06-27 15:42 +0000
        Re: Assignment Versus Equality Marko Rauhamaa <marko@pacujo.net> - 2016-06-26 19:11 +0300
      Re: Assignment Versus Equality MRAB <python@mrabarnett.plus.com> - 2016-06-26 16:41 +0100
        Re: Assignment Versus Equality BartC <bc@freeuk.com> - 2016-06-26 17:08 +0100
      Re: Assignment Versus Equality Christopher Reimer <christopher_reimer@icloud.com> - 2016-06-26 11:53 -0700
        Re: Assignment Versus Equality Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-27 11:41 +1200
      Re: Assignment Versus Equality Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-27 11:22 +1200
        Re: Assignment Versus Equality BartC <bc@freeuk.com> - 2016-06-27 00:39 +0100
          Re: Assignment Versus Equality Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-28 18:15 +1200

Page 5 of 5 — ← Prev page 1 2 3 4 [5]

#110615

On Tuesday, June 28, 2016 at 3:27:40 AM UTC+12, MRAB wrote:
> On 2016-06-27 14:59, Grant Edwards wrote:
>> Why would a language designer think it a good idea?
>>
> It let you have identifiers like "grand total"; there was no need for 
> camel case or underscores to separate the parts of the name.

Another nifty thing (well, I thought so at the time) was that FORTRAN had no reserved words.

Though I wondered, in statements like

    FORMAT(...complex expression with lots of nested parentheses...) = ...

how much work the parser would have to do before deciding that it was an array assignment, not a FORMAT statement?

Then some FORTRAN dialects allowed constant definitions using syntax like

    PARAMETER N = 3

which broke the no-reserved-words convention. Luckily, this was standardized as the much less headache-inducing (for the compiler writer)

    PARAMETER(N = 3)

PL/I (which was almost named “FORTRAN VI” at one stage) added significant whitespace, but managed to keep the no-reserved-words convention--almost. There was just one peculiar set of exceptions...

[toc] | [prev] | [next] | [standalone]

#110618

On 27/06/2016 23:45, Lawrence D’Oliveiro wrote:
> On Tuesday, June 28, 2016 at 3:27:40 AM UTC+12, MRAB wrote:
>> On 2016-06-27 14:59, Grant Edwards wrote:
>>> Why would a language designer think it a good idea?
>>>
>> It let you have identifiers like "grand total"; there was no need for
>> camel case or underscores to separate the parts of the name.
>
> Another nifty thing (well, I thought so at the time) was that FORTRAN had no reserved words.
>
> Though I wondered, in statements like
>
>     FORMAT(...complex expression with lots of nested parentheses...) = ...
>
> how much work the parser would have to do before deciding that it was an array assignment, not a FORMAT statement?

You just design the compiler to do the same processing in each case, ie. 
parse a <name> followed (<expression>), then mark the result AST 
fragment as either an Array term, or Format statement, depending on what 
follows, and whether the name is "format".

I suppose the compiler could decide to backtrack and re-parse based on 
the knowledge that is one or the other, but that's a messy way of doing it.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#110621

On Tue, 28 Jun 2016 00:08:00 +0100, BartC <bc@freeuk.com> declaimed the
following:

>
>You just design the compiler to do the same processing in each case, ie. 
>parse a <name> followed (<expression>), then mark the result AST 
>fragment as either an Array term, or Format statement, depending on what 
>follows, and whether the name is "format".
>
	You're expecting an AST in a compiler from the 50s?

	That might have involved having to punch an output deck of cards for
each compile, only to then feed that deck back into the reader for the next
phase of compilation.


>I suppose the compiler could decide to backtrack and re-parse based on 
>the knowledge that is one or the other, but that's a messy way of doing it.

	But kept things to one statement at a time, with the output being the
machine code for the processor -- possibly being punched to cards so it
could be loaded later.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#110679

On 28/06/2016 01:11, Dennis Lee Bieber wrote:
> On Tue, 28 Jun 2016 00:08:00 +0100, BartC <bc@freeuk.com> declaimed the
> following:
>
>>
>> You just design the compiler to do the same processing in each case, ie.
>> parse a <name> followed (<expression>), then mark the result AST
>> fragment as either an Array term, or Format statement, depending on what
>> follows, and whether the name is "format".
>>
> 	You're expecting an AST in a compiler from the 50s?
>

Well, FORTRAN in the 50s would have been much simpler too. No nested 
subscripts for example. And ASTs are just one of many methods of compiling.

> 	That might have involved having to punch an output deck of cards for
> each compile, only to then feed that deck back into the reader for the next
> phase of compilation.

We have to assume that at least one complete line could be held in 
memory. Then you can reinterpret it as many times as you like. (I don't 
know if 1950s FORTRAN has continuation lines, which makes that a little 
harder.)

However, not allowing FORMAT as a variable name probably /would/ have 
been simpler!

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#110662

BartC wrote:
> On 27/06/2016 23:45, Lawrence D’Oliveiro wrote:
> 
>>     FORMAT(...complex expression with lots of nested parentheses...) = 
> 
> You just design the compiler to do the same processing in each case, ie. 
> parse a <name> followed (<expression>), then mark the result AST 
> fragment as either an Array term, or Format statement, depending on what 
> follows, and whether the name is "format".

Except that the contents of FORMAT statements have their
own unique syntax that's very different from that of
argument lists or array indexes. So processing them
both the same way would introduce its own level of
messiness.

Starting all over again from the beginning of the
statement is probably the least messy way to handle it.

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#110629

On Tue, 28 Jun 2016 01:27 am, MRAB wrote:

> On 2016-06-27 14:59, Grant Edwards wrote:
>> On 2016-06-26, BartC <bc@freeuk.com> wrote:
>>
>>> (Note, for those who don't know (old) Fortran, that spaces and tabs are
>>> not significant. So those dots are needed, otherwise "a eq b" would be
>>> parsed as "aeqb".)
>>
>> I've always been baffled by that.
>>
>> Were there other languages that did something similar?
>>
> Algol 60 and Algog 68.

Are you sure about that? I'd like to see a citation, as everything I've seen
suggests that Algol treats spaces like modern languages.

http://www.masswerk.at/algol60/algol60-syntaxversions.htm

Space is listed as a separator, and *not* in indentifiers.





-- 
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

[toc] | [prev] | [next] | [standalone]

#110597

On 2016-06-27, MRAB <python@mrabarnett.plus.com> wrote:
> On 2016-06-27 14:59, Grant Edwards wrote:
>> On 2016-06-26, BartC <bc@freeuk.com> wrote:
>>
>>> (Note, for those who don't know (old) Fortran, that spaces and tabs are
>>> not significant. So those dots are needed, otherwise "a eq b" would be
>>> parsed as "aeqb".)
>>
>> I've always been baffled by that.
>>
>> Were there other languages that did something similar?
>
> Algol 60 and Algog 68.

Ah, I never knew that Algol ignored spaces also.  I had a vague
recollection that they keyword namespace and variable namespaces were
speparate, which allowed some rather odd looking (by modern standards)
code.

> It let you have identifiers like "grand total"; there was no need for 
> camel case or underscores to separate the parts of the name.

It's interesting how completely that concept has dissappeared from
modern languages.

-- 
Grant Edwards               grant.b.edwards        Yow! Send your questions to
                                  at               ``ASK ZIPPY'', Box 40474,
                              gmail.com            San Francisco, CA 94140,
                                                   USA

[toc] | [prev] | [next] | [standalone]

#110527

Dennis Lee Bieber <wlfraed@ix.netcom.com>:

> 	It did... but I'm sure we'd have a revolt if Python comparison
> operators looked like:
>
> 	a .eq. b
> 	a .ne. b
> 	a .gt. b .or. c .lt. d
> 	a .le. b .and. c .ge. d

Yuck, who'd ever want to look at an eyesore like that. In Python, we
will always stick to the pleasant elegance of

   __eq__
   __ne__
   __gt__
   __ge__
   __lt__
   __le__


Marko

[toc] | [prev] | [next] | [standalone]

#110522

On 2016-06-26 11:48, BartC wrote:
> On 26/06/2016 08:36, Lawrence D’Oliveiro wrote:
>> One of Python’s few mistakes was that it copied the C convention of using “=” for assignment and “==” for equality comparison.
>
> One of C's many mistakes. Unfortunately C has been very influential.
>
> However, why couldn't Python have used "=" both for assignment, and for
> equality? Since I understand assignment ops can't appear in expressions.
>
[snip]

Python supports chained assignments. For example, "a = b = 0" assigns 0 
to both a and b.

I'm not sure how common it is, though. I virtually never use it myself.

[toc] | [prev] | [next] | [standalone]

#110526

On 26/06/2016 16:41, MRAB wrote:
> On 2016-06-26 11:48, BartC wrote:

>> However, why couldn't Python have used "=" both for assignment, and for
>> equality? Since I understand assignment ops can't appear in expressions.
>>
> [snip]
>
> Python supports chained assignments. For example, "a = b = 0" assigns 0
> to both a and b.
>
> I'm not sure how common it is, though. I virtually never use it myself.

Well, if it's allowed, then it doesn't matter how common it is.

So "=" couldn't be used with a different meaning inside expressions as 
it would make this ambiguous.

It also raises the possibility of a bug when someone intends to write 
"a=b==0" but writes "a=b=c" instead.

In that case I would have supported the use of ":=" for assignment.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#110539

On 6/26/2016 8:41 AM, MRAB wrote:

> On 2016-06-26 11:48, BartC wrote:
>> On 26/06/2016 08:36, Lawrence D’Oliveiro wrote:
>>> One of Python’s few mistakes was that it copied the C convention of 
>>> using “=” for assignment and “==” for equality comparison.
>>
>> One of C's many mistakes. Unfortunately C has been very influential.
>>
>> However, why couldn't Python have used "=" both for assignment, and for
>> equality? Since I understand assignment ops can't appear in expressions.
>>
> [snip]
>
> Python supports chained assignments. For example, "a = b = 0" assigns 
> 0 to both a and b.
>
> I'm not sure how common it is, though. I virtually never use it myself.

How can you not use chained assignments? I thought Python was the art of 
the clever one-liners. :)

Chris R.

[toc] | [prev] | [next] | [standalone]

#110546

Christopher Reimer wrote:
> How can you not use chained assignments? I thought Python was the art of 
> the clever one-liners. :)

No, Python is the art of writing clever one-liners
using more than one line.

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#110543

BartC wrote:
> On 26/06/2016 08:36, Lawrence D’Oliveiro wrote:
> 
>> One of Python’s few mistakes was that it copied the C convention of 
>> using “=” for assignment and “==” for equality comparison.
> 
> One of C's many mistakes. Unfortunately C has been very influential.

I'm not sure it's fair to call it a mistake. C was
designed for expert users, and a tradeoff was likely
made based on the observation that assignment is
used much more often than equality testing.

> However, why couldn't Python have used "=" both for assignment, and for 
> equality?

Because an expression on its own is a valid statement,
so

    a = b

would be ambiguous as to whether it meant assigning b
to a or evaluating a == b and discarding the result.

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#110545

On 27/06/2016 00:22, Gregory Ewing wrote:
> BartC wrote:
>> On 26/06/2016 08:36, Lawrence D’Oliveiro wrote:
>>
>>> One of Python’s few mistakes was that it copied the C convention of
>>> using “=” for assignment and “==” for equality comparison.
>>
>> One of C's many mistakes. Unfortunately C has been very influential.
>
> I'm not sure it's fair to call it a mistake. C was
> designed for expert users, and a tradeoff was likely
> made based on the observation that assignment is
> used much more often than equality testing.

You mean the rationale was based on saving keystrokes?

A shame they didn't consider that when requiring parentheses around 
conditionals, semicolons, /*...*/ around comments, %d format codes and 
elaborate for-statements then!

But you might be right in that it was probably based on existing usage 
of Fortran, PL/I and maybe even Basic. (Its predecessor 'B' used "=", 
but B came through BCPL which I believe used ":="; perhaps the mistake 
was in discarding that.)

>> However, why couldn't Python have used "=" both for assignment, and
>> for equality?
>
> Because an expression on its own is a valid statement,
> so
>
>    a = b
>
> would be ambiguous as to whether it meant assigning b
> to a or evaluating a == b and discarding the result.

And that would be another reason why == is needed for equality.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#110655

BartC wrote:
> You mean the rationale was based on saving keystrokes?

Maybe disk space as well -- bytes were expensive
in those days!

-- 
Greg

[toc] | [prev] | [standalone]

Page 5 of 5 — ← Prev page 1 2 3 4 [5]

Back to top | Article view | comp.lang.python

csiph-web