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


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

Assignment Versus Equality

Started byLawrence D’Oliveiro <lawrencedo99@gmail.com>
First post2016-06-26 00:36 -0700
Last post2016-06-28 18:15 +1200
Articles 20 on this page of 95 — 21 participants

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 1 of 5  [1] 2 3 4 5  Next page →


#110513 — Assignment Versus Equality

FromLawrence D’Oliveiro <lawrencedo99@gmail.com>
Date2016-06-26 00:36 -0700
SubjectAssignment Versus Equality
Message-ID<8a53c069-ca13-47bf-a24e-d2393a018b22@googlegroups.com>
One of Python’s few mistakes was that it copied the C convention of using “=” for assignment and “==” for equality comparison.

It should have copied the old convention from Algol-like languages (including Pascal), where “:=” was assignment, so “=” could keep a meaning closer to its mathematical usage.

For consider, the C usage isn’t even consistent. What is the “not equal” operator? Is it the “not” operator concatenated with the “equal” operator? No it’s not! It is “!” followed by “=” (assignment), of all things! This fits in more with the following pattern:

    A += B <=> A = A + B
    A *= B <=> A = A * B

in other words

    A != B

should be equivalent to

    A = A ! B

[toc] | [next] | [standalone]


#110514

FromBartC <bc@freeuk.com>
Date2016-06-26 11:48 +0100
Message-ID<nkobtu$gaq$1@dont-email.me>
In reply to#110513
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.

> It should have copied the old convention from Algol-like languages (including Pascal), where “:=” was assignment, so “=” could keep a meaning closer to its mathematical usage.

(I think Fortran and PL/I also used "=" for assignment. Both were more 
commercially successful than Algol or Pascal.)

> For consider, the C usage isn’t even consistent. What is the “not equal”
 > operator? Is it the “not” operator concatenated with the “equal” 
operator?
 > No it’s not! It is “!” followed by “=” (assignment), of all things!

I thought "!" /was/ the logical not operator (with "~" being bitwise not).

 > This fits in more with the following pattern:
>
>     A += B <=> A = A + B
>     A *= B <=> A = A * B
>
> in other words
>
>     A != B
>
> should be equivalent to
>
>     A = A ! B

Yes, that's an another inconsistency in C. Sometimes "<>" was used for 
"not equals", or "≠" except there was limited keyboard support for that. 
("/=" would have the same problem as "!=")

But again, that doesn't apply in Python as the "!=" in "A != B" can't 
appear in expressions.

-- 
Bartc

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


#110517

FromSteven D'Aprano <steve@pearwood.info>
Date2016-06-26 23:21 +1000
Message-ID<576fd6e0$0$1617$c3e8da3$5496439d@news.astraweb.com>
In reply to#110514
On Sun, 26 Jun 2016 08:48 pm, 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.

Personally, I think that even if there is no *syntactical* ambiguity between
assignment and equality, programming languages should still use different
operators for them. I must admit that my first love is still Pascal's :=
for assignment and = for equality, but C's = for assignment and == for
equality it *almost* as good.

(It loses a mark because absolute beginners confuse the assignment = for the
= in mathematics, which is just different enough to cause confusion.)

But the BASIC style = for both assignment and equality is just begging for
confusion. Even though = is not ambiguous given BASIC's rules, it can still
be ambiguous to beginners who haven't yet digested those rules and made
them second nature.

And even experts don't always work with complete statements. Here is a
snippet of BASIC code:

X = Y

Is it an assignment or an equality comparison? Without seeing the context,
it is impossible to tell:

10 X = Y + 1
20 IF X = Y GOTO 50


Now obviously BASIC was a very popular and successful language, for many
years, despite that flaw. But I wouldn't repeat it in a new language.


>> It should have copied the old convention from Algol-like languages
>> (including Pascal), where “:=” was assignment, so “=” could keep a
>> meaning closer to its mathematical usage.
> 
> (I think Fortran and PL/I also used "=" for assignment. Both were more
> commercially successful than Algol or Pascal.)

Fortran 77 used .EQ. for equality. I'm not sure about PL/I.

I'm also not sure I'd agree about the commercial success. Fortran certainly
has been extremely popular, albeit almost entirely in numerical computing.
But PL/I has virtually disappeared from the face of the earth, while Pascal
still has a small but dedicated community based on FreePascal, GNU Pascal,
and Delphi.

