I'm a python addict !
Linuxguy123
I hate Perl. I never did learn to use it with any competence. I has to
be the most obfuscated, cryptic language I've ever seen. Making it
"object oriented" only makes it worse !
While I am at it, I dislike bash shell programming too.
Man, I love Python ! Its so clean and easy to use. Its so complete.
It links into everything one way or another... Java, C, C++, Qt, KDE,
SWT, Swing and probably more things that I don't know about. Python
makes sense. Python is readable.
I will never write another Perl or Bash script again. I will never use
another low level language to do simple things again.
I love how Python has object member lists in PyDev in Eclipe. It makes
it easy to use and explore the language and objects.
I wrote a simple command line serial emulator in about 10 minutes using
the PySerial library. Unbelievable.
I see a lot of Python in my future.
Paul McGuire
> I just started using python last week and I'm addicted.
> I see a lot of Python in my future.
Bravo, welcome, and well-said!
Your sentiments mirror and resonate with those of many on this list.
About 6 years ago I wanted a scripting language to work with,
*anything* but more Tcl/Tk! Python the language had many features and
language design decisions that just "felt right," and the natural feel
of the object model allowed me to leverage much of the OO theory I had
learned using Java and C++.
And THEN, it began to dawn on me that a lot of that theory is actually
crutch, bailing-wire, and gum, put there to work around the static
typing rigidity of C++, Java and their ilk. As much as I loved Scott
Meyers' "Effective C++" books, many of their idioms and tricks just
fall away as unnecessary in Python. Interfaces? Python don't need no
steenking interfaces! The interface concept is still useful for
organizing your thinking and OO design, but the implementation is far
freer, as you find that an object's conformance to an interface is
only determined/required at runtime, not at some long-distant compile
step in a library nested N levels deep in your hierarchy.
Python exposes many of its dynamic hooks through magic __xxx__
methods. Need to write a proxy wrapper around an object of type X to
supercede method Y, but you don't want to write all thouse tedious
passthru methods for the X class's methods A thru R? Just implement
your special method Y, and let a __getattr__ method pass all the other
calls on to the underlying object. Instant Proxy!
Want to change the type/behavior of an object from class A to class
B? How about this:
aobj = A()
aobj.__class__ = B
Try *that* in as simple-looking C++ or Java!
Python's learning curve can be gentle or steep, depending on your own
inclination. My advice? Push yourself up as quickly as you can.
Quickly put aside this kind of code:
for i in range(len(datalist)):
# do something with datalist[i]
and start thinking in iterators:
for item in datalist:
# do something with item
Need to read through a text file?
for line in file("xyzzy.dat"):
# do something with each line
Master the clean look and feel of a list comprehension or generator
expression, over explicit for loops. Need to build a list of the odd
numbers up to 100? Instead of this:
oddnums = []
for n in range(100):
if n % 2:
oddnums.append(n)
learn to do this:
oddnums = [ n for n in range(100) if n % 2 ]
Learn the native data structures - tuple, list, dict, set. Learn the
dict idiom that serves as Pythons version of a switch statement.
Check out the itertools module, a cunning mix of elegance and
wizardry. The standard lib is a trove of well-oiled and production-
tested code, but the community is not shy about producing additional
modules, many with liberal licensing - image processing, text
processing/parsing, discrete-event simulation, optimization, genetic
algorithms, web/network apps and IPC, ... Google and ye shall find.
Write a generator method to yield a sequence of useful values (odd
numbers, primes, consonants, fibonacci's, whatever). You can
certainly write a lot of Python without ever using these intermediate/
advanced features, but one day you'll give it a shot and think "Dang!
what was the big deal? I wish I'd tried this sooner!"
Yet having said that, in 6 years I've not yet tried to write a C
extension for Python. But I'm told that this too is a well-blazed
trail if you feel the need.
Dig in! And post back here if you get stuck. Be confident that Python
has been employed in a wide range of applications and application
domains, and that if a particular feature seems to be missing, it may
be because Python takes a slightly different angle on the problem.
Ah, those heady days of youth, when the world was fresh, and the
idioms of Python were still new and ripe to discover!
I envy you, Linuxguy123, I envy you...
Enjoy!
-- Paul
Aahz
Welcome! Just be aware that excessive Perl-bashing is considered
somewhat tasteless on this newsgroup, but the occasional snide comment
should be fine. ;-)
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
Weinberg's Second Law: If builders built buildings the way programmers wrote
programs, then the first woodpecker that came along would destroy civilization.
Russ P.
> I will never write another Perl or Bash script again.
I still use bash for orchestrating the execution of a series of other
scripts and/or programs (including python programs). I know you can do
that in python, but I find bash simpler to use for that purpose. Then
again, that may be just because I learned bash before I learned python.
Lie Ryan
> I just started using python last week and I'm addicted.
you need to try this:
import antigravity
Terry Reedy
> (3 comics = 1 week). And still going "Woo Python". You can see him
> floating near the peak of Mt. Everest.
>
> http://xkcd.com/482/
For a Python 'program', see http://xkcd.com/534/
MRAB
Robert Kern
> In article<mailman.7865.1232765...@python.org>,
> Linuxguy123<linux...@gmail.com> wrote:
>> I just started using python last week and I'm addicted.
>
> Welcome! Just be aware that excessive Perl-bashing is considered
> somewhat tasteless on this newsgroup, but the occasional snide comment
> should be fine. ;-)
Or bash-bashing for that matter. :-)
but-zsh-really-is-better'ly yrs,
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
Russ P.
> > Linuxguy123<linuxguy...@gmail.com> wrote:
> >> I just started using python last week and I'm addicted.
>
> > Welcome! Just be aware that excessive Perl-bashing is considered
> > somewhat tasteless on this newsgroup, but the occasional snide comment
> > should be fine. ;-)
>
> Or bash-bashing for that matter. :-)
>
> but-zsh-really-is-better'ly yrs,
>
> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless enigma
> that is made terrible by our own mad attempt to interpret it as though it had
> an underlying truth."
> -- Umberto Eco
Come to think of it, when I use bash to run a series of python
scripts, I could call it "bashing Python."
Andreas Waldenburger
wrote:
> Terry Reedy wrote:
> > For a Python 'program', see http://xkcd.com/534/
> >
> It doesn't follow PEP 8!
So Randall can just forget about getting xkcd in the Standard Library.
Let this be an example to all of you!
/W
--
My real email address is constructed by swapping the domain with the
recipient (local part).
J Kenneth King
> I just started using python last week and I'm addicted.
>
> I hate Perl. I never did learn to use it with any competence. I has to
> be the most obfuscated, cryptic language I've ever seen. Making it
> "object oriented" only makes it worse !
> .. <snip> ..
I program full-time in Python, so I share your excitement and
enthusiasm. But bashing Perl like that doesn't make you sound very
smart. I'm probably one of the very few Python programmers who came from
(and still occassionally) use Perl. I've written non-trivial programs in
it and from my experience I can tell you that it's actually a great
language. The Moose object system is well beyond Python's class
system. But I guess you wouldn't know that.
So yay for Python, but don't get in the habit of criticising that which
you do not know.
J Kenneth King
I just realized this might become flame-bait. Please disregard the
flamey bits. :(
J. Cliff Dyer
On Mon, 2009-01-26 at 14:43 -0800, J Kenneth King wrote:
> Linuxguy123 <linux...@gmail.com> writes:
>
> > I just started using python last week and I'm addicted.
> >
> > I hate Perl. I never did learn to use it with any competence. I has to
> > be the most obfuscated, cryptic language I've ever seen. Making it
> > "object oriented" only makes it worse !
> > .. <snip> ..
>
> I program full-time in Python, so I share your excitement and
> enthusiasm. But bashing Perl like that doesn't make you sound very
> smart. I'm probably one of the very few Python programmers who came from
> (and still occassionally) use Perl.
Really?
I think many many python programmers cut their teeth on Perl. I for
one. I loved programming in it when I did, but I hate having to try to
understand OPP. Now, when I deal with Perl, it's mostly legacy code,
and it's a miserable experience.
> I've written non-trivial programs in
> it and from my experience I can tell you that it's actually a great
> language. The Moose object system is well beyond Python's class
> system. But I guess you wouldn't know that.
>
> So yay for Python, but don't get in the habit of criticising that which
> you do not know.
There are legitimate reasons to criticize things even when they are
powerful.
Cheers,
Cliff
J. Cliff Dyer
On Fri, 2009-01-23 at 20:25 -0800, Paul McGuire wrote:
> Want to change the type/behavior of an object from class A to class
> B? How about this:
>
> aobj = A()
> aobj.__class__ = B
>
> Try *that* in as simple-looking C++ or Java!
Wow. That looks very powerful and fun. But scary. Any thoughts on how
you would use that in a way that wouldn't unleash sulphurous code
smells?
Cheers,
Cliff
Paul McGuire
This technique is perfect for implementing the GoF State pattern.
In the State pattern, you implement behavior for an object's various
states using one of several interchangeable classes. The classes are
"interchangeable" in that they all implement a common interface. Here
is my favorite State pattern example, a traffic light:
import time
class TrafficLight(object):
pass
class RedLight(TrafficLight):
cars_can_go = False
pedestrians_can_cross = True
color = (255,0,0)
duration = 20
class YellowLight(TrafficLight):
cars_can_go = True
pedestrians_can_cross = False
color = (255,255,0)
duration = 5
class GreenLight(TrafficLight):
cars_can_go = True
pedestrians_can_cross = False
color = (0,255,0)
duration = 15
# now add in next_state class vars for state transitions
RedLight.next_state = GreenLight
YellowLight.next_state = RedLight
GreenLight.next_state = YellowLight
TrafficLight.initial_state = RedLight
# run a traffic light for a while...
can_they = lambda cond : ("can't","can")[cond]
light = TrafficLight.initial_state()
while 1:
print light.__class__.__name__
print "waiting for", light.duration, "seconds"
print "Cars", can_they(light.cars_can_go), "go"
print "People", can_they(light.pedestrians_can_cross), "cross"
print
time.sleep(light.duration)
# how you have to do it in C++ and Java
# light = light.next_state()
# using Python
light.__class__ = light.next_state
Gives this output:
RedLight
waiting for 20 seconds
Cars can't go
People can cross
GreenLight
waiting for 15 seconds
Cars can go
People can't cross
YellowLight
waiting for 5 seconds
Cars can't go
People can't cross
RedLight
waiting for 20 seconds
Cars can't go
People can cross
... and so on ...
In Python, the base TrafficLight class isn't even necessary ("don't
need no stinking interfaces!"), although it is a good place to define
default behavior, and it helps tie together the other classes from a
self-documentation standpoint. But any class that has the necessary
attributes would suffice, whether it inherits from TrafficLight or
not.
class HoldForEmergencyVehiclesLight(object):
cars_can_go = False
pedestrians_can_cross = False
color = (255,0,0)
-- Paul
Scott David Daniels
> On Fri, 2009-01-23 at 20:25 -0800, Paul McGuire wrote:
>> aobj = A()
>> aobj.__class__ = B
> on how you would use that in a way that wouldn't unleash sulphurous
> code smells?
Seems like a nice way to transition between "ActiveAccount": and
"InActiveAccount" or some such. The requirement is that the two
classes share memory layout (essentially, class type and all __slots__
involved (including __dict__). It is a bit prickly, so I'd personally
only start to use it once my methods were littered with lots of:
...
if self.active_flag:
self.account.update(...
else:
raise ValueError('Purchase prohibitted')
Could also be useful as the stub for a kept-on-disk structure,
where all methods on the inactive one rolled in data switched class,
and invoked their corresponding method.
--Scott David Daniels
Scott....@Acm.Org
J. Cliff Dyer
Thanks. That makes sense. But your example creates a new instance of
the new class each time, rather than changing the class of a persistent
instance, as the original example, to which I was responding, did.
But perhaps something like:
class TrafficLight(object):
def change_light(self):
self.__class__ = next_state
and then you can persist information about the light (bulb_type in
set(['led', 'incandescent']), last_maintenance_date, location, etc.) on
the instance level, unaffected by the changing color.
Interesting stuff.
Cheers,
Cliff
Paul McGuire
>
> Thanks. That makes sense. But your example creates a new instance of
> the new class each time, rather than changing the class of a persistent
> instance, as the original example, to which I was responding, did.
>
Look closer. The line that creates a new instance is commented out,
with the notation "how you have to do it in C++ and Java". The actual
Python code is just below, and just assigns a new class to
self.__class__, as in the original example.
-- Paul
J. Cliff Dyer
Bruno Desthuilliers
> On Jan 26, 10:54 am, "J. Cliff Dyer" <j...@sdf.lonestar.org> wrote:
>> On Fri, 2009-01-23 at 20:25 -0800, Paul McGuire wrote:
>>> Want to change the type/behavior of an object from class A to class
>>> B? How about this:
>>> aobj = A()
>>> aobj.__class__ = B
>>> Try *that* in as simple-looking C++ or Java!
>> Wow. That looks very powerful and fun. But scary. Any thoughts on how
>> you would use that in a way that wouldn't unleash sulphurous code
>> smells?
>>
>
> This technique is perfect for implementing the GoF State pattern.
Except when it is not !-)
I tried twice to use this trick in "real life" code, and in both cases,
it ended up being much more complicated than implementing the state
pattern the canonical way. Not to say that it's hopeless - just that
there's the usual difference between theory and practice.
afr...@yahoo.co.uk
[snip]
>
> # how you have to do it in C++ and Java
> # light = light.next_state()
>
> # using Python
> light.__class__ = light.next_state
I'm sure you can, but why poke yourself in the eye with a blunt
stick? ;)
IMO there are two obvious problems with the latter approach. Firstly
the information about the next state is left lying about in some
namespace separate from the object, whereas the object itself ought to
know what it's 'next_state' is (or, more correctly, how to determine
it).
Secondly you miss the opportunity of sending a signal to the new
state. Consider that in some jurisdictions the amber light shows
before the green as well as before the red (yeah, I know is that an
invitation for drag racing or what!?). If you called next_state as a
verb you could pass the current state as an argument and the amber (or
yellow, if you prefer) light could work which of the two possible next
states to call in turn. The fact that this behaviour is, in this
example, peculiar to the amber light, demonstrates the pertinence of
my first objection above.
Fortunately the "C++ and Java" approach, (though I would never want to
be seen advocating the C++ or Java approach to anything), is in this
case available in Python as well, at the cheaper price of fewer
characters and arguably greater readibility to boot.
I know, Iknow ... you wanted to show how that code could be used in a
non "sulphurous" way. Which just goes to show that the devil makes
work for idle hands ... or foils the best laid plans ... or is in the
detail ... or something sulphurous. :)