> | > ...
> | > It would be more useful if [list methods] returned the listobject that
> | > resulted from the method call. That way I could chain operations
> | > together like so:
> | >
> | > mylist = [1, 2, 3].reverse().append(0).reverse()
> | >
> | > and mylist would == [0, 1, 2, 3].
> |
> | Prediction: You'll lose interest in this after you get more Python
> | coding under your belt. Why? Because it's rarely useful. E.g., if you
> | really want to add something to the start of a list (as you're doing in
> | your example), it's better in every respect to just say
> |
> | list.insert(0, something)
>
> Another thing I should have mentioned is that I've been coding
> Python for a year and a half now and I use the afore-mentioned
> chaining of statements every day!
Yeah Tim! Lay off the ad homonym attacks!
[ Come to think of it, he used the same argument with ME just
a couple of weeks ago! "You'll learn better when you grow up!" ]
Tommy's done some slick stuff. I went over there and strapped on the
old VR helmet just the other day. ( There may be a few bugs still in
the system, though. I got myself all virtually wrapped up in blue
lines, ( and physically wrapped up in cables ), I couldn't stop my
finger from writing in the air, and the virtual reset button didn't do
a damn thing. They had to reboot my world, which, to say the least, is
a traumatic experience! BUT, there is NO indication that Tommy's
coding style has anything to do with those problems!
[ Maybe you ought to send Tim an Alice manual, Tommy! ]
> The example I gave (using a
> list-literal instead of a variable) was just that, an off-the-cuff
> example. Where I use this now is in calling methods of class
> instances. We have our entire VR simulation system coded as a set of
> Python classes (backed in C and C++) and it is our policy (It's in the
> style guide!) that all methods, if they do not explicitly return a
> value (i.e. obj.getValue()) must return 'self'. That way I can say
> things like:
>
> obj.scale(2).moveBy(1,0,0).setColor('green')
>
> It makes for more compact, and if you ask me, more readable code.
> Providing the ability to do this with listobjects (and hopefully some
> day stringobjects!) methods will simply provide the same benefits.
>
I don't think the "proper-style" argument holds much water, but
"Consultant <amrit@xvt.com>" raised some more valid objections.
( That's "more-valid-(than)", not "more (additional), valid"
objections. )
> And speaking of automatic-return-value-output: why is there
> no flag to the interpreter to suppress this output? If I remember
> right there is one that supposedly does this, but it's never checked
> for in the code!
>
$ python -?
python: illegal option -- ?
usage: python [-d] [-i] [-k] [-v] [-c cmd | file | -] [arg] ...
Options and arguments (and corresponding environment variables):
-d : debug output from parser (also PYTHONDEBUG=x)
-i : inspect interactively after running script (also PYTHONINSPECT=x)
-k : kill printing expression statement (also PYTHONKILLPRINT=x)
-v : verbose (trace import statements) (also PYTHONVERBOSE=x)
-c cmd : program passed in as string (terminates option list)
file : program read from script file
- : program read from stdin (default; interactive mode if a tty)
arg ...: arguments passed to program in sys.argv[1:]
Other environment variables:
PYTHONSTARTUP: file executed on interactive startup (no default)
PYTHONPATH : colon-separated list of directories prefixed to the
default module search path. The result is sys.path.
Well - there is '-k' . That may have been what you were thinking
of, but it doesn't do quite what you want:
$ python -k
Python 1.0.1 (Mar 15 1994)
Copyright 1991-1994 Stichting Mathematisch Centrum, Amsterdam
>>> 1 + 2
3
Traceback (innermost last):
File "<stdin>", line 1
RuntimeError: printing expression statement
Obviously, Guido (and Python) considers this an error.
But this raises another question ( one that I think I may have asked
once before ): How can you wrap your whole interactive session in a
try/except clause ? Or, in other words, how can you replace the
default exception handling code ?
- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU>
- UVA Department of Molecular Physiology and Biological Physics