(Of the three, FreePascal and Delphi appear to still be getting regular
releases.)




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

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


#110518

FromRustom Mody <rustompmody@gmail.com>
Date2016-06-26 07:26 -0700
Message-ID<074ec9c0-7f5b-4bfd-a0d4-06d2d8accf18@googlegroups.com>
In reply to#110517
On Sunday, June 26, 2016 at 6:51:58 PM UTC+5:30, Steven D'Aprano wrote:
> On Sun, 26 Jun 2016 08:48 pm, 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.
> 
> Personally, I think that even if there is no *syntactical* ambiguity between
> assignment and equality, programming languages should still use different
> operators for them. I must admit that my first love is still Pascal's :=
> for assignment and = for equality, but C's = for assignment and == for
> equality it *almost* as good.
> 
> (It loses a mark because absolute beginners confuse the assignment = for the
> = in mathematics, which is just different enough to cause confusion.)
> 
> But the BASIC style = for both assignment and equality is just begging for
> confusion. Even though = is not ambiguous given BASIC's rules, it can still
> be ambiguous to beginners who haven't yet digested those rules and made
> them second nature.
> 
> And even experts don't always work with complete statements. Here is a
> snippet of BASIC code:
> 
> X = Y
> 
> Is it an assignment or an equality comparison? Without seeing the context,
> it is impossible to tell:
> 
> 10 X = Y + 1
> 20 IF X = Y GOTO 50
> 
> 
> Now obviously BASIC was a very popular and successful language, for many
> years, despite that flaw. But I wouldn't repeat it in a new language.

This is a tad bit unfair (I think)
Initially Basic (BASIC as things were spelt then) used
LET X = Y
for the assignment

The general success of the succinct and confusing approach starting Fortran and
exploding with C I guess prompted the shortening

[My impression: Dont know the history exactly]

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


#110521

FromDennis Lee Bieber <wlfraed@ix.netcom.com>
Date2016-06-26 11:31 -0400
Message-ID<mailman.5.1466955108.2358.python-list@python.org>
In reply to#110518
On Sun, 26 Jun 2016 07:26:34 -0700 (PDT), Rustom Mody
<rustompmody@gmail.com> declaimed the following:

>This is a tad bit unfair (I think)
>Initially Basic (BASIC as things were spelt then) used
>LET X = Y
>for the assignment
>

	K&K/Dartmouth BASIC used the first token of each statement to define
what type of statement followed... Making parsing a tad easier for the
interpreter... Sort statements by line number, read first token of line,
invoke proper processing for that type of statement.

LET
IF
GOSUB
GOTO
RETURN
READ
PRINT
INPUT
DATA
OPEN
etc.

... Every statement had a unique keyword as the first token.

>The general success of the succinct and confusing approach starting Fortran and

	FORTRAN goes back to the late 50s, K&K BASIC is mid-60s if not later.
Autocode predated FORTRAN and also use = for assignment:
https://en.wikipedia.org/wiki/Autocode#Mark_1_Autocode

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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


#110538

FromChristopher Reimer <christopher_reimer@icloud.com>
Date2016-06-26 11:47 -0700
Message-ID<mailman.12.1466970454.2358.python-list@python.org>
In reply to#110517
On 6/26/2016 6:21 AM, Steven D'Aprano wrote:

