IsPython really O-O?
kent...@dxsys.com
had made a big scene saying that it may be a solution to some of our
cross-platform issues) and came away saying that it was no more
object-oriented than Java. I sputtered around a bit but could hardly make a
decent argument, as I'm a mere designer. We do very large-scale industrial
work here, all O-O, with object databases (I thought the ZODB business
looked great). Is my friend right? Is Python not "really" appropriate for
true O-O applications, in the sense that Viz-Age Smalltalk and Eifel and so
on are???
Kent Smith
<embarrassed and kicking himself in Toronto>
Roy Smith
> Is Python not "really" appropriate for true O-O applications, in the
> sense that Viz-Age Smalltalk and Eifel and so on are???
I've never been accused of worrying too much about what's appropriate, so
maybe this answer isn't going to be either :-)
The typical complaint I hear from people when they say Python isn't O-O
enough for them, is that it doesn't have private data. The hard-core O-O
zealot will insist that the only way to access data inside of an object
should be through explicit set/get functions.
I'll admit that there is value to the private/set/get way of life, and
sometimes I do wish Python worked that way. It certainly does give you
some protections that would be nice to have. For example, you wouldn't
need warnings such as (from the documentation for string.whitespace):
"Do not change its definition -- the effect on the routines strip() and
split() is undefined."
On the other hand, I'm too busy writing programs in Python that do useful
things with a minimum of fuss to worry about whether it's "true O-O" or
not. I'll leave that argument to comp.lang.oo.religious-wars.
Peter Hansen
What is it about "true O-O" applications (never heard the term)
which requires the features of Smalltalk and Eiffel?
More likely, depending on what you mean by "large-scale industrial
work" (also a term I've never heard except when applied to heavy
machinery) you will find Python slower than Smalltalk, and unacceptable
to your anti-non-Smalltalk people...
(I use Python for industrial work, use ZODB, and write what I
thought, until now, were "true O-O" applications, and I've been
very happy with it until now. Maybe I should stop? ;-)
> Kent Smith
> <embarrassed and kicking himself in Toronto>
I'd be embarrassed to be living in Toronto too. No, wait! I *am*
living in Toronto! :)
Strange home page you people have...
--
----------------------
Peter Hansen, P.Eng.
pe...@engcorp.com
Tim Hammerquist
> A Smalltalk guru in our organization looked at Python last weekend (after I
> had made a big scene saying that it may be a solution to some of our
> cross-platform issues) and came away saying that it was no more
> object-oriented than Java.
Well, if he didn't think Java was OO, he shouldn't bothered looking at
Python. Besides, no matter how brilliant the programmer, in my
experience, a Smalltalker will never acknowledge anything except
Smalltalk as an OOP. Don't waste your breath. =)
(For the record, I was very impressed with Smalltalk and very much
enjoyed using it. I like it, but it wasn't the ideal solution to the
problem I had; of course, neither is Python all the time...)
> (I thought the ZODB business looked great).
> Is my friend right? Is Python not "really" appropriate for
> true O-O applications,
A majority of people on _this_ NG will tell you Python works quite well
for large OO solutions.
A major problem "pure" or "true" OO advocates have with Python et al. is
data hiding. Encapsulation (at least in the Python-intended sense) is
implemented, but with enough hacking, a coder _could_ access an object's
private data at runtime. This is a serious offense to many OO radicals,
esp. Smalltalkers. OTOH, Python implements a Smalltalk feature: that of
an object's _class_ being a type of _object_ as well. (Perl does _not_
do this; Perl "packages" are simply namespaces adhocked into a var.)
I have no wish to draw this out, merely to bring some (hopefully)
unbiased data to the discussion. If you think Python might help you,
and you can take it for a test drive, try it. _Then_ decide.
HTH
Tim Hammerquist
--
Do "grep UTF toke.c" and all will become clear. (Or as clear as anything
ever is in toke.c.)
-- Larry Wall in <1999090919...@kiev.wall.org>
Erik Max Francis
> A Smalltalk guru in our organization looked at Python last weekend
> (after I
> had made a big scene saying that it may be a solution to some of our
> cross-platform issues) and came away saying that it was no more
> object-oriented than Java.
Java _is_ object-oriented, so I don't see how this is a negative. Note
that object orientation looks a little different in message-oriented
languages (such as Smalltalk or Objective C) rather than in
call-oriented languages (like C++, Java, or Python). Those on either
side of the fence can sometimes be languagist; some Smalltalk users in
particular can be extremely purist about what makes an object-oriented
language. Perhaps your Smalltalk fan is referring to the fact that
Python (like Java) is not the same type of object-oriented language as
Smalltalk, but that doesn't mean that Python (again, like Java) is not
object oriented.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/ \ Laws are silent in time of war.
\__/ Cicero
Esperanto reference / http://www.alcyone.com/max/lang/esperanto/
An Esperanto reference for English speakers.
Matt Gerrans
dare I say) thinks Java (especially) and Python are not OO.
I find it ridiculous when people write off valuable tools with a stupid,
unverifiable and unquantifiable (i.e. subjective) one-liner (eg. "that's just
syntactic candy"), when in fact what they are really trying to hide is the
truth: they are too lazy or afraid to learn something new! I think the real
problem is that this "guru" heard you mention a subject in which he was not a
"guru" and felt insecure. He felt you were trying to steal his thunder and
he lashed out, naturally.
I find this sort of silly writing off of tools very annoying. The one thing
in the (otherwise good) book "The Pragmatic Programmer" that really pissed me
off was when they wrote off Python because its syntax is "slightly quirky."
I later came to understand that the reason they said this was financial: they
wanted to sell their upcoming Ruby book. No intelligent and unbiased person
could call Python's syntax quirky. "Innovative," perhaps, but certainly not
quirky.
Anyway, my point is, writing off a valuable tool with a one-liner is foolish,
defensive behavior and has no place in an engineering environment. The more
tools you have in your toolbox, the better you are at solving problems.
Period.
- Matt
<kent...@dxsys.com> wrote in message
news:AbkH7.41130$bf1.4...@news20.bellglobal.com...
Guido Stepken
MODULA-2/3, LISP, PROLOG, C, C++, JAVA, now Python is:
1. Python is easy to learn
2. Python is easy to keep in mind
3. Pyton is full OO !
4. Python Code is reusable
5. Python has simple to unterstand containers, polymorphism
6. Python is powerfull, but easy to understand
7. Python is fun for kids (my experience !)
8. Python is a full OO language with mighty modules and libraries
9. Python can't keep up with smalltalk or haskell in OO features (i am
missing makro's, but ist's the best compromise I have ever seen.
10. Python is much more readable than Smalltalk, Eiffel, Haskell, Lisp,
C++, JAVA so it's easier for team - programming
11. JAVA is spread all ove the world, but there is JPYTHON !!!!!!!!!!
12. Try Python, an you will see your own !
13. Python has future - see Microsoft Visual Studio implementation of
Python ..... - Even Microsoft likes Python !!!!!!!!!!!!!!!!!!!!!!!!
regards, Guido Stepken
Gerhard Häring
> My experience, coming from many languages (BASIC, ASSEMBLER, PASCAL,
> MODULA-2/3, LISP, PROLOG, C, C++, JAVA, now Python is:
>
> 1. Python is easy to learn
> 2. Python is easy to keep in mind
Modules and functions (and others) are first-class objects, which is something
rarely found in other languages. There are no ugly primitive types like in
Java. So it's at least more OO than any language I know. But then, I don't know
Smalltalk. Hey, if you want to annoy a Smalltalk zealot, why don't you tell him
that his language is far less functional than Haskell, Ocaml or even Python!
And far less type-safe than Ada, Eiffel or Java (this is just my guess, but it
might be true).
> 4. Python Code is reusable
> 5. Python has simple to unterstand containers, polymorphism
> 6. Python is powerfull, but easy to understand
> 7. Python is fun for kids (my experience !)
> 8. Python is a full OO language with mighty modules and libraries
> 9. Python can't keep up with smalltalk or haskell in OO features (i am
> missing makro's, but ist's the best compromise I have ever seen.
Well, I think Python can keap up very well with Haskell's OO features ;-) Not
with functional features, though. But I've heard the list comprehensions were
inspired by Haskell. Never could wrap my head around Haskell's IO, myself.
> 10. Python is much more readable than Smalltalk, Eiffel, Haskell, Lisp,
> C++, JAVA so it's easier for team - programming
> 11. JAVA is spread all over the world, but there is JPYTHON !!!!!!!!!!
> 12. Try Python, an you will see your own !
> 13. Python has future - see Microsoft Visual Studio implementation of
> Python ..... - Even Microsoft likes Python !!!!!!!!!!!!!!!!!!!!!!!!
A minor correction: VisualPython is an ActiveState product. Microsoft has AFAIK
nothin to do with it except that they provide VisualStudio 7 with a plug-in API
for other languages, debuggers, etc.
Gerhard
--
mail: gerhard <at> bigfoot <dot> de registered Linux user #64239
web: http://www.cs.fhm.edu/~ifw00065/ OpenPGP public key id 86AB43C0
public key fingerprint: DEC1 1D02 5743 1159 CD20 A4B6 7B22 6575 86AB 43C0
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))
Tim Hammerquist
Matt Gerrans <mger...@ix.netcom.com> graced us by uttering:
> Roy, I really would like to know why, specifically, your Smalltalk guru (snob,
> dare I say) thinks Java (especially) and Python are not OO.
[ snipped throwing down of gauntlet ]
Them 're fightin' w'rds.
If you really need to raise a discussion, the posters
comp.lang.smalltalk will be more than happy to tell you why it is that
you and hundreds of programming langauges are brain-dead for even
dreaming they could get to OO from where they started.
I, for one, have had this discussion a dozen times and have not
progressed any further in the latter 11 than I did in the first.
$ cat debate
#!/usr/local/bin/python
assert time is infinite
steve = Zealot(SmallTalk)
matt = Advocate(Python)
while isinstance(steve, Zealot):
try:
matt.argue()
if isconvinced(steve):
break
pigs.fly()
steve.say("I'm not convinced.")
except:
steve.say("Hah! You can't prove it!")
$ chmod 700 debate
$ debate and echo "They all lived happily ever after."
Tim Hammerquist
--
As someone pointed out, you could have an attribute that says "optimize
the heck out of this routine", and your definition of heck would be a
parameter to the optimizer.
-- Larry Wall in <1997090818...@wall.org>
Tim Hammerquist
[ snip ]
> 13. Python has future - see Microsoft Visual Studio implementation of
> Python ..... - Even Microsoft likes Python !!!!!!!!!!!!!!!!!!!!!!!!
Visual Python is distributed by ActiveState.
Visual Perl is also distributed by ActiveState.
Microsoft certainly doesn't "like" Perl (as inferred from it's attempted
license agreement.
Tim Hammerquist
--
The mind of a bigot is like the pupil of the eye.
The more light you shine on it, the more it will contract.
-- Oliver Wendell, Jr. Holmes
Edward Diener
that when he says a word it means what he wants it to mean. No doubt
your Smalltalk guru has his own definition of OOP so even if you ask him
you will just be arguing against someone whose idea of OOP is Smalltalk,
or some such similar nonsense. A more effective response would have been
to ask him what he didn't like about Python. Maybe then you could have
had an intelligent conversation with him. OOP is so personal that
arguing about it is a huge waste of time.
Guido Stepken
with cygnus (now redhat) GNUPRO suite. Microsoft has bought a Content
Management System (CMS), which was written in Python......and they rewrote
it in C++ .....hmmm.... seems, they haven't unterstood really......But i am
happy with microsofts change-mind in things like opensource, .net. But
their licenses are still horror (EULA). IMHO they do forbid the use of
their software together with GPL ....but i have no evidence (i dont't use
M$ !). I there anybody out there, who has a copy of this M$ license ?
regards, Guido Stepken
>Gerhard Häring wrote:
...
Daniel Dittmar
would make it easier to decide which of these differences are really
important.
This list is based on Digitalk SmallTalk of 7 years ago, so it might be
dated.
- no strict data encapsulation in Python: true, but I would rate this in the
same area as static type checks
- Classes are objects in Python, but there are used in a different way,
especially when constructing objects. In Python, the runtime creates a new
object and calls the appropriate __init__ method (this is similar to Java).
In Smalltalk, you call a class method. If this method somehow manages to
call 'Object new', then a new object gets created. This approach makes it
somewhat easier to create multiple constructor methods. <Asbestos>I didn't
say it is impossible to have multiple object creation routines in
Python.</Asbestos>
- no multiple return values in Smalltalk (still true?). One could argue that
having a separate class for all such cases is more object oriented. One
could also argue that such nonessential helper classes are simply fluff.
- no code blocks in Python: Python allows to pass callables around, but
lambdas are simply too limited for most purposes. Handling collections in
Python has more of a functional heritage (applying filter to a UserList will
return a list, not a UserList). With all the elements available in Python
2.2 (nested scopes, inheritance from C-classes), it is probably possible to
implement something similar to the Smalltalk collection hierarchy.
- calling conventions are very different (has really nothing to do with
O-O). The Smalltalk syntax does not allow for default arguments (yes, you
can fake them with additional methods) or passing of dictionaries through
keyword arguments. On the other hand, I still believe a listing of Smalltalk
methods gives me a better idea of the functionality than the equivalent in
Python (compare 'from:for:' or 'from:to:' with 'substring')
- adding of code at runtime: Smalltalk allows this, but at least commercial
implementions will remove this from the freely redistributable runtime.
- With Carlton University nearby, anything other than Smalltalk will be a
tough sell.
Daniel
Tim Hammerquist
Hash: SHA1
Guido Stepken <ste...@little-idiot.de> graced us by uttering:
[ snip ]
> IMHO they do forbid the use of
> their software together with GPL ....but i have no evidence (i dont't use
> M$ !). I there anybody out there, who has a copy of this M$ license ?
I tried to follow the links from a slashdot.org article, but MS seems to
have moved the page. A search for 'MIT EULA' on msdn.microsoft.com
returned four URLs, the third of which follows:
http://msdn.microsoft.com/Downloads/eula_mit.htm
Some interesting excerpts:
The Restriction:
[ snip ]
: (c) Open Source. Recipient's license rights to the Software are
: conditioned upon Recipient
: (i) not distributing such Software, in whole or in part, in
: conjunction with Potentially Viral Software (as defined
: below); and
: (ii) not using Potentially Viral Software (e.g. tools) to
: develop Recipient software which includes the Software,
: in whole or in part.
[ snip ]
The Definition:
: Recipient shall not distribute the Software, in whole or in part,
: in conjunction with any Publicly Available Software.
[ snip ]
: Publicly Available Software includes, without limitation, software
: licensed or distributed under any of the following licenses or
: distribution models, or licenses or distribution models similar to
: any of the following:
: (A) GNU's General Public License (GPL) or Lesser/Library GPL (LGPL),
: (B) The Artistic License (e.g., PERL),
: (C) the Mozilla Public License,
: (D) the Netscape Public License,
: (E) the Sun Community Source License (SCSL), and
: (F) the Sun Industry Standards License (SISL).
[ snip ]
The rest of the EULA adds more legalspeak, but it doesn't get any more
lenient. I believe MS was trying to see how this would go over in the
community and decided to test it with a pre-release version of software
in case users raised too much of a fuss.
Cheers!
Tim Hammerquist
- --
You know, we've got armadillos in our trousers.
It's really quite frightening.
-- Nigel Tufnel, "This is Spinal Tap"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE7795R8vyBPhAeHacRAqCoAJ4kDHQnnxtvt6XhZw/9tZTN05q4OQCfXTgC
xJDr6FUNbB0ETA5t04QpNJI=
=pAsi
-----END PGP SIGNATURE-----
Gerhard Häring
> VisualPython is a windows port of the unix python from G.v.Rossum, done
> regards, Guido Stepken
You've got that wrong! Trust me. My description is the correct one :-) Go read
the ActiveState page for the description:
http://www.activestate.com/Products/Visual_Python/
"""Visual Python is the full-featured Python plug-in for Visual Studio .NET,
providing a rich development environment for programmers who wish to use Python
within Visual Studio .NET.
Unlike other Python IDEs and editors, Visual Python was written specifically
for Visual Studio .NET, allowing programmers to fully leverage the features of
Microsoft's powerful development tool suite."""
A quick google check reveals that a win32 port of Python exists at least since
Python *1.2*.
Gerhard
> >Gerhard Haering wrote:
> ...
> > A minor correction: VisualPython is an ActiveState product. Microsoft has
> > AFAIK nothin to do with it except that they provide VisualStudio 7 with a
> > plug-in API for other languages, debuggers, etc.
> >
> > Gerhard
Stuart D. Gathman
<t...@vegeta.ath.cx> wrote:
> A major problem "pure" or "true" OO advocates have with Python et al. is
> data hiding. Encapsulation (at least in the Python-intended sense) is
> implemented, but with enough hacking, a coder _could_ access an object's
> private data at runtime. This is a serious offense to many OO radicals,
> esp. Smalltalkers.
That is a silly objection. Smalltalk implements data hiding, but with
enough hacking, a coder _could_ access an objects private data at runtime
(via (ab)use of introspection, dynamic class modification, generic
persistance mechanisms, etc. etc.).
So I guess ST isn't O-O either by that criterion. In general, if a language
provides for generic persistence or debuggers written in that
language, then those features can be abused to violate encapsulation.
This is why introspection and persistence are considered security
sensitive in the Java system.
--
Stuart D. Gathman <stu...@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - Mozart background
song for the Microsoft "Where do you want to go from here?" commercial.
Jason Voegele
Unfortunately, everybody has their own opinion on what "is OO", and
what is "pure OO". Personally, I don't consider Python to be a pure
OO language. I consider it a hybrid language with support for OO, but
that doesn't mean it's not useful. I've formulated my own opinion
about what makes a language "Pure OO", which you can read here:
http://www.jvoegele.com/software/langcomp.html
Please note that this is not complete, and that it is not intended to
say language x is better than language y. I'd appreciate feedback if
I've misrepresented anything, though.
Also note that just because a language is not "pure OO", does not mean
that you cannot create OO applications with it. Java is not pure OO,
but supports OO well enough to create OO
applications/frameworks/libraries/etc.
Jason Voegele
James_...@i2.com
Kent Smith wrote:
>A Smalltalk guru in our organization looked at Python last weekend (after
I
>had made a big scene saying that it may be a solution to some of our
>cross-platform issues) and came away saying that it was no more
>object-oriented than Java. I sputtered around a bit but could hardly make
a
I worked in the LRG group (Learning Research Group, aka the Smalltalk team)
at Xerox PARC in the late seventies / early eighties under Alan Kay and
Adele Goldberg and helped design and implement the original Smalltalk-80.
Therefore, by the powers vested in me by no one in particular, I hereby
proclaim Python to be
"Plenty-good OO!"
Helpfully yours,
Jim
Nahuel Greco
ja...@jvoegele.com (Jason Voegele) wrote:
> <kent...@dxsys.com> wrote in message news:<AbkH7.41130$bf1.4...@news20.bellglobal.com>...
> > A Smalltalk guru in our organization looked at Python last weekend (after I
> > had made a big scene saying that it may be a solution to some of our
> > cross-platform issues) and came away saying that it was no more
> > object-oriented than Java. I sputtered around a bit but could hardly make a
> > decent argument, as I'm a mere designer. We do very large-scale industrial
> > work here, all O-O, with object databases (I thought the ZODB business
> > looked great). Is my friend right? Is Python not "really" appropriate for
> > true O-O applications, in the sense that Viz-Age Smalltalk and Eifel and so
> > on are???
>
> Unfortunately, everybody has their own opinion on what "is OO", and
> what is "pure OO". Personally, I don't consider Python to be a pure
> OO language. I consider it a hybrid language with support for OO, but
> that doesn't mean it's not useful. I've formulated my own opinion
> about what makes a language "Pure OO", which you can read here:
>
> http://www.jvoegele.com/software/langcomp.html
>
I share that opinion and the ones in your page, but you are making a common
mistake, you must view ST as a language/syntax, but also as an "Object Ambient",
or "Box with objects to play". The language really doesnt matter too much, you
can make other parsers in the Ambient (i know Lisp & Prolog in ST, but not
python).
By now, the unique "Objects Ambients" that i know are ST and Self, and i think
that CLOS classifies also, but without tools (browsers, etc, or yes?). And
ZOPE a little, but i dont like it too much :)
The really revolutionary thing is the concept of "Objects Box", where you
program / use manipulating objects.
I think that is the future, if you see the trend in the OS camp, you see that
for example, OLE, COM, and .NET or any component model is trying to reach that.
Also the inclusion of metadata in the filesystems. Or the uniformity of device
access / file access in Unix.
In the end of the road, your computer will be full of objects, not "documents"
and "binaries", all visually manipulable in a Gibson way :)
- Nahuel Greco Web Development - Open Source -
- http://www.codelarvs.com.ar Game Programming - Research -
- Freelance coding / sysadmin Networking. The answer is 42. -
Adam Spitz
> Well, if he didn't think Java was OO, he shouldn't bothered looking at
> Python. Besides, no matter how brilliant the programmer, in my
> experience, a Smalltalker will never acknowledge anything except
> Smalltalk as an OOP. Don't waste your breath. =)
For what it's worth, I consider myself a Smalltalker, and I like
Python very much. I don't give a hoot about OO purity - I like
Smalltalk because I'm really productive in it, and I like Python for
the same reason. (Ruby, too. ;)
But then, maybe I'm in the minority...
Adam Spitz
Guido Stepken
to produce (distribute) code, consisting of (L)GPL Software and Microsoft
OpenSource. One is not allowed to mix code. BSD License + Microsoft Code,
that's OK !
Any ideas, why ?
regards, Guido Stepken
>Tim Hammerquist wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
...
Rainer Deyke
news:9sph0u$gj7$02$1...@news.t-online.com...
> Thanx lots for checking this out ! Hmmm, that means, that it is forbidden
> to produce (distribute) code, consisting of (L)GPL Software and Microsoft
> OpenSource. One is not allowed to mix code. BSD License + Microsoft Code,
> that's OK !
> Any ideas, why ?
It makes perfect sense to me. BSD licensed code plays along nicely with
closed source. The GPL, on the other hand, is designed to give open source
developers a competitive advantage over closed source developers, with the
ultimate goal of forcing closed source developers out of business.
--
Rainer Deyke (ro...@rainerdeyke.com)
Shareware computer games - http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor
Cliff Wells
>
> It makes perfect sense to me. BSD licensed code plays along nicely with
> closed source. The GPL, on the other hand, is designed to give open source
> developers a competitive advantage over closed source developers, with the
> ultimate goal of forcing closed source developers out of business.
>
On the plus side, this may end the debate over BSD vs GPL vs Python license
vs whatever: if Microsoft says the BSD license is okay, it must not be <wink>.
--
Cliff Wells
Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308
(800) 735-0555 x308
Chris Tavares
"Guido Stepken" <ste...@little-idiot.de> wrote in message
news:9sph0u$gj7$02$1...@news.t-online.com...
> to produce (distribute) code, consisting of (L)GPL Software and Microsoft
> OpenSource. One is not allowed to mix code. BSD License + Microsoft Code,
> that's OK !
> Any ideas, why ?
>
> regards, Guido Stepken
>
Simple - the Microsoft code in question is NOT open source in any way, shape
or form. It does include some source code and program samples, but it's not
open source, and the end user does not have redistribution rights.
The phrases in the EULA doesn't really add anything - actually, the GPL
includes the same clause (If you link GPL code with non-GPL code, you can't
release the program unless you change the license of the non-GPL code). It's
just Microsoft's lawyers & marketing dept. getting together and rattling
their sabers.
The reason that the BSD license works with MS code is that the BSD license
says, basically "use this, but you can't sue us." No requirements to change
licensing on any other code.
-Chris
Tim Hammerquist
> Tim Hammerquist wrote:
>> Besides, no matter how brilliant the programmer, in my experience,
>> a Smalltalker will never acknowledge anything except Smalltalk as
>> an OOP. Don't waste your breath. =)
> For what it's worth, I consider myself a Smalltalker, and I like
> Python very much. I don't give a hoot about OO purity - I like
> Smalltalk because I'm really productive in it, and I like Python for
> the same reason. (Ruby, too. ;)
This is the exact reason I included that phrase. =) Also, it might have
been an unconscious attempt to bring some of the less argumentative
Smalltalkers out of hiding. Your opinion may be quieter, but it's not
any less important.
> But then, maybe I'm in the minority...
Before your post, every Smalltalker I'd talked to said something very
similar to "That's alright, but if you want a _real_ OO language,
look at Smalltalk."
> Adam Spitz
Cheers!
Tim Hammerquist
--
Emacs is a nice OS - but it lacks a good text editor.
That's why I am using Vim.
-- Anonymous
Tim Hammerquist
Hash: SHA1
Guido Stepken <ste...@little-idiot.de> graced us by uttering:
[ snipped excerpt from MS MIT EULA ]
> Thanx lots for checking this out ! Hmmm, that means, that it is forbidden
> to produce (distribute) code, consisting of (L)GPL Software and Microsoft
> OpenSource. One is not allowed to mix code. BSD License + Microsoft Code,
> that's OK !
> Any ideas, why ?
The BSD license is unrestrictive. I can take an entire BSD-licensed
file, cut-and-paste it into my own project, sign, seal, and
deliver...and not even have to mention where I got it.
This is fine by Microsoft because it means if they find anything they
want somewhere inside a Berkeley Quality Software project, they can just
take it.
What I think was even more appalling was the restriction on
<citation>
: (ii) not using Potentially Viral Software (e.g. tools) to
: develop Recipient software which includes the Software,
: in whole or in part.
</citation>
This means I can't
- test a script using a perl binary that falls under the (default)
Artistic License.
- test a script using a Python binary that falls under the GPL
compatible license.
- _use_ Vim or Emacs to edit _any_ file in the project I'm developing.
- make a tarball of a directory tree using GNU tar or GNU gzip.
- ...and so on
Limitations on the product distributed is nothing new. OTOH, Microsoft
has just attempted to make it _ILLEGAL_ to use a python binary I've
compiled myself (though ActivePython is probably alright). _This_ is
what a _huge_ number of people are upset about.
Opinions? Rebuttals?
Tim Hammerquist
- --
There's something to be said for returning the whole syntax tree.
-- Larry Wall in <1997102218...@wall.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE78KHt8vyBPhAeHacRAjQkAJ0ThoHmEb+edkRyibQBXh/Lsbx0pQCdFxt/
zk6p9bOHMWfhBRXo8/F9PWI=
=nzLy
-----END PGP SIGNATURE-----
goonfist
Indeed by Smalltalks standards, many OO things , python included ,
aren't reeeeealy truly
objecto-puro-oriento , but there we have it! Endorsement!
That said , python doesnt encourage you to directly fiddle with
'properties',
but rather fiddle with 'methods' , so it's pretty good like that.
James_...@i2.com wrote in message news:<mailman.1005592816...@python.org>...
Matt Gerrans
> If you really need to raise a discussion, the posters
> comp.lang.smalltalk...
Okay, I'm off to the smalltalk group to declare that "Python is more OO than
Smalltalk!" Who will ensure that I get a decent burial?
> $ cat debate
> #!/usr/local/bin/python
>
> assert time is infinite
> steve = Zealot(SmallTalk)
> matt = Advocate(Python)
>
> while isinstance(steve, Zealot):
> try:
> matt.argue()
> if isconvinced(steve):
> break
> pigs.fly()
> steve.say("I'm not convinced.")
> except:
> steve.say("Hah! You can't prove it!")
>
> $ chmod 700 debate
> $ debate and echo "They all lived happily ever after."
Cute, I like it! (although I don't claim to be a Python Advocate -- I
advocate using the best tool for the job, which means the more tools you know
how to use, the better your odds are).
- mfg
Steve Holden
>
> Guido Stepken <ste...@little-idiot.de> graced us by uttering:
>
> [ snipped excerpt from MS MIT EULA ]
>
> > Thanx lots for checking this out ! Hmmm, that means, that it is
forbidden
> > to produce (distribute) code, consisting of (L)GPL Software and
Microsoft
> > OpenSource. One is not allowed to mix code. BSD License + Microsoft
Code,
> > that's OK !
> > Any ideas, why ?
>
> The BSD license is unrestrictive. I can take an entire BSD-licensed
> file, cut-and-paste it into my own project, sign, seal, and
> deliver...and not even have to mention where I got it.
>
> This is fine by Microsoft because it means if they find anything they
> want somewhere inside a Berkeley Quality Software project, they can just
> take it.
>
> What I think was even more appalling was the restriction on
>
> <citation>
> : (ii) not using Potentially Viral Software (e.g. tools) to
> : develop Recipient software which includes the Software,
> : in whole or in part.
> </citation>
>
> This means I can't
>
> - test a script using a perl binary that falls under the (default)
> Artistic License.
> - test a script using a Python binary that falls under the GPL
> compatible license.
> - _use_ Vim or Emacs to edit _any_ file in the project I'm developing.
> - make a tarball of a directory tree using GNU tar or GNU gzip.
> - ...and so on
>
> Limitations on the product distributed is nothing new. OTOH, Microsoft
> has just attempted to make it _ILLEGAL_ to use a python binary I've
> compiled myself (though ActivePython is probably alright). _This_ is
> what a _huge_ number of people are upset about.
>
> Opinions?
<soapbox>
Microsoft is a rabidly commercial organisation with little idea of the
trouble it is storing up for itself. If I were a stockholder I would be
incensed at the behavior of the corporate officers. They still deny any
wrongdoing after having been declared a monopolist in the US courts. They
still attempt to impose unreasonable terms in licenses.
One measure of the success (or otherwise) of the DoJ settlement, should it
go through, will be the Samba team's ability to shoehorn a proper protocol
description out of MS. Given the current verbiage, the Samba team aren't
optimistic.
I firmly believe Microsoft will be the first IBM of the 21st century, and
some unstoppable market force will unseat them before they realise how wrong
they are. Look how nearly they missed the Internet boat, believing they
could turn the Internet into a Microsoft network. The really dumb feature is
that they don't appear to have learned much from all that.
</soapbox>
> Rebuttals?
>
Since the Python license is as liberal as it is, there is no reason why a
Python binary has to be GPL, just because (say) you compiled it with gcc.
But that apart, your description of the terms and conditions of Microsoft's
EULA seems fair, and less biased than, say, my own sclerotic reactions.
regards
Steve
--
http://www.holdenweb.com/
Adam Spitz
> Adam Spitz <adam...@bigfoot.com> graced us by uttering:
>
> > For what it's worth, I consider myself a Smalltalker, and I like
> > Python very much. I don't give a hoot about OO purity - I like
> > Smalltalk because I'm really productive in it, and I like Python for
> > the same reason. (Ruby, too. ;)
>
> This is the exact reason I included that phrase. =) Also, it might have
> been an unconscious attempt to bring some of the less argumentative
> Smalltalkers out of hiding.
OK, I'm out of hiding. :) Anything in particular you'd like to
discuss?
> Before your post, every Smalltalker I'd talked to said something very
> similar to "That's alright, but if you want a _real_ OO language,
> look at Smalltalk."
I *do* think that Smalltalk's got some advantages over Python, but I
don't think they're in the area of OOness. In terms of OO, Python has
everything I want.
Does anybody mind if I gripe a bit? (If you do, stop reading now. :) I
don't mean to piss anybody off. I'd just like to offer an outsider's
perspective. I promise to be as unbiased as I know how to be.
I'd be interested to see the current state of Python development
environments. That's where Smalltalk really shines, and I've never
seen an environment for any other language even come close. That's
understandable, because Smalltalk's whole, um, paradigm is optimized
for that kind of thing. Holding everything inside a monolithic image
makes it really easy to create spectacular tools (but, of course, also
costs Smalltalk a lot, like the ability to use Smalltalk for small
scripts). In particular, I'd like to see the Python Refactoring
Browser efforts bear fruit.
I'm kinda annoyed about Python's silly type/class distinction. But
then, so are you, and I'm glad to see the efforts at unification
progressing.
I'm also kinda annoyed that Python introduced generators, list
comprehensions, and crippled lambdas to deal with an issue that
Smalltalk solves very neatly with its blocks. Still, most of my use of
blocks in Smalltalk is for conditionals (done in Python with nice,
plain "if" statements), and #do and #select and #collect (done in
Python with "for" statements and list comprehensions, and I kinda like
having the more convenient syntax). So in real life, most of the time
I don't even notice the lack of blocks. (I was surprised to realize
this. I'd like to know if other Smalltalk/Ruby programmers'
experiences with Python have been the same.)
I'd like to see Python stop hiding its dynamic side. I had a
discussion with some Python folks over at Ward Cunningham's Wiki
(http://c2.com/cgi/wiki) a while ago, and I left with the impression
that Python was dynamic enough to do the things that I wanted, but
forced me to jump through some hoops to do them. (And that really
surprised me, because I *know* that the Python community takes pride
in Python's dynamicness and intuitiveness.) First example that comes
to mind: adding methods to an existing class. In Smalltalk, I'd just
browse over to that class and add the method. In Ruby, I'd just write:
class MyClass
def newMethod()
print "new method"
end
end
... and it'd add the new method to the class. In Python, I think I
have to define the method as a function *outside* the class and then
assign it as an attribute on the class:
def MyClass_newMethod(self):
print "new method"
MyClass.newMethod = MyClass_newMethod
I smiled just now when I realized that the Python version is actually
fewer lines of code. :) But I still don't think it feels right. In
Smalltalk and Ruby, I'm just using the standard mechanism for adding
methods to a class. In Python, it feels like I'm sneakily hacking an
extra method into a class against its will. (Does that make any sense?
Maybe I'm being too touchy-feely. :)
(Sorry for digressing into Ruby. I just wanted to point out there *is*
an intuitive syntax - at least, a syntax that *I* find intuitive :) -
for this sort of thing, even for conventional file-based languages.)
Oh, and I've been meaning to ask - is there a way for me to add
methods to Dict or List or String? I couldn't figure out how to do it,
and that's where I *really* want it.
Anyway, I'd better stop now. I don't want to piss too many people off
too quickly. :) I really do like Python a lot, and I'd be delighted if
I ever got the opportunity to use it in an actual work environment.
(If I had any control over my life, I'd push for it. ;) But maybe it's
useful to hear the perspective of an almost-reasonable person from
outside the community.
Adam Spitz
Andrew Dalke
>First example that comes
>to mind: adding methods to an existing class. In Smalltalk, I'd just
>browse over to that class and add the method. In Ruby, I'd just write:
>
>class MyClass
> def newMethod()
> print "new method"
> end
>end
[in Python]
>def MyClass_newMethod(self):
> print "new method"
>MyClass.newMethod = MyClass_newMethod
I've been toying around with proposing
def MyClass.newMethod(self):
print "new method"
but I've never really needed it. Better I think would be if
Python's IDE's offered a reload() which was closer to Smalltalks's,
where a modified class definition propagates even to existing
instances of that class. So someone could edit a module and
manipulate things interactively without having to reload and rerun
everything.
> In Python, it feels like I'm sneakily hacking an
>extra method into a class against its will. (Does that make any sense?
>Maybe I'm being too touchy-feely. :)
When I first started Python, I wrote a class like:
class Spam:
def __init__(self, x):
self.x = x
def show(self):
print self.x
After I figured out it worked, I wanted to add a new method, so
I did
class Spam:
def double(self):
self.x = self.x * 2
then was annoyed that it didn't work the way I expected. So I
don't think you are alone in this view. I bring it up here because
I suspect for many people this is forgotten amoung all the other
confusions in the early stages of learning Python.
>Oh, and I've been meaning to ask - is there a way for me to add
>methods to Dict or List or String? I couldn't figure out how to do it,
>and that's where I *really* want it.
No. You can only add them to subclasses of those types, and
only in Python 2.2. You *can* add them to UserDict, UserList, and
UserString.
I've never liked that idea though (which Smalltalk and Ruby both
have). I think adding methods to an existing class is like
playing around with global variables. What's to keep two different
libraries from adding a method with the same name but which
does different things?
Andrew
da...@dalkescientific.com
Ian Bicking
> Java _is_ object-oriented, so I don't see how this is a negative. Note
> that object orientation looks a little different in message-oriented
> languages (such as Smalltalk or Objective C) rather than in
> call-oriented languages (like C++, Java, or Python).
If you look under the hood, Python is much more like Smalltalk than
Java. The message-passing of smalltalk is the same as a function call
-- though the syntax obscures that. The (subtle) difference between
message-passing and method-calling is that message passing *sends*
something to the object, while calling *calls* something. Calling
implies that the language pretty much knows what's being called before
it calls it.
Python is really sending, not calling. You don't (ever) know before
runtime what function definition is going to be invoked. By
overriding __getitem__ and other special methods, you can make the
object fully dynamic -- just like you can do in Smalltalk, but can't
do in Java. (There are some holes in Python with respect to this, but
they are all being filled so they should be ignored for this argument)
Maybe to explain this a bit more: in Smalltalk every method call is
like sending a message to the object. So when you do (someObject
moveTo: 10) you are actually sending (#moveTo:, 10) to the object,
which it can interpret as it wants. It usually searches its class for
a method definition named #moveTo:, but it does not have to. The
exact same thing happens in Python. when you do
(someObject.moveTo(10)) in python, you are sending ("moveTo", 10) to
the object. Most of the time it searches the class for a method named
"moveTo", but the object can really do anything it wants with it.
This is why both Python and Smalltalk are message passing languages.
Python starts out from somewhere different than Smalltalk --
particularly that it's default object model is much more concrete and
not altogether as regular. But you can go to all the same places.
And what makes Smalltalk so cool -- that you can have so much power
over the language and objects, so that an object can pretend to be
anything you want it to be -- is also true for Python. And it's
getting truer all the time as 2.x progresses.
Prabhu Ramachandran
AD> but I've never really needed it. Better I think would be if
AD> Python's IDE's offered a reload() which was closer to
AD> Smalltalks's, where a modified class definition propagates
AD> even to existing instances of that class. So someone could
AD> edit a module and manipulate things interactively without
AD> having to reload and rerun everything.
That would be incredibly cool but is most probably very hard to do?
prabhu
Gerhard Häring
> [...]
>
> class Spam:
> def __init__(self, x):
> self.x = x
> def show(self):
> print self.x
>
> After I figured out it worked, I wanted to add a new method, so
> I did
>
> class Spam:
> def double(self):
> self.x = self.x * 2
>
> then was annoyed that it didn't work the way I expected. So I
> don't think you are alone in this view. I bring it up here because
> I suspect for many people this is forgotten amoung all the other
> confusions in the early stages of learning Python.
Hey, you could have written:
class Spam(Spam):
...
It doesn't really add a method to the class, but at least it looks nicer.
What I miss(ed) was overloadable function and method signatures.
Gerhard
--
The information transmitted in this message (if any) is intended only for the
person or entity to which it is addressed. The message may contain
confidential and/or privileged material. It doesn't really matter, we will
append this lengthy legalese mumbo-jumbo anyway. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon this
information, by persons or entities other than the intended recipient is
prohibited. The same goes for the intended recipient herself.
If you have received this in error, please contact your lawyer and delete this
e-mail and everything else from any computer in your vicinity.
The intended recipient of this e-mail may only use, reproduce, disclose or
distribute the information contained in this e-mail and any attached files,
with the permission of BigBrother Inc.
This message has been scanned for anti-Microsoft propaganda and cleared by
MailMarshal.
Thomas Heller
AD> but I've never really needed it. Better I think would be if
AD> Python's IDE's offered a reload() which was closer to
AD> Smalltalks's, where a modified class definition propagates
AD> even to existing instances of that class. So someone could
AD> edit a module and manipulate things interactively without
AD> having to reload and rerun everything.
Here's a script I'm sometimes working on which does this.
It's not bulletproof, but it kindof works.
It runs a thread in the background (once started), which checks
the timestamp of all modules loaded from the filesystem.
It it's out of date, is is reloaded automatically.
Classes and functions in the reloaded module are
updated automatically to the new version.
Hopefully sometime I will complete it and post it to the Python Cookbook.
Thomas
---- autoreload.py ----
#
# autoreload.py - automatically reload changed source
# code into a running program
#
# You may want to place the following two lines
# into your sitecustomize.py:
#
# import autoreload
# autoreload.run()
#
# Created: Thomas Heller, 2000-04-17
#
# $Id: autoreload.py,v 1.8 2001/11/13 20:44:51 thomas Exp $
#
# $Log: autoreload.py,v $
# Revision 1.8 2001/11/13 20:44:51 thomas
# Clean up a little...
#
# Revision 1.7 2001/10/05 16:38:35 thomas
# Assure a clean shutdown of the thread with atexit
#
# Revision 1.6 2001/10/04 19:21:46 thomas
# Only some comments added and a typo fixed.
#
# Revision 1.3 2001/10/04 18:37:54 thomas
# Stores now old objects with (modulename, objectname) as keys.
#
# Revision 1.1 2001/10/04 16:54:04 thomas
# Discovered this old module on my machine, it didn't work too well,
# but seems worth to continue with it...
# Checked in as a first step.
version = "$Revision: 1.8 $".split()[1]
# ToDo:
#
# Cannot reload __main__ - explain why this cannot work
#
# Optimize - the number of watches objects (in old_objects)
# grows without limits. Think if this is really necessary...
import time, os, threading, sys, types, imp
def _get_compiled_ext():
for ext, mode, typ in imp.get_suffixes():
if typ == imp.PY_COMPILED:
return ext
PY_COMPILED_EXT = _get_compiled_ext()
class ModuleWatcher:
running = 0
def __init__(self):
# If we don't do this, there may be tracebacks
# when shutting down python.
import atexit
atexit.register(self.stop)
def run(self):
if self.running:
print "# autoreload already running"
return
self.running = 1
self.thread = threading.Thread(target=self._check_modules)
self.thread.setDaemon(1)
self.thread.start()
def stop(self):
if not self.running:
print "# autoreload not running"
return
self.running = 0
self.thread.join()
## print "# autoreload stopped"
def _check_modules(self):
## print "# autoreload running"
while self.running:
time.sleep(0.01)
for m in sys.modules.values():
if not hasattr(m, '__file__'):
continue
if m.__name__ == '__main__':
# we cannot reload(__main__) First I thought we
# could use mod = imp.load_module() and then
# reload(mod) to simulate reload(main), but this
# would execute the code in __main__ a second
# time.
continue
file = m.__file__
dirname = os.path.dirname(file)
path, ext = os.path.splitext(file)
if ext.lower() == '.py':
ext = PY_COMPILED_EXT
file = os.path.join(dirname, path + PY_COMPILED_EXT)
if ext != PY_COMPILED_EXT:
continue
try:
if os.stat(file[:-1])[8] <= os.stat(file)[8]:
continue
except OSError:
continue
try:
superreload(m)
except:
import traceback
traceback.print_exc(0)
def superreload(module,
reload=reload,
_old_objects={}):
"""superreload (module) -> module
Enhanced version of the builtin reload function.
superreload replaces the class dictionary of every top-level
class in the module with the new one automatically,
as well as every function's code object.
"""
start = time.clock()
# retrieve the attributes from the module before the reload,
# and remember them in _old_objects.
for name, object in module.__dict__.items():
key = (module.__name__, name)
_old_objects[key] = _old_objects.get(key, []) + [object]
module = reload(module)
# iterate over all objects and update them
count = 0
# XXX We should optimize here:
# It may be that no references to the objects are present
# except those from our _old_objects dictionary.
# We should remove those. I have to learn about weak-refs!
for name, new_obj in module.__dict__.items():
key = (module.__name__, name)
if _old_objects.has_key(key):
for old_obj in _old_objects[key]:
## if sys.getrefcount(old_obj) == 3:
## _old_objects[key].remove(old_obj)
## continue
if type(new_obj) == types.ClassType:
old_obj.__dict__ = new_obj.__dict__.copy()
count += 1
print sys.getrefcount(old_obj), name
elif type(new_obj) == types.FunctionType:
old_obj.func_code = new_obj.func_code
count += 1
print sys.getrefcount(old_obj), name
stop = time.clock()
print "# updated %d objects from %s" % (count, module)
print "# This took %.3f seconds" % (stop - start)
print
return module
_watcher = ModuleWatcher()
run = _watcher.run
stop = _watcher.stop
---- EOF ----
James_...@i2.com
Prabhu Ramachandran wrote:
>Andrew Dalke wrote:
>> but I've never really needed it. Better I think would be if
>
I wrote such a tool for Jython. It is used quite extensively at our
company and is well-liked. :-)
Jim
Tim Hammerquist
[ snip ]
>> Limitations on the product distributed is nothing new. OTOH, Microsoft
>> has just attempted to make it _ILLEGAL_ to use a python binary I've
>> compiled myself (though ActivePython is probably alright). _This_ is
>> what a _huge_ number of people are upset about.
>> Rebuttals?
>>
> Since the Python license is as liberal as it is, there is no reason why a
> Python binary has to be GPL, just because (say) you compiled it with gcc.
> But that apart, your description of the terms and conditions of Microsoft's
> EULA seems fair, and less biased than, say, my own sclerotic reactions.
I was referring more to, say, a copy of Python 1.6.1 I might have laying
around whose license is _explicitly_ GPL-compatible, making the above
license even more averse to it than Python's current release. Also, the
license does not limit 'Publicly Available Software' to GPL; it
includes, as stated previously, software that
#v+
contains, or is derived in any manner (in whole or in part) from
any software that is distributed as free software, open source
software ... or _similiar_licensing_or_distribution_model_.
#v-
I cannot (under this license):
- _use_ any OS software to develop the project. This includes:
* editing any MIT file in Vim
* search/modify/operate on any MIT files using tar, gzip,
perl, etc.
* telnet into a Win32 box from a linux box to view and/or
edit any MIT files.
- distribute anything created using MS MIT under and GPL "or similar
licensing or distribution model." (of course)
- I cannot include anything under the aforementioned licenses in the
same package as anything developed using MS MIT. M$ has required
that it be a separate product, thereby dictating what my package
contents may/may not include.
And AFAIK, a program compiled by gcc (GPL) is _not_ required to be
GPL itself. So you are correct in this. Microsoft may still whine
that you are _using_ a GPL'd product with their system, whether or
not that product affects your end-product's license.
Tim Hammerquist
--
"Supported" is an MS term that means the function exists. The fact
that it always fails means that it is an exercise for the programmer.
-- Sarathy, p5p
Paul Prescod
>
>...
>
>
> def MyClass_newMethod(self):
> print "new method"
> MyClass.newMethod = MyClass_newMethod
>
> I smiled just now when I realized that the Python version is actually
> fewer lines of code. :) But I still don't think it feels right. In
> Smalltalk and Ruby, I'm just using the standard mechanism for adding
> methods to a class. In Python, it feels like I'm sneakily hacking an
> extra method into a class against its will. (Does that make any sense?
> Maybe I'm being too touchy-feely. :)
You are doing something sneaky in *any* language because if anyone else
defines newMethod in any other module anywhere in the system you'll
overwrite each other. Classes are more or less global variables and so
are their methods.
Python would probably not have first-class syntax to do this until there
were a way to do it that scaled well to large programs written by people
who do not necessarily communicate with each other.
Paul Prescod
Tim Hammerquist
>> Also, it might have been an unconscious attempt to bring some
>> of the less argumentative Smalltalkers out of hiding.
>
> OK, I'm out of hiding. :) Anything in particular you'd like to
> discuss?
Yes. Exactly what you here. ;)
> I *do* think that Smalltalk's got some advantages over Python, but I
> don't think they're in the area of OOness. In terms of OO, Python has
> everything I want.
My fave part of ST is how it handles the whole object _concept_. As you
state, this make small scripts/programs unnecessarily complex/large, but
for anything sufficiently large it's amazing!
> I'm kinda annoyed about Python's silly type/class distinction. But
> then, so are you, and I'm glad to see the efforts at unification
> progressing.
Agreed.
> I'm also kinda annoyed that Python introduced generators, list
> comprehensions, and crippled lambdas to deal with an issue that
> Smalltalk solves very neatly with its blocks.
Having come from Perl (and, BTW, still using/liking it), I found
list-comprehensions a welcome addition. Oops! I shouldn't have said
that. There may be a PEP to remove them since they resemble a Perl
feature!
[ snip ]
> Oh, and I've been meaning to ask - is there a way for me to add
> methods to Dict or List or String? I couldn't figure out how to do it,
> and that's where I *really* want it.
Dicts, lists, and strings are all "types", the downfalls of which you
mentioned earlier. OTOH, someone must've had the some wish, because the
latest Python distro comes with the standard modules UserDict, UserList,
and UserString which provide inheritable classes (though slightly less
efficient) to do with whatever you wish. Add a method, or simply
subclass. (As the interface of the above types is fairly standard,
adding new methods would technically be a different object exhibiting
different behavior, deserving of its own class, right?)
I don't currently know of a way to make a custom(ized) String/List/Dict
class the default for the ''/[]/{} constructor, though.
> But maybe it's useful to hear the perspective of an almost-reasonable
> person from outside the community.
It has been for me. Thx.
Tim Hammerquist
--
Anyone who thinks that the act of programming is worth
less than $50/hr should leave the industry.
-- Randal L. Schwartz (clpm, 27 Jul 2000)
Tim Hammerquist
> Tim Hammerquist <t...@vegeta.ath.cx> wrote
>
>> If you really need to raise a discussion, the posters
>> comp.lang.smalltalk...
>
> Okay, I'm off to the smalltalk group to declare that "Python is more OO than
> Smalltalk!" Who will ensure that I get a decent burial?
They may be too deeply involved debating RDBMS vs OODBMS to even see
your post. ;)
>> $ cat debate
>> #!/usr/local/bin/python
>>
>> assert time is infinite
>> steve = Zealot(SmallTalk)
>> matt = Advocate(Python)
>>
>> while isinstance(steve, Zealot):
>> try:
>> matt.argue()
>> if isconvinced(steve):
>> break
>> pigs.fly()
>> steve.say("I'm not convinced.")
>> except:
>> steve.say("Hah! You can't prove it!")
>>
>> $ chmod 700 debate
>> $ debate and echo "They all lived happily ever after."
This last should have been:
$ debate && echo "They all lived happily ever after."
Thus, && tests the exit value of debate, debate can never return true,
(since at no point is steve .convinced), and no one ever lives happily
ever after. Cynical yet apropos.
> Cute, I like it! (although I don't claim to be a Python Advocate -- I
> advocate using the best tool for the job, which means the more tools you know
> how to use, the better your odds are).
Touché. This means I won't be garroted for mentioning Perl elsewhere in
this thread? ;)
Tim Hammerquist
--
No violence, gentlemen -- no violence, I beg of you! Consider the furniture!
-- Sherlock Holmes
Rainer Deyke
news:359f85cd.01111...@posting.google.com...
> runtime what function definition is going to be invoked.
If by "runtime" you mean at the actual time the function is called, you're
wrong.
def f(x):
g = x.g
print "I'm going to call %s." % g
g()
Matt Gerrans
> ...
> Touché. This means I won't be garroted for mentioning Perl elsewhere in
> this thread? ;)
Don't push your luck! ;-/
- mfg
Roy Smith
> If you look under the hood, Python is much more like Smalltalk than
> Java.
I'm having trouble parsing that. Which of the following did you mean?
1) Python is more like Smalltalk that Python is like Java
2) Python is more like Smalltalk than Java is like Smalltalk
Tim Hammerquist
I grokked it as meaning case 2.
That's what we get for using English. Now if we used Latin, we wouldn't
have to rely on the relative location of words in a sentence to
determine meaning... ;)
On that note:
http://search.cpan.org/doc/DCONWAY/Lingua-Romana-Perligata-0.50/README
Sorry 'bout the OT, but it seems Mr. Conway is both quite adept and very
much a masochistic hacker.
Tim Hammerquist
--
I'll keep him as an insurance policy, since,
unfortunately, I can't kill him twice.
-- Scaroth
Michael Hudson
I think 1).
Cheers,
M.
--
39. Re graphics: A picture is worth 10K words - but only those
to describe the picture. Hardly any sets of 10K words can be
adequately described with pictures.
-- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html
Tim Randolph
> I'd be interested to see the current state of Python development
> environments. That's where Smalltalk really shines, and I've never
> seen an environment for any other language even come close. That's
> understandable, because Smalltalk's whole, um, paradigm is optimized
> for that kind of thing. Holding everything inside a monolithic image
> makes it really easy to create spectacular tools (but, of course, also
> costs Smalltalk a lot, like the ability to use Smalltalk for small
> scripts). In particular, I'd like to see the Python Refactoring
> Browser efforts bear fruit.
This is robably a good time to point out the new meta-IDE put out by
IBM as open source at eclipse.org. It was developed by the smarties
at UTI who built the original VA for Smalltalk.
Not only is it open source, but its got a very open plug-in
architecture, that to my mind is yearning for Python editors,
debuggers, Class Browsers, Zope builders, etc. Using the eclipse
framework and tools, I don't think it would be *that* hard to get to a
VA for Python experience.
Check it out. It's one of the coolest things that has come down the
road for quite some time.
--Tim
Blake Winton
>Adam Spitz wrote:
>> In Python, it feels like I'm sneakily hacking an
>> extra method into a class against its will.
>defines newMethod in any other module anywhere in the system you'll
>overwrite each other. Classes are more or less global variables and so
>are their methods.
I wonder if this has to be the case. Perhaps a Class could be made
module-specific, so that any changes to the Class would only occur in
the module they were changed in. (As an implementation, I'm thinking
of something like the "__spam" changing to "_classname__spam"... So
if something in module "eggs" adds the method "bacon" to the class
"spam", it would actually go in as "_eggs__bacon", with the
interpreter checking for the module version of the function first, and
if it didn't find it, checking for the base version. This could also
generalize to nested modules as "_eggs_ham__bacon" for the "eggs.ham"
module, with the interpreter checking for the method in the order
"_eggs_ham__bacon" followed by "_eggs__bacon" followed by "bacon".)
>Python would probably not have first-class syntax to do this until there
>were a way to do it that scaled well to large programs written by people
>who do not necessarily communicate with each other.
Something like throwing a "Method Already Defined" exception if you
step on someone else's toes? Or more like the module syntax I
described above? Or something else entirely?
Caveat: I've never found a need to define a method on an object I
didn't own, so all of this is mere speculation. For that matter, I
really haven't taken much advantage of Python's dynamic nature at all.
Later,
Blake.
--
9:40pm up 52 days, 21:07, 2 users, load average: 0.02, 0.09, 0.07
Modman
> Roy Smith <r...@panix.com> graced us by uttering:
> > ia...@colorstudy.com (Ian Bicking) wrote:
> >> If you look under the hood, Python is much more like Smalltalk than
> >> Java.
> >
> > I'm having trouble parsing that. Which of the following did you mean?
> >
> > 1) Python is more like Smalltalk that Python is like Java
> > 2) Python is more like Smalltalk than Java is like Smalltalk
>
> I grokked it as meaning case 2.
>
> That's what we get for using English. Now if we used Latin, we wouldn't
> have to rely on the relative location of words in a sentence to
> determine meaning... ;)
why is that bad? Python uses position to determine meaning (i.e.
Spaces are significant) :-)
just thought I could try to tie this back into the main topic :-)
Modman
> Roy Smith <r...@panix.com> writes:
>
> > ia...@colorstudy.com (Ian Bicking) wrote:
> > > If you look under the hood, Python is much more like Smalltalk than
> > > Java.
> >
> > I'm having trouble parsing that. Which of the following did you mean?
> >
> > 1) Python is more like Smalltalk that Python is like Java
> > 2) Python is more like Smalltalk than Java is like Smalltalk
>
> I think 1).
>
> Cheers,
> M.
both mean the same thing. Python is closer to smalltalk than Java is
so the ST guru buddie was a bit off base to be compairing Py to J.
Michael Hudson
> Michael Hudson <m...@python.net> wrote in message news:<uzo5pm...@python.net>...
> > Roy Smith <r...@panix.com> writes:
> >
> > > ia...@colorstudy.com (Ian Bicking) wrote:
> > > > If you look under the hood, Python is much more like Smalltalk than
> > > > Java.
> > >
> > > I'm having trouble parsing that. Which of the following did you mean?
> > >
> > > 1) Python is more like Smalltalk that Python is like Java
> > > 2) Python is more like Smalltalk than Java is like Smalltalk
> >
> > I think 1).
> >
> > Cheers,
> > M.
>
> both mean the same thing.
No they don't.
1) means
Smalltalk Python Java
^ ^
little gap big gap
2) means
Python Smalltalk Java
^ ^
little gap big gap
both are true, but they're not the same.
> Python is closer to smalltalk than Java is so the ST guru buddie was
> a bit off base to be compairing Py to J.
Quite, i.e. 1) above.
Cheers,
M.
--
Counting lines is probably a good idea if you want to print it out
and are short on paper, but I fail to see the purpose otherwise.
-- Erik Naggum, comp.lang.lisp
Erik Max Francis
...
> > > Roy Smith <r...@panix.com> writes:
> > >
> > > > 1) Python is more like Smalltalk that Python is like Java
> > > > 2) Python is more like Smalltalk than Java is like Smalltalk
...
> No they don't.
>
> 1) means
>
> Smalltalk Python Java
> ^ ^
> little gap big gap
>
> 2) means
>
> Python Smalltalk Java
> ^ ^
> little gap big gap
>
> both are true, but they're not the same.
I'm not sure what you intend to signify by the placement of the names on
the line. Surely "X is like Y to degree Z" is symmetric with respect to
X and Y. If X is very much like Y, then Y is very much like X; if X is
very different from Y, then Y is very different from X too. In which
case the swapping of Smalltalk and Python on the above diagrams doesn't
mean anything and the two statements are in fact equivalent.
Unless you want to suggest that X can be very much like Y, but Y can be
very different from X, which doesn't make much sense.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/ \ Laws are silent in time of war.
\__/ Cicero
Esperanto reference / http://www.alcyone.com/max/lang/esperanto/
An Esperanto reference for English speakers.
Adam Spitz
> Adam Spitz wrote:
> >
> > def MyClass_newMethod(self):
> > print "new method"
> > MyClass.newMethod = MyClass_newMethod
> >
> > I smiled just now when I realized that the Python version is actually
> > fewer lines of code. :) But I still don't think it feels right. In
> > Smalltalk and Ruby, I'm just using the standard mechanism for adding
> > methods to a class. In Python, it feels like I'm sneakily hacking an
> > extra method into a class against its will. (Does that make any sense?
> > Maybe I'm being too touchy-feely. :)
>
> You are doing something sneaky in *any* language because if anyone else
> defines newMethod in any other module anywhere in the system you'll
> overwrite each other.
Um... sort of. It's really not as sneaky as you think. It's part of
the culture. We *expect* people to do things like that. We encourage
it. You're right, though, that the potential consequences are just as
bad in Ruby or Smalltalk. We just think that the advantages are worth
it, that's all.
Sometimes I'll be programming and I'll have a need for a certain
method on the Array class, but it's not there. Or I'll write a
string-manipulation method as part of another class, but then decide
that it really ought to live in the String class. In most other
languages, I feel a little twinge of annoyance. In Ruby or Smalltalk,
I just go add the method.
The biggest advantage by far, though, is that it encourages evolution.
When you've got lots and lots of programmers out there thinking up new
library methods and adding them and playing with them and tweaking
them, the best ones are going to get proposed as additions to the
standard library, and the standard library is going to get really
good. (Ever hear a Smalltalker brag about how the Smalltalk class
library is so amazing? Guess how it got that way.)
Anyway, because this *is* a cultural issue, adding this feature isn't
necessarily a good idea for Python. Your priorities are different, and
I wouldn't be surprised if you decided that the risks are too high.
(Maybe someone here could come up with a clever Python-ish way to get
the same effect with less risk.) But this is the sort of thing that
prevents me from embracing Python whole-heartedly.
Adam Spitz
Adam Spitz
> I've never liked that idea though (which Smalltalk and Ruby both
> have). I think adding methods to an existing class is like
> playing around with global variables. What's to keep two different
> libraries from adding a method with the same name but which
> does different things?
Faith? :)
Seriously? It's almost never a problem. (Python people ought to be
familiar with this argument - it's the same one we all use when
incredulous C++/Java programmers ask us how we can possibly live
without a static type checker. ;)
Adam Spitz
Daniel Klein
[snip]
>When I first started Python, I wrote a class like:
>
>class Spam:
> def __init__(self, x):
> self.x = x
> def show(self):
> print self.x
>
>After I figured out it worked, I wanted to add a new method, so
>I did
>
>class Spam:
> def double(self):
> self.x = self.x * 2
>
>then was annoyed that it didn't work the way I expected. So I
>don't think you are alone in this view. I bring it up here because
>I suspect for many people this is forgotten amoung all the other
>confusions in the early stages of learning Python.
Just curious to know how it is that you expected this to work and why you were 'annoyed'? I can't
see what the problem is with the double() method.
>>> class Spam:
def __init__(self,x):
self.x = x
def show(self):
print self.x
def double(self):
self.x = self.x * 2
>>> s = Spam(1)
>>> t = Spam('foo')
>>> s.double()
>>> t.double()
>>> s.x
2
>>> t.x
'foofoo'
>>> s.show()
2
>>> t.show()
foofoo
Daniel Klein
Matt Gerrans
> to describe the picture. Hardly any sets of 10K words can be
> adequately described with pictures.
> -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html
Hey, when did a picture's word-value get upgraded by an order of magnitude?
(or was he referring to the Chinese version of that cliché?)
- mfg
Matt Gerrans
probably struggle to visualize the several hundred (or so) -dimensional graph
to accurately describe the differences between the three...
- mfg
Andrew Dalke
>>I wanted to add a new method, so I did
>>
>>class Spam:
>> def double(self):
>> self.x = self.x * 2
Daniel Klein:
>Just curious to know how it is that you expected this to work
Because I didn't think that 'class Spam' always created a new
class. I thought it would reuse a definition of one already exists.
I believe this is similar to what Smalltalk does.
> why you were 'annoyed'?
Because it didn't fit my model of how the language worked, so
was more effort to learn.
>I can't
>see what the problem is with the double() method.
The problem was I wanted to add a method to an existing class.
The method definition was fine.
Andrew
da...@dalkescientific.com
Steve Holden
def Spam.double(self):
self.x *= 2
to add or redefine methods, but I don't remember why this was thought to be
a bad idea. I suppose in all such cases it's bad that there's no way to
reach out to existing instances and modify them. SmallTalk's introspection
system has it over Python in that respect, but then (like me :) it's more
mature.
memory's-not-what-it-was-ly y'rs - steve
--
http://www.holdenweb.com/
Tim Hammerquist
[ snipped pieces of a Python thread that became a Smalltalk
thread, that then degenerated into a Perl/Latin thread ]
> just thought I could try to tie this back into the main topic :-)
Why bother? I'm only assuming from the Newsgroups: header that this
thread was originally about Python. ;)
Oh wait, now I remember. There was a pterodactyl flying outside my
window and someone posted regarding a cow orker who denounced Python's
OO-ness...
<there's-no-place-like-home-cuz
-we-passed-Kansas-'bout-six-subthreads-back>ly 'yrs,
Tim Hammerquist
--
Usenet is essentially a HUGE group of
people passing notes in class.
-- R. Kadel
Ken Seehof
If the syntax you describe were implemented, it would presumable modify the
class directly, and therefore would affect all existing instances (the
instances
all refer to the same class object, so there is no reason to need to reach
out
to the existing instances). There isn't any semantic reason against it, in
fact
here's a recipe describing how to add or replace a method in an existing
class
using the 'new' module:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/81982
So python seems to be just as flexible as smalltalk is this respect, but you
have to get under the hood a bit more.
I've used this trick on a few occaisions; usually for debugging, but also to
work around design problems in existing python packages.
- Ken
Mikael Olofsson
I thought we were talking about distances here. It should be enough with
a two-dimensional subspace of that multi-dimensional space, namely the
plane on which the three points (languages) are. Everything else is
orthogonal to that plane...
Now back to business!
/Mikael
-----------------------------------------------------------------------
E-Mail: Mikael Olofsson <mik...@isy.liu.se>
WWW: http://www.dtr.isy.liu.se/dtr/staff/mikael
Phone: +46 - (0)13 - 28 1343
Telefax: +46 - (0)13 - 28 1339
Date: 15-Nov-2001
Time: 08:28:38
/"\
\ / ASCII Ribbon Campaign
X Against HTML Mail
/ \
This message was sent by XF-Mail.
-----------------------------------------------------------------------
Linköpings kammarkör: www.kammarkoren.com
Matt Gerrans
> ...and someone posted regarding a cow orker who denounced Python's...
Now let's not stoop to name-calling. He may be a SmallTalk bigot, but we
have no proof that he ever orked a cow...
- mfg
Laura Creighton
The Design Patterns Smalltalk Companion (p 214) discussing Proxy states:
'Since the problem lies in Proxy's subclass relation to
object, one way to solve it would be to dissolve this
relationship. How is this possible? Subclass Proxy off nil'
Do people actually do this. Pardon this phrasing, but isn't it, ah,
'evil'? I'm way to scared to use it, though of course I had to write
one just to see it.
Laura Creighton
Thomas Heller
wrong group, I'd say ;-)
I remember having played with this (with great fun), but I didn't
use it in production code.
Firing up VSW311, I find (in the class browser which probably does not
display all classes) these classes as subclasses of nil other than Object:
SelfInitializingObject
SelfInitializingObjectReference
Smells like the proxy pattern...
Thomas
Adam Spitz
Honestly? I have no idea. I've never done it myself. But then, that
doesn't mean much.
If it scares you, open up a workspace and play with the objects for a
while. Get your hands on them. Get comfortable with them. (You can do
this in Python, too, in interactive mode.) And write a bunch of unit
tests, while you're at it.
It still seems to me like it's pretty deep in the bag of tricks, but I
wouldn't be afraid to use it when I needed to.
Adam Spitz
gbr...@cix.compulink.co.uk
> ... in fact
> here's a recipe describing how to add or replace a method in an existing
> class
> using the 'new' module:
>
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/81982
AIUI, that involves a circular reference. If anybody wants to try some
benchmarking, compare it with the following:
dynamicModule = "__dynamic__"
def setDynamicClass(object):
if object.__class__.__module__ != dynamicModule:
class klass(object.__class__):
"""dynamic class for hacking"""
klass.__name__ = object.__class__.__name__
klass.__module__ = dynamicModule
object.__class__ = klass
def addMethod(object, function):
setDynamicClass(object)
setattr(object.__class__, function.__name__, function)
Graham
Martijn Faassen
Excellent work folks -- we're adding centuries to the lifetime of the
universe this way.
The PSU thanks you.
:)
Regards,
Martijn
Tim Hammerquist
> [free software, open source, licenses, microsoft, oh my, oh my]
>
> Excellent work folks -- we're adding centuries to the lifetime of the
> universe this way.
>
> The PSU thanks you.
Would it help if I called Microsoft a bunch of fascists?
Or would I actually have to call them nazis to end the thread?
<g>
Tim Hammerquist
--
A yacc is an unruly beast.
-- Larry Wall in <1999120120...@kiev.wall.org>
Tim Hammerquist
There you go, assuming orking cows is bad! Have you proof? Or even
personal experience? ;)
Now bigotry... _that_ I have experience with, and let me tell you...it
can really be fun!
Tim Hammerquist
--
If Microsoft built cars, the oil, gas, and alternator warning lights would
be replaced by a single "general car fault" warning light.
Tim Hammerquist
>> [free software, open source, licenses, microsoft, oh my, oh my]
>>
>> Excellent work folks -- we're adding centuries to the lifetime of the
>> universe this way.
>>
>> The PSU thanks you.
>
> Would it help if I called Microsoft a bunch of fascists?
>
> Or would I actually have to call them nazis to end the thread?
>
> <g>
Damn! I went and jinxed it! <g>
Tim Hammerquist
--
Nothing so needs reforming as other people's habits.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"
Blake Winton
It's a bit of a pain, but...
Python 2.2a3 (#1, Sep 16 2001, 12:18:17)
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class Spam:
... def __init__( self ):
... self.x = 3
...
>>> spam1 = Spam()
>>> dir( spam1 )
['__doc__', '__init__', '__module__', 'x']
>>> dir( Spam )
['__doc__', '__init__', '__module__']
>>> def newMeth( self ):
... self.x = self.x + 1
...
>>> Spam.__dict__["eggs"] = newMeth
>>> dir( Spam )
['__doc__', '__init__', '__module__', 'eggs']
>>> dir ( spam1 )
['__doc__', '__init__', '__module__', 'eggs', 'x']
>>> spam1.eggs
<bound method Spam.newMeth of <__main__.Spam instance at 0x8139094>>
>>> spam1.eggs()
>>> spam1.x
4
>>>
So, it seems to me that all you really want is syntactic sugar for
that... I guess since it's not really in Python's community
standards to add methods to classes (aside from the Twisted folk),
it's not horrible that it's a little tricky...