A Bug By Any Other Name ...

[Daniel Fetchinson]

I wonder how many people have been tripped up by the fact that

The fact that it isn't suggests strongly to me that it isn't that common
a surprise even for Java and C programmers. This is the first time I've
seen anyone raise it as an issue.

There are plenty of other languages other than Java and C. If we start
listing every feature of Python that's different from some other
language, we'll never end.

Yes, there are plenty of languages other than Java and C, but the
influence of C is admittedly huge in Python. Why do you think loops
are called "for", conditionals "if" or "while", functions return via
"return", loops terminate via "break" and keep going via "continue"
and why is comparison written as "==", etc, etc? All of these are
coming from C (or an even earlier language) and my point is that users
are most of time correct when they assume that something will work the
same way as in C.

So I'd think that putting a warning in a FAQ or a Python Gotchas list
about ++n would be very useful for many users. And it does not imply
that the differences from every other language should be documented in
a similar fashion. Only C

Cheers,
Daniel

 

[Dennis Lee Bieber]

Yes, there are plenty of languages other than Java and C, but the
influence of C is admittedly huge in Python. Why do you think loops
are called "for", conditionals "if" or "while", functions return via
"return", loops terminate via "break" and keep going via "continue"
and why is comparison written as "==", etc, etc? All of these are
coming from C (or an even earlier language) and my point is that users

for, if, and return were common keywords in FORTRAN.

Not to mention BASIC

Both of which predate C

--
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/

 

[Lie Ryan]

Well, like I suggested, it /could/ be made an operator (or rather, a
lexer token) which just causes a compile/parse error.

Cheers,
Chris

There are edge cases (level: very rare) where you legitimately want to
actually do that, e.g.:

class A(object):
def __init__(self, arg):
self.value = arg.value
def __pos__(self):
return B(self)
def __neg__(self):
return D(self)

class B(object):
def __init__(self, arg):
self.value = arg.value
def __pos__(self):
return C(self)
def __neg__(self):
return A(self)

class C(object):
def __init__(self, arg):
self.value = arg.value
def __pos__(self):
return D(self)
def __neg__(self):
return B(self)

class D(object):
def __init__(self, arg):
self.value = arg.value
def __pos__(self):
return A(self)
def __neg__(self):
return C(self)

def cons(val):
class E(object):
value = val
return E()
<__main__.C object at 0x7fbf723c8710>

 

[Daniel Fetchinson]

Yes, there are plenty of languages other than Java and C, but the

for, if, and return were common keywords in FORTRAN.

Not to mention BASIC

Both of which predate C

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

Cheers,
Daniel

 

[Steven D'Aprano]

There are edge cases (level: very rare) where you legitimately want to
actually do that, e.g.:

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


Help on method __pos__ in module decimal:

__pos__(self, context=None) unbound decimal.Decimal method
Returns a copy, unless it is a sNaN.

Rounds the number (if more then precision digits)

 

[Chris Rebert]

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


Help on method __pos__ in module decimal:

__pos__(self, context=None) unbound decimal.Decimal method
   Returns a copy, unless it is a sNaN.

   Rounds the number (if more then precision digits)

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

(Not that I strongly support the prohibition idea, just thought it
should be brought up)

Cheers,
Chris

 

[Bruno Desthuilliers]

Daniel Fetchinson a écrit :
(snip)

and my point is that users
are most of time correct when they assume that something will work the
same way as in C.

Oh, really ? They would surely be wrong if they'd expect the for loop to
have any similarity with a C for loop, or - a *very* common error - if
they'd expect assignment to work the same way as in C.

So I'd think that putting a warning in a FAQ or a Python Gotchas list
about ++n would be very useful for many users.

Might eventually be useful, but I can't hardly recall of more than a
couple threads on this topic in 8+ years.

 

[Bruno Desthuilliers]

Daniel Fetchinson a écrit :

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

Mmm... Should we then claim that "the influence of FORTRAN is admittedly
huge in Python" ?-)

 

[Steven D'Aprano]

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)
....'spam spam spam spam '

 

[MRAB]

for, if, and return were common keywords in FORTRAN.

Not to mention BASIC

Both of which predate C

FORTRAN also used "=" for assignment (and ".EQ." for comparison).

C was derived from BCPL which used ":=" for assignment and "=" for
comparison.

 

[Dave Angel]

Really? What does 'for' do in FORTRAN?

P.S. Does FORTRAN actually have keywords these days? Back when I learned it
there was no such thing as a reserved word though for all I know they may
have since added them.

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).

 

[Daniel Fetchinson]

(snip)