> On Sun, 26 Jun 2016 08:48 pm, 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.
> Personally, I think that even if there is no *syntactical* ambiguity between
> assignment and equality, programming languages should still use different
> operators for them. I must admit that my first love is still Pascal's :=
> for assignment and = for equality, but C's = for assignment and == for
> equality it *almost* as good.
>
> (It loses a mark because absolute beginners confuse the assignment = for the
> = in mathematics, which is just different enough to cause confusion.)
>
> But the BASIC style = for both assignment and equality is just begging for
> confusion. Even though = is not ambiguous given BASIC's rules, it can still
> be ambiguous to beginners who haven't yet digested those rules and made
> them second nature.
>
> And even experts don't always work with complete statements. Here is a
> snippet of BASIC code:
>
> X = Y
>
> Is it an assignment or an equality comparison? Without seeing the context,
> it is impossible to tell:
>
> 10 X = Y + 1
> 20 IF X = Y GOTO 50
>
>
> Now obviously BASIC was a very popular and successful language, for many
> years, despite that flaw. But I wouldn't repeat it in a new language.
>
>
>>> It should have copied the old convention from Algol-like languages
>>> (including Pascal), where “:=” was assignment, so “=” could keep a
>>> meaning closer to its mathematical usage.
>> (I think Fortran and PL/I also used "=" for assignment. Both were more
>> commercially successful than Algol or Pascal.)
> Fortran 77 used .EQ. for equality. I'm not sure about PL/I.
>
> I'm also not sure I'd agree about the commercial success. Fortran certainly
> has been extremely popular, albeit almost entirely in numerical computing.
> But PL/I has virtually disappeared from the face of the earth, while Pascal
> still has a small but dedicated community based on FreePascal, GNU Pascal,
> and Delphi.
>
> (Of the three, FreePascal and Delphi appear to still be getting regular
> releases.)

I started writing a BASIC interpreter in Python. The rudimentary version 
for 10 PRINT "HELLO, WORLD!" and 20 GOTO 10 ran well. The next version 
to read each line into a tree structure left me feeling over my head. So 
I got "Writing Compilers & Interpreters: An Applied Approach" by Ronald 
Mak (1991 edition) from Amazon, which uses C for coding and Pascal as 
the target language.  I know a little bit of C and nothing of Pascal. 
Translating an old dialect of C into modern C, learning Pascal and 
figuring out the vagaries of BASIC should make for an interesting 
learning experience.

Chris R.

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


#110540

FromMichael Torrie <torriem@gmail.com>
Date2016-06-26 15:28 -0600
Message-ID<mailman.14.1466976536.2358.python-list@python.org>
In reply to#110517
On 06/26/2016 12:47 PM, Christopher Reimer wrote:
> I started writing a BASIC interpreter in Python. The rudimentary version 
> for 10 PRINT "HELLO, WORLD!" and 20 GOTO 10 ran well. The next version 
> to read each line into a tree structure left me feeling over my head. So 
> I got "Writing Compilers & Interpreters: An Applied Approach" by Ronald 
> Mak (1991 edition) from Amazon, which uses C for coding and Pascal as 
> the target language.  I know a little bit of C and nothing of Pascal. 
> Translating an old dialect of C into modern C, learning Pascal and 
> figuring out the vagaries of BASIC should make for an interesting 
> learning experience.

Sounds like fun.  Every aspiring programmer should write an interpreter
for some language at least once in his life!

I imagine that any modern dialect of BASIC has a very complex grammar.
The syntax is full of ambiguities, of which the "=" operator is the
least of them.  In many dialects there several versions of END to
contend with, for example.  And then there are a lot of legacy
constructs with special syntax such as LINE (0,0)-(100,100),3,BF.

I have a soft spot in my heart for BASIC, since that's what I grew up
on. I still follow FreeBASIC development. It's a very mature language
and compiler now, though it struggles to find a reason to exist I think.
 It can't decide if it's C with a different syntax, or C++ with a
different syntax (object-oriented and everything) or maybe something in
between or completely different.

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


#110573

FromBob Gailer <bgailer@gmail.com>
Date2016-06-27 08:22 -0400
Message-ID<mailman.27.1467030174.2358.python-list@python.org>
In reply to#110517
On Jun 26, 2016 5:29 PM, "Michael Torrie" <torriem@gmail.com> wrote:
>
> On 06/26/2016 12:47 PM, Christopher Reimer wrote:

> Sounds like fun.  Every aspiring programmer should write an interpreter
> for some language at least once in his life!

In the mid 1970' s I helped maintain an installation of IBM' s APL
interpreter at Boeing Computer Services. APL uses its own special character
set, making code unambiguous and terse. It used a left-arrow for
assignment, which was treated as just another operator. I will always miss
"embedded assignment".

A year later I worked on a project that ran on a CDC 6600? where only
FORTRAN was available. The program's job was to apply user's commands to
manage a file system. FORTRAN was not the best language for that task, so I
designed my own language, and wrote an interpreter for it in FORTRAN. In
retrospect a very good decision. That program was in use for 10 years!

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


#110574

