Introducing Python to others
Paddy O'Loughlin
As our resident python advocate, I've been asked by my team leader to
give a bit of a presentation as an introduction to python to the rest
of our department.
It'll be less than an hour, with time for taking questions at the end.
There's not going to be a whole lot of structure to it. First, I'm
going to open up a python terminal and show them how the interpreter
works and a few basic syntax things and then a file .py files (got to
show them that python's indenting structure is not something to be
afraid of :P). I think I'll mostly show things in the order that they
appear in the python tutorial (http://docs.python.org/tutorial/).
My question to you, dear python-list, is what suggestions do you have
for aspects of python that I should show them to make them maybe think
that python is better than what they are using at the moment.
All of the audience will be experienced (4+ years) programmers, almost
all of them are PHP developers (2 others, plus myself, work in C, know
C#, perl, java, etc.).
Because of this, I was thinking of making sure I included exceptions
and handling, the richness of the python library and a pointing out
how many modules there were out there to do almost anything one could
think of.
Anything else you think could make PHP developers starting think that
python is a better choice?
If I were to do a (very) short demonstration one web framework for the
PHP devs, what should I use? CherryPy (seems to be the easiest),
Django (seems to be the "biggest"/most used), or something else?
Any other suggestions for a possible "wow" reaction from an audience like that?
Thanks,
Paddy
--
"Ray, when someone asks you if you're a god, you say YES!"
*nixtechno
wrote:
Yeah tell them that they don't have to REWRITE all their code again,
just fix VERY MINOR things when required if there is a drastic
change... I would bite if I learned this a long time ago if I knew
that, and also threading in python is WAYYYYYYYYYYYYYYYYYYYYYYYYY
better, somethings in PHP you can't do like you can within python when
it comes to threading (which I'm stumped on right now in a project of
mine...)
I may add that debugging is a learning curve for sure, how and where
to place what when trying to debug a script in python.... So I would
mostly concentrate on the CORE thing of NO MORE rewriting your WHOLE
library for a change like you have to do with PHP. :)
My opinion.
Hendrik van Rooyen
> Any other suggestions for a possible "wow" reaction from an audience like
that?
two simple demos:
The first one is a simple client server thingy on the LAN.
I have seen hardened people do a double take
when they see how little code it takes to set up a server
and a client.
The second is in the same vein - use the xmlrpc demo from
the docs to do a simple remote call. In this also do a deliberate
mistake, and show them how the remote exception pops up
locally...
And the third of the two would be the mrs premise demo from the
shared memory stuff shm in which two independent processes
happily share a piece of ram...
hth - Hendrik
Bruno Desthuilliers
(snip)
> Anything else you think could make PHP developers starting think that
> python is a better choice?
The debugger ?-) (debugging PHP code is kind of nightmare).
> If I were to do a (very) short demonstration one web framework for the
> PHP devs, what should I use? CherryPy (seems to be the easiest),
> Django (seems to be the "biggest"/most used), or something else?
AFAICT from lurking on django-users, it seems that quite a few PHP
developpers are switching to Django and really like it.
> Any other suggestions for a possible "wow" reaction from an audience like that?
cf Hendrik's suggestions...
Marco Mariani
> All of the audience will be experienced (4+ years) programmers, almost
> all of them are PHP developers (2 others, plus myself, work in C, know
> C#, perl, java, etc.).
Show them the same classical design patterns in Java and Python. Explain
how it's much more flexible.
> Any other suggestions for a possible "wow" reaction from an audience like that?
SQLAlchemy / SQLSoup, and XML handling with lxml.
pyt...@bdurham.com
I've tried to categorize some ideas for your presentation. Note that the
ideas within each category are ordered by my random "stream of
conscience" vs. prioritized in some logical order.
Good luck with your presentation! (BTW: It would be great if you could
share your final outline with this list so others have a starting point
for similar presentations)
Malcolm
Language basics to reassure developers their favorite capabilities
are present:
1. "Batteries included" examples for web, ftp, smtp, pop3/imap,
zip/gzip/tar, regular expressions
2. A simple database example to show that database access is really no
different than other tools
3. Exception handling example
4. Reading/writing files (iterating through text files)
5. Working with folders and files (os, shutil)
6. A simple class example and a class example showing multiple
inheritance (mixin)
7. Simple string manipulation example (also reinforce Unicode support)
8. Modules (including the ability to reference modules in a zip file)
Unique Python features:
1. Lists, dictionaries and sets
2. Pickling
3. IDLE console
4. Working with command line args (and optionally optparse)
5. Dynamic code evaluation (eval/exec)
6. String constant prefixes (r, b, u) and triple quoted strings that
span multiple lines
7. Indentation as syntax (plus no need for line continuation chars when
bracketed delimiters are in play)
8. Doc string commenting, help( object ), and dir( object )
Advanced Python features:
1. Threading and/or multiprocessing
2. Creating a Python based web server for offline apps/testing
3. A web framework like Django or (simple) web.py
4. A sample templating module
5. Sample parsers (lxml and/or pyparser)
6. Overriding built-in __methods__ so custom classes can support use
with operators (encourages polymorphism)
7. Iterators and generators
8. List and dictionary comprehensions
Scott David Daniels
> "Paddy O'Loughlin" <patrick....@gmail.com> wrote:
>> Any other suggestions for a possible "wow" reaction from an audience like
> that?
> two simple demos:
> The first one is a simple client server thingy on the LAN.
> I have seen hardened people do a double take
> when they see how little code it takes to set up a server
> and a client.
after you get it working, and show how little you had to change,
and how quickly the new feature is working.
I'd shrink recapitulating the tutorial, 1 hour is a very short time.
Perhaps a "strange variable model," huge integers, defining a function,
class, using modules, what "global" does and means (if you have time)
and a hand-wave about types.
[other excellent choices deleted]
--Scott David Daniels
Scott....@Acm.Org
David C. Ullrich
"Paddy O'Loughlin" <patrick....@gmail.com> wrote:
Here's my favorite thing about Python (you'd of course
remark that it's just a toy example, doing everything
in as dumb but easily understood way as possible):
x=[1,2]
print x+x
class Vector():
def __init__(self, data):
self.data = data
def __repr__(self):
return repr(self.data)
def __add__(self, other):
return Vector([self.data[0]+other.data[0],
self.data[1]+other.data[1]])
x = Vector([1,2])
print x+x
--
David C. Ullrich
J. Cliff Dyer
with `from foo import *`. Instead show them (using how by using `import
foo` and `from foo import x, y, z`, your namespace only has those things
you explicitly imported, plus the contents of `dir(__builtins__)`.
2) Aliasing imports is also cool. Show people how easy it is to switch
from
>>> import MySQLdb as db
to
>>> import psycopg2 as db
and have all your dbapi2 code still work. Or from
>>> from StringIO import StringIO
to
>>> from cStringIO import StringIO
3) Functions as first-class variables (which could connect to a
discussion of decorators or of dictionaries as dispatch tables).
4) List comprehensions
5) Generators using yield
6) Also very handy is the interactive interpreter and the ability to
type `dir(foo)` and `help(foo)` to see what facilities are available to
you.
> Thanks,
> Paddy
>
Cheers,
Cliff
andrew cooke
> In article <mailman.2701.1238060...@python.org>,
> "Paddy O'Loughlin" <patrick....@gmail.com> wrote:
>
> Here's my favorite thing about Python (you'd of course
> remark that it's just a toy example, doing everything
> in as dumb but easily understood way as possible):
>
> x=[1,2]
>
> print x+x
>
> class Vector():
> def __init__(self, data):
> self.data = data
> def __repr__(self):
> return repr(self.data)
> def __add__(self, other):
> return Vector([self.data[0]+other.data[0],
> self.data[1]+other.data[1]])
>
> x = Vector([1,2])
>
> print x+x
that's cute, but if you show them 2.6 or 3 it's even cuter:
>>> from operator import add
>>> class Vector(list):
... def __add__(self, other):
... return map(add, self, other)
...
>>> x = Vector([1,2])
>>> x+x
[2, 4]
andrew
Mensanator
Mind if I ask a question? In DU's code, both operands have to
be instances of the Vector class?
>>> x = Vector([1,2])
>>> x+x
[2, 4]
>>> x+[3,3]
Traceback (most recent call last):
File "<pyshell#60>", line 1, in <module>
x+[3,3]
File "<pyshell#55>", line 7, in __add__
return SV([self.data[0]+other.data[0],self.data[1]+other.data[1]])
AttributeError: 'list' object has no attribute 'data'
Whereas with your version, "other" just has to be an iterable.
>>> x = Vector([1,2])
>>> x+x
[2, 4]
>>> x+[3,3]
[4, 5]
>>> x+(9,9)
[10, 11]
>>> x+{3:4,4:9}
[4, 6]
Although it does require the same number of elements (because that's
required by map and could be changed if necessary).
>>> x+[3,3,3]
Traceback (most recent call last):
File "<pyshell#71>", line 1, in <module>
x+[3,3,3]
File "<pyshell#62>", line 3, in __add__
return map(add,self,other)
TypeError: unsupported operand type(s) for +: 'NoneType' and 'int'
What would you have to do to make this work?
>>> x+x+x # expecting [3,6]
[2, 4, 1, 2]
mma...@gmx.net
"andrew cooke" <and...@acooke.org> wrote:
> that's cute, but if you show them 2.6 or 3 it's even cuter:
>
> >>> from operator import add
> >>> class Vector(list):
> ... def __add__(self, other):
> ... return map(add, self, other)
> ...
> >>> x = Vector([1,2])
> >>> x+x
> [2, 4]
Works for me in 2.5.4 (Linux) :-)
Martin
Peter Otten
Use itertools.imap() which stops when the shortest sequence is exhausted and
have Vector.__add__() return a Vector:
>>> from operator import add
>>> from itertools import imap
>>> class Vector(list):
... def __add__(self, other):
... return Vector(imap(add, self, other))
...
>>> a = Vector([1,2,3])
>>> a + [10, 20]
[11, 22]
>>> a + a + a
[3, 6, 9]
>>>
Peter
Paddy O'Loughlin
A lot of very strong answers :)
2009/3/26 Mensanator <mensa...@aol.com>:
> What would you have to do to make this work?
>
>>>> x+x+x # expecting [3,6]
> [2, 4, 1, 2]
What's happening is that the call to map() is returning a list object.
So after it calculates the first "x+x", you are left with the equivalent of:
[6, 6] + x
Because the list object is on the left, it's __add__() function is
called, which appends x to [6,6].
Instead, convert the list returned by map to a Vector before returning
it. Like so:
>>> class Vector(list):
... def __add__(self, other):
... return Vector(map(add, self, other))
...
>>> x = Vector([3,3])
>>> x+x+x
[9, 9]
Irmen de Jong
it could be very wow-provoking if you have a nice example using ctypes
to interface to existing c libraries.
Python shines as a glue language too :-)
--irmen
Scott David Daniels
>> that's cute, but if you show them 2.6 or 3 it's even cuter:
>>
>>>>> from operator import add
>>>>> class Vector(list):
>> ... def __add__(self, other):
>> ... return map(add, self, other)
>> ...>>> x = Vector([1,2])
>>>>> x+x
>> [2, 4]
>
>
>>>> x+x+x # expecting [3,6]
> [2, 4, 1, 2]
>
class Vector(list):
def __add__(self, other):
return type(self)(x + y for x, y in zip(self, other))
def __sub__(self, other):
return type(self)(x - y for x, y in zip(self, other))
def __repr__(self):
return '%s(%s)' % (
type(self).__name__, list.__repr__(self))
x = Vector([1,2])
x + x + x
--Scott David Daniels
Scott....@Acm.Org
Jervis Whitley
>>>
>>> ... def __add__(self, other):
>>> ... return map(add, self, other)
>>> ...>>> x = Vector([1,2])
I've used the complex type for a similar problem (2D Cartesian points)
in the past, I saw the suggestion
once on the pygame list.
>>> x = complex(1,2)
>>> x + x
(2 + 4j)
Cheers,
Jervis
Mensanator
But those are floats aren't they?
Don't games use stuff like pixels per parsec? :-)
>
> Cheers,
>
> Jervis
Rhodri James
<patrick....@gmail.com> wrote:
> Because of this, I was thinking of making sure I included exceptions
> and handling, the richness of the python library and a pointing out
> how many modules there were out there to do almost anything one could
> think of.
Once you've shown them exceptions, show them context managers briefly.
It's amazing how much they can simplify some types of exception handling.
--
Rhodri James *-* Wildebeeste Herder to the Masses
Delaney, Timothy (Tim)
> On Thu, 26 Mar 2009 09:35:55 -0000, Paddy O'Loughlin
> <patrick....@gmail.com> wrote:
>
>> Because of this, I was thinking of making sure I included exceptions
>> and handling, the richness of the python library and a pointing out
>> how many modules there were out there to do almost anything one could
>> think of.
>
> Once you've shown them exceptions, show them context managers briefly.
> It's amazing how much they can simplify some types of exception
> handling.
I would second this. Basically, write something in idiomatic PHP or
Java, and write the direct translation to Python. Then show them the
idiomatic Python.
Of course, you need to be upfront that this may in some cases work in
reverse, but that in your experience idiomatic Python code that has the
same effect tends to be considerably clearer and shorter.
try/finally -> with is an excellent example of idiomatic python. I'd
suggest IO would be the best candidate - something along the lines of:
f = open('path', 'w')
try:
f.write('Hello, world!')
finally:
f.close()
to:
with open('path', 'w') as f:
f.write('Hello, world!')
Mention that locks (threading) are also context managers, there's a
built-in "closing" context manager (and what it does), and explain how
you can write any context manager you like.
Tim Delaney
André
wrote:
> Hi,
> As our resident python advocate, I've been asked by my team leader to
> give a bit of a presentation as an introduction to python to the rest
> of our department.
> It'll be less than an hour, with time for taking questions at the end.
>
> There's not going to be a whole lot of structure to it. First, I'm
> going to open up a python terminal and show them how the interpreter
> works and a few basic syntax things and then a file .py files (got to
> show them that python's indenting structure is not something to be
> afraid of :P). I think I'll mostly show things in the order that they
> appear in the python tutorial (http://docs.python.org/tutorial/).
>
Shameless plug:
Show them the Python tutorial in a regular browser window ... and then
switch tab to one in which you have the same tutorial loaded from
Crunchy (http://code.google.code/p/crunchy) and go through it
(interpreter and all) right from the browser's window. I've had some
really positive reactions from long-term Pythonistas when I did that
one-on-one two years ago.
Then perhaps use IPython as a terminal window and show them other cool
stuff that people have mentioned.
André
Beni Cherniavsky
On Mar 26, 7:35 pm, "J. Cliff Dyer" <j...@sdf.lonestar.org> wrote:
>
> 2) Aliasing imports is also cool. Show people how easy it is to switch
> from
>
> >>> import MySQLdb as db
> to
> >>> import psycopg2 as db
>
> and have all your dbapi2 code still work. Or from
>
> >>> from StringIO import StringIO
> to
> >>> from cStringIO import StringIO
>
For even cooler effect, show them that it can be decided at run time:
try:
from cStringIO import StringIO
except ImportError:
from StringIO import StringIO
> 3) Functions as first-class variables (which could connect to a
> discussion of decorators or of dictionaries as dispatch tables).
>
If you show this, show bound methods as first-class values.
Explain how class and module namespaces are really simple dicts.
> 4) List comprehensions
>
> 5) Generators using yield
>
And generator expressions. Show off things like sum(x**2 for x in
range(10)).
When showing generators, I like to explain how Python allows you to
build abstractions - take common patterns and give them names:
- generator + for loop = abstraction over while loop
- context manager + with statement = abstraction over try statement
- decorators = abstraction over def statement
- metaclasses = abstraction over class statement
(you don't have time to show metaclasses, but you can mention their
existance)
---
Unrelated cool stuff to show off: doctest, VPython
BackSeat
wrote:
> If I were to do a (very) short demonstration one web framework for the
> PHP devs, what should I use?
No question: use web2py. See the website and the videos that
demonstrate it. You could build a reasonably substantial application
in 2-3 minutes if you practice it first - for example, a wiki.
David C. Ullrich
<039360fb-a29c-4f43...@z23g2000prd.googlegroups.com>,
Mensanator <mensa...@aol.com> wrote:
Yes, in the code I posted. That code was not meant to be
an example of the right way to do anything, just an
illustration of how wonderful things like __add__ can be.
--
David C. Ullrich
David C. Ullrich
Scott David Daniels <Scott....@Acm.Org> wrote:
> Mensanator wrote:
> > On Mar 26, 11:42 am, "andrew cooke" <and...@acooke.org> wrote:
> >> ...
> >> that's cute, but if you show them 2.6 or 3 it's even cuter:
> >>
> >>>>> from operator import add
> >>>>> class Vector(list):
> >> ... def __add__(self, other):
> >> ... return map(add, self, other)
> >> ...>>> x = Vector([1,2])
> >>>>> x+x
> >> [2, 4]
> >
> > What would you have to do to make this work?
> >
> >>>> x+x+x # expecting [3,6]
> > [2, 4, 1, 2]
> >
>
> class Vector(list):
> def __add__(self, other):
> return type(self)(x + y for x, y in zip(self, other))
Question: I would have thought it would be
return type(self)([x + y for x, y in zip(self, other)])
What's this thing that looks like a list comprehension but isn't?
Comment:
I didn't mean to start a big deal, but as long as it's started:
Of course returning that list as in Andrew's example is not what
we want. Someone said we should return a Vector instead. That's
probably what the demo should do, but in stuff like this that
I actually _use_ I tend to do something like what you do here
(with very different spelling, since type(self) wouldn't work
in the bad old days.) The reason of course being that we want
subclasses to return instances of the subclass automatically.
On the other hand I have this vague feeling that explicitly
inspecting the type like this is "wrong" - I've always wondered
whether this is the "right" way to do it. ???
> def __sub__(self, other):
> return type(self)(x - y for x, y in zip(self, other))
> def __repr__(self):
> return '%s(%s)' % (
> type(self).__name__, list.__repr__(self))
>
> x = Vector([1,2])
> x + x + x
>
> --Scott David Daniels
> Scott....@Acm.Org
--
David C. Ullrich
andrew cooke
> In article <TM6dnZxRVIQ0QFbU...@pdx.net>,
> Scott David Daniels <Scott....@Acm.Org> wrote:
>
>> Mensanator wrote:
>> > On Mar 26, 11:42 am, "andrew cooke" <and...@acooke.org> wrote:
>> >> ...
>> >> that's cute, but if you show them 2.6 or 3 it's even cuter:
>> >>
>> >>>>> from operator import add
>> >>>>> class Vector(list):
>> >> ... def __add__(self, other):
>> >> ... return map(add, self, other)
>> >> ...>>> x = Vector([1,2])
>> >>>>> x+x
>> >> [2, 4]
>> >
>> > What would you have to do to make this work?
>> >
>> >>>> x+x+x # expecting [3,6]
>> > [2, 4, 1, 2]
>> >
>>
>> class Vector(list):
>> def __add__(self, other):
>> return type(self)(x + y for x, y in zip(self, other))
>
> Question: I would have thought it would be
>
> return type(self)([x + y for x, y in zip(self, other)])
>
> What's this thing that looks like a list comprehension but isn't?
it's a generator expression.
http://docs.python.org/3.0/reference/expressions.html#index-3735
andrew
David C. Ullrich
"andrew cooke" <and...@acooke.org> wrote:
> David C. Ullrich wrote:
> > In article <TM6dnZxRVIQ0QFbU...@pdx.net>,
> > Scott David Daniels <Scott....@Acm.Org> wrote:
[...]
> >>
> >> class Vector(list):
> >> def __add__(self, other):
> >> return type(self)(x + y for x, y in zip(self, other))
> >
> > Question: I would have thought it would be
> >
> > return type(self)([x + y for x, y in zip(self, other)])
> >
> > What's this thing that looks like a list comprehension but isn't?
>
> it's a generator expression.
> http://docs.python.org/3.0/reference/expressions.html#index-3735
Ah, thanks. I see "dict comprehensions" there too - keen.
Sometime I gotta get around to actually learning this 2.x
stuff. Thought I had an idea how 1.x worked...
> andrew
--
David C. Ullrich
Sells, Fred
Using a dictionary to return a function or a class definition based on a
msg id and let that returned value "handle" the message that contained
the id. Something like
Class XYZ:
...
MyHandlers = {42:XYZ, ...
Message = read_from_somewhere_else()
HandlerDefn = MyHandlers[Message.id]
Handler = HandlerDefn(Message)
Handler.processMessage()
As opposed to a switch statement in other languages.
I get my fellow codes to install Eclipse+PyDev as I find it easier to
comprehend that IDLE. It's nice to just hit F9; although ^c^c is cool
for emacs folks.
I prefer turbogears over Django because it is simpler (and thus less
robust) but it sure is cool to edit your server side code, save it and
watch the server reload it automatically. Of couse I hate HTML and use
Flex for the client side and turbogears JSON or my own XML converter
make Flex a joy.
Good luck
Fred.
> -----Original Message-----
> From: python-list-bounces+frsells=adventis...@python.org
> [mailto:python-list-bounces+frsells=adventis...@python.org] On
> Behalf Of Paddy O'Loughlin
> Sent: Thursday, March 26, 2009 5:36 AM
> To: pytho...@python.org
> Subject: Introducing Python to others
>
> Hi,
> As our resident python advocate, I've been asked by my team leader to
> give a bit of a presentation as an introduction to python to the rest
> of our department.
> It'll be less than an hour, with time for taking questions at the end.
>
> There's not going to be a whole lot of structure to it. First, I'm
> going to open up a python terminal and show them how the interpreter
> works and a few basic syntax things and then a file .py files (got to
> show them that python's indenting structure is not something to be
> afraid of :P). I think I'll mostly show things in the order that they
> appear in the python tutorial (http://docs.python.org/tutorial/).
>
> My question to you, dear python-list, is what suggestions do you have
> for aspects of python that I should show them to make them maybe think
> that python is better than what they are using at the moment.
> All of the audience will be experienced (4+ years) programmers, almost
> all of them are PHP developers (2 others, plus myself, work in C, know
> C#, perl, java, etc.).
> Because of this, I was thinking of making sure I included exceptions
> and handling, the richness of the python library and a pointing out
> how many modules there were out there to do almost anything one could
> think of.
> Anything else you think could make PHP developers starting think that
> python is a better choice?
> If I were to do a (very) short demonstration one web framework for the
> PHP devs, what should I use? CherryPy (seems to be the easiest),
> Django (seems to be the "biggest"/most used), or something else?
>
> Any other suggestions for a possible "wow" reaction from an audience
like
> that?
>
> Thanks,
> Paddy
>
> --
> "Ray, when someone asks you if you're a god, you say YES!"
> --
> http://mail.python.org/mailman/listinfo/python-list
---[Notification]--------------------------------------------------------------------
The information contained in this message may be privileged and / or
confidential and protected from disclosure. If the reader of this message is
not the intended recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited. If you
have received this communication in error, please notify the sender
immediately by replying to this message and deleting the material from any
computer.
--------------------------------------------------------------------------------------
Rhodri James
<dull...@sprynet.com> wrote:
> Sometime I gotta get around to actually learning this 2.x
> stuff. Thought I had an idea how 1.x worked...
3.x may come as a bit of a surprise :-)