A Bug By Any Other Name ...

[Dennis Lee Bieber]

The way I remember it (last used Fortran in 1970), DO was the looping
construct, not FOR. Naturally it was uppercase, as keypunches of the
time didn't have an easy way to do lowercase. (It was possible, you
just had to use multi-punch, and a good memory for the appropriate
0-12-11 prefixes).

I was a bit lucky... all the compilers I used were case insensitive
-- as is Ada.

Though BASIC did have a FOR...

--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[Dennis Lee Bieber]

Yes, hence my comment above, ".... coming from C (or an even earlier
language) ......".

Ah, but the parenthetical relegates those predecessor languages to
second class status...

Heck, how much of C is directly from BCPL and B?
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[Daniel Fetchinson]

But this academic discussion is honestly a little pointless. The OP

was referring to a expectation, coming from C, that is not fulfilled
in python. What's wrong with mentioning it somewhere for the sake of
helping C programmers?

And where does one stop? After all, my primary work language at the
time I first encountered Python was FORTRAN77; and my home system at the
time was an Amiga with ARexx... (granted, I did have a C compiler on it
-- which I do not have on this WinXP machine)... And programming, even
in C, on the Amiga still inflicted BCPL concepts upon one ("AmigaDOS",
the "user" view, was a port of Tripos user view on top of the Amiga
executive libraries).

Do we mention how Python differs from F77, F90, Ada, Rexx, LISP,
RPG, APL, Pascal, BASIC, and COBOL (I've done all except RPG since
graduating high school).

In my mind... Anyone whose only experience with programming language
concepts is C/C++ deserves the shock of finding that other languages ARE
DIFFERENT! Even if they never use other languages they should at least
have been exposed to language design options and rationales...

Okay, I don't know what current curricula consist of, but in the
late 70s, a CS degree at my college required two sessions of FORTRAN,
two of COBOL, Assembly (numerically, it followed advanced FORTRAN),
database (followed COBOL)... and then diverged into Business Programming
vs Systems Programming (Business required lots of accounting/statistics
courses [stat-II was SPSS], Systems was operating system and language
design). Electives included BASIC, Pascal, APL (The professor for the
data structures course made the mistake of once allowing an assignment
-- hashed head multiple-linked list -- to be done in any language he
could read <G>; I did it in a BASIC that only supported 4 open files at
a time... I think someone did it in SNOBOL)

C wasn't available on the XEROX Sigma-7; I did have a first edition
K&R. By graduation I'd also been exposed to the initial Ada
reference/rational (a working compiler -- Ada/Ed -- didn't come out
until after I'd graduated).

Okay, so where does one stop? I'd say C deserves special treatment as
opposed to all the other languages you mentioned because Guido himself
admits to influences from C (and ABC but I hope you won't assume that
ABC is a widely used language).

Maybe you didn't read these messages from me in this thread:

By the way, assignments in conditionals. Guido explicitly referred to
C when he forbade assignment in conditionals, citing common
typos/errors in C code such as if( x = 5 ){ .... } instead of if( x ==
5 ){ ..... }. So even he realized that warning people about different
usage in python and C is a good thing. Expectations from C work
sometimes, and sometimes they don't. In latter case a little warning
is useful.

And also,

Seriously, ask Guido about the influence of C vs. fortran (or cobol,
ada, pascal, etc). Somewhere you can find him quoted as saying that
python was originally intended to "bridge the gap between the shell
and C". I've never heard him talk about fortran (or cobol, ada,
pascal, etc).

So don't get me wrong, I'm sufficiently impressed by your knowledge of
various computer languages, I admit to only knowing C and basic and
some fortran (and of course python ), but if Guido himself thinks
the influence of C on python is more important than the others, then
let's not doubt him.

And yes, I shamelessly admit to arguing based on a higher authority
and not based on merit, but in this case it's appropriate, I think

Cheers,
Daniel

 