FromRustom Mody <rustompmody@gmail.com>
Date2016-06-27 05:48 -0700
Message-ID<02e2d3f4-0198-4cdf-a493-45a248c03aea@googlegroups.com>
In reply to#110573
On Monday, June 27, 2016 at 5:53:07 PM UTC+5:30, Bob Gailer wrote:
> On Jun 26, 2016 5:29 PM, "Michael Torrie"  wrote:
> >
> > On 06/26/2016 12:47 PM, Christopher Reimer wrote:
> 
> > Sounds like fun.  Every aspiring programmer should write an interpreter
> > for some language at least once in his life!
> 
> In the mid 1970' s I helped maintain an installation of IBM' s APL
> interpreter at Boeing Computer Services. APL uses its own special character
> set, making code unambiguous and terse. It used a left-arrow for
> assignment, which was treated as just another operator. I will always miss
> "embedded assignment".


In the past, APL's ← may not have been practicable (ie
- without committing to IBM... which meant
- $$$ 
- Also it was a hardware commitment (trackball?)
- etc

Today that '←' costs asymptotically close to '='
To type :: 3 chars CAPSLOCK '<' '-'
To setup :: [On Ubuntu Unity]
   System-Settings → Keyboard → Shortcuts-Tab → Typing → Make Compose CAPSLOCK
To see :: Its ONE CHAR, just like '=' and ½ of ':='

tl;dr Anyone opposing richer charsets is guaranteedly using arguments from 1970

PS Google Groups is wise enough to jump through hoops trying to encode my message
above as latin-1, then as Windows 1252 and only when that does not work as 
UTF-8
ie it garbles ← into <- etc
So some हिंदी (ie Hindi) to convince GG to behave

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


#110576

FromSteven D'Aprano <steve@pearwood.info>
Date2016-06-27 23:28 +1000
Message-ID<577129e0$0$1596$c3e8da3$5496439d@news.astraweb.com>
In reply to#110574
On Mon, 27 Jun 2016 10:48 pm, Rustom Mody wrote:

> PS Google Groups is wise enough to jump through hoops trying to encode my
> message above as latin-1, then as Windows 1252 and only when that does not
> work as UTF-8


There is nothing admirable about GG (or any other newsreader or email
client) defaulting to legacy encodings like Latin-1 and especially not
Windows 1252.

Certainly the user should be permitted to explicitly set the encoding, but
otherwise the program should default to UTF-8.



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

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


#110582

FromMarko Rauhamaa <marko@pacujo.net>
Date2016-06-27 16:58 +0300
Message-ID<877fdawx6n.fsf@elektro.pacujo.net>
In reply to#110576
Steven D'Aprano <steve@pearwood.info>:

> On Mon, 27 Jun 2016 10:48 pm, Rustom Mody wrote:
>
>> PS Google Groups is wise enough to jump through hoops trying to
>> encode my message above as latin-1, then as Windows 1252 and only
>> when that does not work as UTF-8
>
> There is nothing admirable about GG (or any other newsreader or email
> client) defaulting to legacy encodings like Latin-1 and especially not
> Windows 1252.
>
> Certainly the user should be permitted to explicitly set the encoding,
> but otherwise the program should default to UTF-8.

The users should be completely oblivious to such technicalities as
character encodings.

As for those technicalities, a MIME-compliant client is free to use any
well-defined, widely-used character encoding as long as it is properly
declared.


Marko

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


#110590

FromRustom Mody <rustompmody@gmail.com>
Date2016-06-27 07:23 -0700
Message-ID<c032167b-baeb-4b9b-8f90-39019cbb4030@googlegroups.com>
In reply to#110576
On Monday, June 27, 2016 at 6:58:26 PM UTC+5:30, Steven D'Aprano wrote:
> On Mon, 27 Jun 2016 10:48 pm, Rustom Mody wrote:
> 
> > PS Google Groups is wise enough to jump through hoops trying to encode my
> > message above as latin-1, then as Windows 1252 and only when that does not
> > work as UTF-8
> 
> 
> There is nothing admirable about GG (or any other newsreader or email
> client) defaulting to legacy encodings like Latin-1 and especially not
> Windows 1252.
> 
> Certainly the user should be permitted to explicitly set the encoding, but
> otherwise the program should default to UTF-8.

Its called sarcasm...