Oh, really ? They would surely be wrong if they'd expect the for loop to
have any similarity with a C for loop, or - a *very* common error - if
they'd expect assignment to work the same way as in C.

Yes, really. I wrote ".... most of the time ....." and not "all the time".

Might eventually be useful, but I can't hardly recall of more than a
couple threads on this topic in 8+ years.

I'm happy we agree.

Cheers,
Daniel

 

[Daniel Fetchinson]

Yes, there are plenty of languages other than Java and C, but the

Mmm... Should we then claim that "the influence of FORTRAN is admittedly
huge in Python" ?-)

Hmmmm, your comments reached a level of pedanticism beyond which I can
not follow
Seriously, ask Guido about the influence of C vs. fortran. 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.

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?

Cheers,
Daniel

 

[Daniel Fetchinson]

and my point is that users

Oh, really ? They would surely be wrong if they'd expect the for loop to
have any similarity with a C for loop, or - a *very* common error - if
they'd expect assignment to work the same way as in C.

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.

Cheers,
Daniel

 

[MRAB]

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.

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?

 

[Stefan Behnel]

I wonder how many people have been tripped up by the fact that

++n

and

--n

fail silently for numeric-valued n.

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

n++

and

n--

which *do* fail with a SyntaxError. I think I faintly remember trying those
in my early Python days and immediately went for "+=" when I saw them fail
(as I had expected).

Stefan

 

[Phil Runciman]

-----Original Message-----
From: Dennis Lee Bieber [mailto:[email protected]]
Sent: Tuesday, 7 July 2009 4:45 p.m.
To: (e-mail address removed)
Subject: Re: A Bug By Any Other Name ...

Yes, there are plenty of languages other than Java and C, but the
influence of C is admittedly huge in Python. Why do you think loops
are called "for", conditionals "if" or "while", functions return via
"return", loops terminate via "break" and keep going via "continue"
and why is comparison written as "==", etc, etc? All of these are
coming from C (or an even earlier language) and my point is that users

for, if, and return were common keywords in FORTRAN.

Not to mention BASIC

Both of which predate C

--
__________________________________________________________________________

Guido was probably influenced by the ALGOL language stream, which used "for" and "if". ALGOL 60 was a joint American and European effort and was significant in the late 50s and 60's.

Guido's fellow countryman, Edsgar Dijkstra, took this publication language (the ALGOL60 version) and produced a compiler for it. (It was not the first, but was very early on). Then B. Randell and L.J. Russell visited him, learnt from his experiences and returned to the UK to produce the KDF9 Whetstone ALGOL60 Compiler. Their book "ALGOL 60 Implementation" was a very early and influential book in the field and occupies a significant place in the history of computing. Computer language designers, including Nicholas Wirth (Pascal, Modula, Oberon), have been influenced by ALGOL.

Sadly, "C" and its ilk, come from a totally different stream of language development beginning with the likes of "CPL", "BCPL", "B" and developing into "C" and "C++". This stream was originally focussed on language portability and performance. This stream was much closer to the assembler language end of the language spectrum, whereas the other stream was heavily biased towards publication and later teaching.

I could say more but will restrain myself.

My 2c

Phil

FWIW "++" reeks of assembler language notation.

The KDF9 Whetstone ALGOL60 Compiler was the one I used at Whetstone for 1-Dimensional Transient Heat-Flow calculations and Steam-Table generation. Our course on it was 2.5 days long. We had wonderful training by English Electric, Kidsgrove staff. I hate to think how long the same course would be now, a month?

 

[Dennis Lee Bieber]

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).
--
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]

Mmm... Should we then claim that "the influence of FORTRAN is admittedly
huge in Python" ?-)

Let's cut out the middle-men, and go to the root...

Abu- ?Abdalla-h Muh.ammad ibn Mu-sa- al-Khwa-rizmi-

(interesting, the cut&paste from Wikipedia put in some rather odd
breaks)
--
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]

P.S. Does FORTRAN actually have keywords these days? Back when I learned it

Okay... you caught me on one... (I probably condensed REXX and
FORTRAN for that one...

DO <label> <indexvar>=<start>,<end>,<inc>
vs
DO <indexvar>=<start> TO <end> BY <inc>

there was no such thing as a reserved word though for all I know they may
have since added them.

And technically, two... Though perhaps one could argue that it did
not have /reserved/ keywords? (These days, I tend to consider keywords
as words that have semantic meaning to the language -- FORTRAN ignored
whitespace, so "words" per se didn't exist... and parsing was a pain...

D O 1 0 I = 1, 10
vs
D O 1 0 I = 1. 10
)

--
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/