This is NOT alt.fan.monty-python. Python is a LANGUAGE.
Jeff Blaine
group, am I the first to post?' just wear off as it always does, but
with the new frequency of postings regarding, 'hey, who says we can't
talk about Monty Python here!?', I felt it time to say a few things.
There is a newsgroup alt.fan.monty-python for the explicit discussion
of Monty Python.
comp.lang.python was created for the discussion of the Python
programming language. The language Python got its name from
Monty Python, as the author states in the source code distribution, but
this is not really the place for discussion of the person, rather
the language.
No, I'm no net.cop, just trying to do something about a situation
that has already gotten out of hand.
If you don't get alt.* groups, well then complain to your News
or System Administrator.
--
Jeff Blaine
jbl...@ciesin.org
CIESIN Operations
Max Headroom
> [ stuff deleted ]
>
> No, I'm no net.cop, just trying to do something about a situation
> that has already gotten out of hand.
It's a fair cop.
-Max
PS: It's a good thing I didn't say anything about the dirty fork!
--
================================================================
| I have no plan. I like to be somewhat spontaneous if I can. |
================================================================
Max Headroom
> [ stuff deleted ]
>
> No, I'm no net.cop, just trying to do something about a situation
> that has already gotten out of hand.
It's a fair cop.
-Max
PS: Good thing I didn't tell him about the dirty fork!
ObOO: cout << "Standard disclaimer\n"
Tommy Burnette
no? Then why is all Python traffic still going to the mailing list
and none to the newsgroup? We certainly can't let ourselves be
daunted by these idiots who don't know the difference between the
comp.lang and the alt.fandom groups.
MY REAL QUESTION: Why do stringobjects not have methods? We have
listobjects that have their own methods so that I can say:
[1, 3, 2].sort()
or:
[1, 2].append(3)
But if I want to do similar operations on stringobjects I have to
import string or strop and pass my strings through these functions.
Why? Why can't I just say:
message = 'get down get'.append(' funky')
I understand that strings are immutable, but is that necessarily the
right thing? I'll often tack things on to the end of a string with:
string = string + char
and this goes and creates a new string object that is the combination
of the first string and the new char. Wouldn't it be more efficient
to simply add the char onto the end of the original string? I
understand I'm poking at a pedagogical hornet's nest here with the
mutable vs. immutable argument (see the socratic discussion concerning
lists and tuples, right?) but could someone please explain it to me
again?
AND ANOTHER THING: Why do the listobject methods always return None?
It would be more useful if they 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]. Is there a reason this would be a
bad thing? the methods have to return SOMETHING, right? How about
something a little more useful than None, eh?
--
-------> Tommy.
"Subvert the parental paradigm - Refuse Birth."
Steven D. Majewski
Tommy Burnette <tn...@Virginia.Edu> wrote:
>MY FIRST QUESTION: We all voted FOR the comp.lang.python newsgroup,
>no? Then why is all Python traffic still going to the mailing list
>and none to the newsgroup? We certainly can't let ourselves be
>daunted by these idiots who don't know the difference between the
>comp.lang and the alt.fandom groups.
>
That's right guys! Let's talk it up in the outfield!
>MY REAL QUESTION: Why do stringobjects not have methods?
BECAUSE: Guido has decreed it!
( The GREAT and *POWERFUL* OZ^H^HGuido ! )
[ I may actually have a serious answer to this, later.
Good work, Tommy: If this doesn't arouse some arguments, we can always
try starting a Syntax Argument again. ( Vote for the "frowning Guido"
diglyph! ) ]
Now that we have comp.lang.python, can we start working on starting
alt.fan.guido ? ( Or is that alt.fan.van.rossum ? :-)
- Steve Majewski (804-982-0831) <sd...@Virginia.EDU>
- UVA Department of Molecular Physiology and Biological Physics
Tim Peters
> and none to the newsgroup?
Well, why did you send this to the list instead of the newsgroup <wink>?
Seriously, because of the usual variety of delays in propagation &
overburdened sysadmins, I bet a lot of sites still don't have the group
-- and won't for a few weeks.
> ... Why do stringobjects not have methods?
You answered it later: "because strings are immutable". Ditto tuples,
and ditto ints, long ints, and floats (don't you miss being able to say
"3.pow(5)" too <grin>?).
The interesting question is _why_ strings and tuples (etc) are immutable,
and I don't have an interesting answer to that. Maybe Guido will shed
more light on these decisions?
> listobjects have their own methods so that I can say:
>
> [1, 3, 2].sort()
Note that this example (indirectly) answers your later question, "Why do
the listobject methods always return None?". If list.method() returned
the updated list, then actually using
[1, 3, 2].sort()
as a line of Python would cause
[1, 2, 3]
to get printed. Remember that Python automatically prints every non-None
expression! Changing Python so that list methods returned anything other
than None would cause massive amounts of existing code to start printing
all sorts of unwanted stuff.
> ... I'll often tack things on to the end of a string with:
>
> string = string + char
>
> and this goes and creates a new string object that is the combination
> of the first string and the new char. Wouldn't it be more efficient to
> simply add the char onto the end of the original string?
Pprobably, if there were no other references to the original value of the
string. I say just "probably" because doing a realloc to extend existing
space may (depending on the host) be more expensive than malloc'ing new
space.
> ...
> 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)
Similarly, it's almost never useful to apply a list method to a list
literal (so you'll almost always have a name by which to get at the
result later).
an-argument-is-a-connected-series-of-statements-intended-to-establish-a-
proposition-ly y'rs - tim the obscure
Tim Peters t...@ksr.com
not speaking for Kendall Square Research Corp
Jaap Vermeulen
>The interesting question is _why_ strings and tuples (etc) are immutable,
>and I don't have an interesting answer to that. Maybe Guido will shed
>more light on these decisions?
I can give you a simple reason:
If strings were mutable any hashing based on strings would become very
tricky. That's why dictionaries don't support lists as keys (or any
mutable object for that matter).
It's not impossible (see Smalltalk), but that would certainly guarantee
some unexpected behavior somewhere down the line. With the current
approach you keep all behavior predictable without really loosing any
functionality.
-Jaap-
--
Jaap Vermeulen +--------------------------+
| Sequent Computer Systems |
Internet : ja...@sequent.com | Beaverton, Oregon |
Uucp : ...uunet!sequent!jaap +--------------------------+
Steven D. Majewski
>
> Tim Peters writes:
> | > ...
> | > 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 <am...@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 ?
Jenni Gregor
: -Max
--
shouldnt that be "dirty knife"? surely it was the dirty fork that
caused the slight over reaction...
-------------------------------------------------------------------------------
Jenni Gregor, Professor of Debauchery and Lunacy, University of Dundee
Scotland. email jgr...@mcs.dundee.ac.uk
-------------------------------------------------------------------------------
Godlike Individual
>Well, I was considering letting the standard freakishness of 'hey, a new
>group, am I the first to post?' just wear off as it always does, but
>with the new frequency of postings regarding, 'hey, who says we can't
>talk about Monty Python here!?', I felt it time to say a few things.
>
>There is a newsgroup alt.fan.monty-python for the explicit discussion
>of Monty Python.
>
>comp.lang.python was created for the discussion of the Python
>programming language. The language Python got its name from
>Monty Python, as the author states in the source code distribution, but
>this is not really the place for discussion of the person, rather
>the language.
I think you're lying.
I KNOW you're lying
FILTHYPIECEOFSCUMMYSCUMMYSHITASSHOLE
love,
Mooney
......................................................................
No disclaimer
......................................................................