Also how is GG deliberately downgrading clear unicode content to be kind to 
obsolete clients at recipient end different from python 2 → 3 making breaking 
changes but not going beyond ASCII lexemes?

Just think: Some poor mono-lingual ASCII-user may suffer an aneurism...
Completely atrocious!

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


#110626

FromSteven D'Aprano <steve@pearwood.info>
Date2016-06-28 11:05 +1000
Message-ID<5771cd54$0$1589$c3e8da3$5496439d@news.astraweb.com>
In reply to#110590
On Tue, 28 Jun 2016 12:23 am, Rustom Mody wrote:

> On Monday, June 27, 2016 at 6:58:26 PM UTC+5:30, Steven D'Aprano wrote:
>> On Mon, 27 Jun 2016 10:48 pm, Rustom Mody wrote:
>> 
>> > PS Google Groups is wise enough to jump through hoops trying to encode
>> > my message above as latin-1, then as Windows 1252 and only when that
>> > does not work as UTF-8
>> 
>> 
>> There is nothing admirable about GG (or any other newsreader or email
>> client) defaulting to legacy encodings like Latin-1 and especially not
>> Windows 1252.
>> 
>> Certainly the user should be permitted to explicitly set the encoding,
>> but otherwise the program should default to UTF-8.
> 
> Its called sarcasm...


Ah, sorry about that, I didn't realise.

Some human languages have native support for flagging sarcasm, e.g. there's
a sarcasm marker called temherte slaqî used by some Ethiopic languages to
indicate sarcasm and other unreal statements. It apparently looks somewhat
like an upside down exclamation mark (¡).

Another common solution is to use "scare quotes" around the sarcastic key
words. Or you could tag the sentence with <sarcasm> </sarcasm> tags. Most
people I see using this last one just show the close tag, often
abbreviating it to just /s on its own.


> Also how is GG deliberately downgrading clear unicode content to be kind
> to obsolete clients at recipient end different from python 2 → 3 making
> breaking changes but not going beyond ASCII lexemes?

Oh yes, I completely agree, obviously GvR is literally worse than Hitler
because he hasn't added a bunch of Unicode characters with poor support for
input and worse support for output as essential syntactic elements to
Python.

/s




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

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


#110642

FromRustom Mody <rustompmody@gmail.com>
Date2016-06-27 21:31 -0700
Message-ID<4805e31e-040d-4caf-a79e-af56f93f6daf@googlegroups.com>
In reply to#110626
On Tuesday, June 28, 2016 at 6:36:06 AM UTC+5:30, Steven D'Aprano wrote:
> On Tue, 28 Jun 2016 12:23 am, Rustom Mody wrote:
> > Also how is GG deliberately downgrading clear unicode content to be kind
> > to obsolete clients at recipient end different from python 2 → 3 making
> > breaking changes but not going beyond ASCII lexemes?
> 
> Oh yes, I completely agree, obviously GvR is literally worse than Hitler
> because he hasn't added a bunch of Unicode characters with poor support for
> input and worse support for output as essential syntactic elements to
> Python.
> 
> /s

Gratuitous Godwin acceleration produceth poor sarcasm -- try again
And while you are at it try and answer the parallel:
Unicode has a major pro and con
Pro: Its a superset and enormously richer than ASCII
Con: It is costly and implementations are spotty

GG downgrades posts containing unicode if it can, thereby increasing reach to
recipients with unicode-broken clients

Likewise this:

> a bunch of Unicode characters with poor support for
> input and worse support for output as essential syntactic elements to
> Python.

sounds like the same logic applied to python

JFTR I am not quarrelling with Guido's choices; just pointing out your 
inconsistencies

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


#110648

FromSteven D'Aprano <steve+comp.lang.python@pearwood.info>
Date2016-06-28 15:42 +1000
Message-ID<57720e58$0$1530$c3e8da3$5496439d@news.astraweb.com>
In reply to#110642
On Tuesday 28 June 2016 14:31, Rustom Mody wrote:

