On Thu, 3 Feb 2000 gvwilson@nevex.com wrote:
> I taught Python at Los Alamos National Laboratory for the second time
> two weeks ago, and finally found time last night to go through both
> sets of feedback forms. Given the current discussion on python-dev of
> ternary conditionals, namespaces, etc., I figured syntax issues would
> be most topical.
Wow, these were really informative. Thanks for collecting the results.
> 1. "What's with 'while 1: break' for normal loops?"
I'd probably agree that this is a significant thing. I think
it would be very nice to have do...while, and of all your
examples i liked
do:
first-body
while condition:
second-body
best. This very nicely takes care of the common idiom
do:
line =3D file.readline()
while line:
body
(Once upon a time i even wrote a patch just to handle this
case with a strange "while line from file.readline()" syntax.
I think the above is much nicer.)
> while:
> first-half
> and while condition-1:
> second-half
> and while condition-2:
> third-half # [sic]
> and while final-condition # no trailing ':'
This *is* confusing. Does the "third-half" get executed
if condition-2 is true, or only if condition-1 and condition-2
are both true? Hmmm... i suppose if i interpret each
"and while <cond>" as "if not <cond>: break" it makes more
sense. But i still like the first.
"do" doesn't even have to be made into a keyword for the
do...while construct to work: there is no other valid
construct in which a name would appear followed by a colon
as the first thing in a statement or expression, so the
parser should be able to figure it out.
> 2. "Using range() in for loops is clumsy."
>=20
> My audience does a lot of 'for' loops over numerical bounds, and would
> prefer something slice-ish like:
>=20
> for i in 0:10:2 :
> body
>=20
> I think they could live with:
>=20
> for i in [0:10:2] :
> body
Wow, i like that. There is a nice symmetry to
>>> t =3D (3, 7, 5, 6, 2, 1, 8)
>>> print t[0:5]
(3, 7, 5, 6, 2)
>>> for i in [0:5]: print t[i]
...
3
7
5
6
2
> I believe Brian Harvey mentions somewhere in "Computer Science Logo
> Style" (the best programming books for kids I've ever seen) that it
> was important to make basic counting loops very, very simple to write.
I'd tend to agree with that. This is definitely one of the
first things any beginner will see, and it's nice not to be
sidetracked into an explanation of "range". The symmetry
means that, after they've seen "for i in [0:10]:", they'll
already have a feel for what "list[0:10]" ought to do.
Oh, and having a slice object work in a "for" would allow
us to drop that vaguely irritating range/xrange distinction.
That said, however, i don't think i'd make a really big deal
out of this. Maybe i'm being too swayed by the cuteness of
the idea.
> (While we're on the topic: is there an easy way to construct a slice
> like 3:10, pass it around as a variable, and later use it to index an
> arbitrary sequence?)
I was wondering why this doesn't work. Given that slices are
built in, the lack of discussion of them in the documentation
makes them rather mysterious. It would be nice to make them
just do the expected thing. You could then do things like
putting list[::-1] in an expression without having to copy it
to a temporary, call reverse(), and then use the temporary.
> -------------------------------------------------------------------------
>=20
> 3. "Where is '+=3D' ?" and "Why can't I redefine assignment?"
+=3D would be nice; not a really big deal to me.
Redefining assignment would get way too confusing, i think.
__setitem__ has always been good enough for me.
> -------------------------------------------------------------------------
>=20
> 3.1 Min and Max
Interesting, but doesn't matter much to me.
> -------------------------------------------------------------------------
>=20
> 3.2 Case Statement, and Remembering Matches in Conditionals
>=20
[...]
> One student (a physicist who now does computer graphics) sent me:
>=20
> if x is:
> expr1, expr2:
> code using x (which is either val1 or val2)
> expr3:
> code using x (which is guaranteed to be val3)
> else:
> code using x (which is something else)
I like this quite a lot!
One question: in that last "else" clause, wouldn't "x" be undefined?
> -------------------------------------------------------------------------
>=20
> 5. "Why can't I put an 'except' after an 'if'?"
Possibly interesting, but it doesn't seem necessary to me.
Having the "try:" at the beginning of the block more clearly
delimits what's being protected.
Wouldn't this look weird?
if foo.bar > 0:
blah
else:
blah
except AttributeError:
blah
else:
blah
Now does the "except" cover just the first "else" or both
the bodies of the "if" and the "else"? Alternatively,
imagine that there used to be only an "if" and we wanted to
insert an "else".
It's clear we can't get rid of "try:" altogether, so it seems
like more work to remember the specific list of other situations
in which "except:" might apply...
> -------------------------------------------------------------------------
>=20
> 6. "There is no number six."
And six is RIGHT OUT.
min-sv=E4vare-=E4r-full-med-=E5lar-ly y'rs,
-- ?!ng
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4