[Lawrence D'Oliveiro]

I doubt that there are many. Plus, you misspelled them from the more
obvious

n++

and

n--

which *do* fail with a SyntaxError.

Funny, you accuse me of "misspelling", when it's _your_ version that fails
with errors!

 

[Lawrence D'Oliveiro]

I wonder whether the problem with assignment in conditionals in C is due
to the assignment operator being "=". If it was ":=", would the error
still occur?

One of the original C designers, Kernighan or Ritchie, admitted that he made
the assignment operator "=" instead of ":=" just to save typing one
character, because he thought assignments were more common than tests for
equality.

 

[rwwh]

Not so rare. Decimal uses unary plus. Don't assume +x is a no-op.

[...]
Well, yes, but when would you apply it twice in a row?

My point was that unary + isn't a no-op, and therefore neither is ++. For
Decimal, I can't think why you'd want to apply ++x, but for other
objects, who knows?

Here's a toy example:

...     def __pos__(self):
...         return self.__class__("spam " + self)
...>>> s = Spam("")
'spam spam spam spam '

Here's another toy example:

class Toy(int):
def __init__(self, value):
self._incrd = False
int.__init__(self, value)

def incrHalf(self):
self._incrd = True

def __pos__(self):
if self._incrd:
return self.__class__(self+1)
else:
p = self.__class__(self)
p.incrHalf()
return p

def __add__(self, other):
return self.__class__(int(self)+other)

nows122[126]~% python -i toy.py11

 

[J. Cliff Dyer]

Because unlike in algol 68 in python whitespace is relevant,
we could get by with requiring whitespace:
x= -q # okay
a<b and -a<c and -b < -d # okay
8 ** -2 # okay

This is actually quite thoroughly untrue. In python, *indentation* is
significant. Whitespace (internal to a line) is not. You can even call
methods like this if you want:
ABC

Obviously, that's A Bad Idea(tm), but python's parser won't stop you.
The ++ operator gotcha is so minor that I can't remember anyone actually
asking about it on the list (who was actually facing it as a
problem--this thread was started by idle speculation). Can we not
change the language syntax to address non-issues?

Practicality beats purity, a.k.a. don't you have something better to do?


Cheers,
Cliff

 

[Albert van der Horst]

En Mon, 06 Jul 2009 00:28:43 -0300, Steven D'Aprano


Well, those expectations are taken seriously when new features are
introduced into the language - and sometimes the feature is dismissed just
because it would be confusing for some.
If a += 1 works, expecting ++a to have the same meaning is very reasonable
(for those coming from languages with a ++ operator, like C or Java) -
more when ++a is a perfectly valid expression.
If this issue isn't listed under the various "Python gotchas" articles, it
should...

In algol 68 there was one thing strictly forbidden: putting two
operators behind each other:
x := y** -b .comment must be x := y**(-b) .comment

This is quite a sensible rule, especially when, like in Python,
two special characters can be run together to denote a different
operator.
Examples abound : +:= **
A consequence is that 'a*-b'
would be illegal. It would become 'a*(-b)'
Worse is that x=-q would be illegal.

Because unlike in algol 68 in python whitespace is relevant,
we could get by with requiring whitespace:
x= -q # okay
a<b and -a<c and -b < -d # okay
8 ** -2 # okay

Once a c-addict is forced to write
+ +a
she will realize that probably the operator is + is applied to
+a, and that a ++ has no meaning.

Groetjes Albert

 

[MRAB]

This is actually quite thoroughly untrue. In python, *indentation* is
significant. Whitespace (internal to a line) is not.

[snip]
Whitespace (internal to a line) _mostly_ is not. It's not allowed within
names, and it is needed in the second example above, before the 'and's.

 

[Tom Kermode]

Maybe the IDE is the best place to warn you of something like that.

You could have an IDE where you specify which language you're more
familiar with and then have it display warnings likely to be relevant
to you. People could collaborate to add support for gradually more
niche languages.

Python could continue to work the way it was designed to and people
documenting python wouldn't have to worry about this kind of issue.

 

[Albert van der Horst]

This is actually quite thoroughly untrue. In python, *indentation* is
significant. Whitespace (internal to a line) is not. You can even call
methods like this if you want:

You totally don't get it. You describe how python is now.
I propose a change to be made to python. Small wonder that that is
different from what it is now.

ABC

You prove nothing by giving examples.
You can disprove by giving one counter example,
here it goes.

Whitespace (internal to a line) is significant.
In Python you cannot change
xleftgoing = 123000000
to
x left going = 123 000 000

(You can in Algol68)

Obviously, that's A Bad Idea(tm), but python's parser won't stop you.

What is a bad idea?
Apparently you are not talking about my idea of changing the parser.
("Pythons parser won't stop you from changing the parser" doesn't
make sense.)

The ++ operator gotcha is so minor that I can't remember anyone actually
asking about it on the list (who was actually facing it as a
problem--this thread was started by idle speculation). Can we not
change the language syntax to address non-issues?

As other languages have an Eleventh Commandment against concatenating
operators, the larger issue is hardly futile.

Practicality beats purity, a.k.a. don't you have something better to do?

I'm having a great time, thank you!

Cheers,
Cliff

Groetjes Albert

 

[J. Cliff Dyer]

You totally don't get it. You describe how python is now.
I propose a change to be made to python. Small wonder that that is
different from what it is now.


You prove nothing by giving examples.
You can disprove by giving one counter example,
here it goes.

Whitespace (internal to a line) is significant.
In Python you cannot change
xleftgoing = 123000000
to
x left going = 123 000 000

(You can in Algol68)

I had a feeling that counterexample would be coming sooner or later.
However, it doesn't really address the change you're looking for.
Internal whitespace *is* irrelevant, except insofar as it can be used to
delimit different tokens in parsing. If tokens are separate, they are
separate, and no more or less whitespace is going to make any
difference.

Again, I'm describing how python is now. Which is not to say it
couldn't be changed, I just want to make sure you understand how deep
into the heart of python you are trying to cut. You make it sound like
a small change, but it is not. You are proposing changing the parsing
rules, which completely changes the scope of what is possible and what
isn't with python syntax. All to solve a problem that, so far, hasn't
been proven to exist in anything other than a speculative way.

You're trying to turn an ocean liner around because you left your
sunscreen on the dock.

Cheers,
Cliff