> On Tuesday, June 28, 2016 at 6:36:06 AM UTC+5:30, Steven D'Aprano wrote:
>> On Tue, 28 Jun 2016 12:23 am, Rustom Mody wrote:
>> > Also how is GG deliberately downgrading clear unicode content to be kind
>> > to obsolete clients at recipient end different from python 2 → 3 making
>> > breaking changes but not going beyond ASCII lexemes?
>> 
>> Oh yes, I completely agree, obviously GvR is literally worse than Hitler
>> because he hasn't added a bunch of Unicode characters with poor support for
>> input and worse support for output as essential syntactic elements to
>> Python.
>> 
>> /s
> 
> Gratuitous Godwin acceleration produceth poor sarcasm -- try again
> And while you are at it try and answer the parallel:
> Unicode has a major pro and con
> Pro: Its a superset and enormously richer than ASCII

Correct.

> Con: It is costly and implementations are spotty

That's a matter of opinion. What do you mean by "spotty"?

It seems to me that implementations are mostly pretty good, at least as good as 
Python 2 narrow builds. Support for astral characters is not as good, but 
(apart from some Han users, and a few specialist niches) not as import either.

The big problem is poor tooling: fonts still have many missing characters, and 
editors don't make it easy to enter anything not visible on the keyboard.


> GG downgrades posts containing unicode if it can, thereby increasing reach to
> recipients with unicode-broken clients

And how does that encourage clients to support Unicode? It just enables 
developers to tell themselves "It's just a few weirdos and foreigners who use 
Unicode, ASCII [by which they mean Latin 1] is good enough for everyone."

Its 2016, and it is *way* past time that application developers stop pandering 
to legacy encodings by making them the default. If developers saw that 99% of 
emails were UTF-8, they would be less likely to think they could avoid learning 
about Unicode.

 
> Likewise this:
> 
>> a bunch of Unicode characters with poor support for
>> input and worse support for output as essential syntactic elements to
>> Python.
> 
> sounds like the same logic applied to python
> 
> JFTR I am not quarrelling with Guido's choices; just pointing out your
> inconsistencies

Oh, it's inconsistencies plural is it? So I have more than one? :-)

In Python 3, source files are treated as UTF-8 by default. That means, if you 
want to use Unicode characters in your source code (for variable names, 
comments, or in strings) you can, and you don't have to declare a special 
encoding. Just save the file in an editor that defaults to UTF-8, and Python is 
satisfied. If, for some reason, you need some legacy encoding, you can still 
explicitly set it with a coding cookie at the top of the file.

That behaviour is exactly analogous to my position that mail and news clients 
should default to UTF-8. But in neither case would people be *required* to 
include Unicode characters in their text.


-- 
Steve

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


#110649

FromChris Angelico <rosuav@gmail.com>
Date2016-06-28 16:04 +1000
Message-ID<mailman.63.1467093900.2358.python-list@python.org>
In reply to#110648
On Tue, Jun 28, 2016 at 3:42 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> And how does that encourage clients to support Unicode? It just enables
> developers to tell themselves "It's just a few weirdos and foreigners who use
> Unicode, ASCII [by which they mean Latin 1] is good enough for everyone."
>

Or Windows-1252, but declared as Latin-1. (Bane of my life.)

ChrisA

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


#110652

FromMarko Rauhamaa <marko@pacujo.net>
Date2016-06-28 09:12 +0300
Message-ID<87por1on9a.fsf@elektro.pacujo.net>
In reply to#110649
Chris Angelico <rosuav@gmail.com>:

> Or Windows-1252, but declared as Latin-1. (Bane of my life.)

J


Marko

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


#110668

FromJussi Piitulainen <jussi.piitulainen@helsinki.fi>
Date2016-06-28 11:04 +0300
Message-ID<lf537nxloxf.fsf@ling.helsinki.fi>
In reply to#110652
Marko Rauhamaa writes:

> Chris Angelico wrote:
>
>> Or Windows-1252, but declared as Latin-1. (Bane of my life.)
>
> J

J [1] uses ASCII.

References:

[1] https://en.wikipedia.org/wiki/J_(programming_language)

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


#110654

FromRustom Mody <rustompmody@gmail.com>
Date2016-06-27 23:09 -0700
Message-ID<fbe3fd6b-ddba-4185-a081-e2a0fcdd0ffc@googlegroups.com>
In reply to#110648
On Tuesday, June 28, 2016 at 11:12:59 AM UTC+5:30, Steven D'Aprano wrote:
> On Tuesday 28 June 2016 14:31, Rustom Mody wrote:
> 
> > On Tuesday, June 28, 2016 at 6:36:06 AM UTC+5:30, Steven D'Aprano wrote:
> >> On Tue, 28 Jun 2016 12:23 am, Rustom Mody wrote:
> >> > Also how is GG deliberately downgrading clear unicode content to be kind
> >> > to obsolete clients at recipient end different from python 2 → 3 making
> >> > breaking changes but not going beyond ASCII lexemes?
> >> 
> >> Oh yes, I completely agree, obviously GvR is literally worse than Hitler
> >> because he hasn't added a bunch of Unicode characters with poor support for
> >> input and worse support for output as essential syntactic elements to
> >> Python.
> >> 
> >> /s
> > 
> > Gratuitous Godwin acceleration produceth poor sarcasm -- try again
> > And while you are at it try and answer the parallel:
> > Unicode has a major pro and con
> > Pro: Its a superset and enormously richer than ASCII
> 
> Correct.
> 
> > Con: It is costly and implementations are spotty
> 
> That's a matter of opinion. What do you mean by "spotty"?

We've had this conversation before.
Ive listed these spottinesses
See http://blog.languager.org/2015/03/whimsical-unicode.html
Specifically the section on ½-assed unicode support

> 
> It seems to me that implementations are mostly pretty good, at least as good as 
> Python 2 narrow builds. Support for astral characters is not as good, but 
> (apart from some Han users, and a few specialist niches) not as import either.
> 
> The big problem is poor tooling: fonts still have many missing characters, and 
> editors don't make it easy to enter anything not visible on the keyboard.
> 
> 
> > GG downgrades posts containing unicode if it can, thereby increasing reach to
> > recipients with unicode-broken clients
> 
> And how does that encourage clients to support Unicode? It just enables 
> developers to tell themselves "It's just a few weirdos and foreigners who use 
> Unicode, ASCII [by which they mean Latin 1] is good enough for everyone."
> 
> Its 2016, and it is *way* past time that application developers stop pandering 
> to legacy encodings by making them the default. If developers saw that 99% of 
> emails were UTF-8, they would be less likely to think they could avoid learning 
> about Unicode.
> 
>  
> > Likewise this:
> > 
> >> a bunch of Unicode characters with poor support for
> >> input and worse support for output as essential syntactic elements to
> >> Python.
> > 
> > sounds like the same logic applied to python
> > 
> > JFTR I am not quarrelling with Guido's choices; just pointing out your
> > inconsistencies
> 
> Oh, it's inconsistencies plural is it? So I have more than one? :-)

Here's one (below)
> 
> In Python 3, source files are treated as UTF-8 by default. That means, if you 
> want to use Unicode characters in your source code (for variable names, 
> comments, or in strings) you can, and you don't have to declare a special 
> encoding. Just save the file in an editor that defaults to UTF-8, and Python is 
> satisfied. If, for some reason, you need some legacy encoding, you can still 
> explicitly set it with a coding cookie at the top of the file.
> 
> That behaviour is exactly analogous to my position that mail and news clients 
> should default to UTF-8. But in neither case would people be *required* to 
> include Unicode characters in their text.

Python2 had strings and unicode strings u"..."
Python3 has char-strings and byte-strings b"..." with the char-strings 
uniformly spanning all of unicode.

Not just a significant change in implementation but in mindset

Yet the way you use Unicode in the sentence above implies that while you
*say* 'Unicode' you mean the set Unicode - ASCII which is exactly
Python2 mindset.

So which mindset do you subscribe to?

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


#110663

FromLawrence D’Oliveiro <lawrencedo99@gmail.com>
Date2016-06-28 00:12 -0700
Message-ID<3bd25897-8ecb-4a27-ab22-220677551f41@googlegroups.com>
In reply to#110654
On Tuesday, June 28, 2016 at 6:14:28 PM UTC+12, Rustom Mody wrote:
> Ive listed these spottinesses
> See http://blog.languager.org/2015/03/whimsical-unicode.html
> Specifically the section on ½-assed unicode support

Remember how those UTF-16-using pieces of software got sucked into it. They were assured it was UCS-2.

As for remembering to correctly free() after malloc(), it’s not that hard to do <https://github.com/ldo/dvd_menu_animator/blob/master/spuhelper.c>.

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


Page 1 of 5  [1] 2 3 4 5  Next page →

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


csiph-web