python for everyday tasks


K

koch.mate

Hello,

I'm about held a short course with the title indicated in the subjects. The students are very experienced programmers of our company, with deep knoledge on C, C++, C#, Perl and similar languages, but very limited, or absolutely no knowledge on python.

what would you teach to such a group in 5x1.5 hours? I'm looking for the most interesting, unique topics, emphesizing python's strong points.

I have already a couple ideas:
- a general intro about tuples, lists, dicts, sets, and working with these
- functional programming tools, functools, itertools, lambda, map, filter
- wsgi, pickle

I'd appreciate a lot if you could add some ideas

thanks,
Mate
 
Ad

Advertisements

S

Steven D'Aprano

Hello,

I'm about held a short course with the title indicated in the subjects.
The students are very experienced programmers of our company, with deep
knoledge on C, C++, C#, Perl and similar languages, but very limited, or
absolutely no knowledge on python.

what would you teach to such a group in 5x1.5 hours? I'm looking for the
most interesting, unique topics, emphesizing python's strong points.

I have already a couple ideas:
- a general intro about tuples, lists, dicts, sets, and working with
these - functional programming tools, functools, itertools, lambda,
map, filter - wsgi, pickle


Do you have any system administrators in the audience? If so, I'd show
the IPython shell, which includes a lot of custom "magic" to make it a
powerful shell as easy to use as bash. For example, compare the regular
Python REPL:

py> import os, glob
py> glob.glob(os.path.expanduser('~/lam*'))
['/home/steve/lambert.ods', '/home/steve/lambert.csv', '/home/steve/
lambertw.pdf', '/home/steve/lambert-v2.pdf', '/home/steve/lambert.txt']


with the IPython shell:

In [1]: ls ~/lam*
/home/steve/lambert.csv /home/steve/lambert.txt /home/steve/
lambertw.pdf
/home/steve/lambert.ods /home/steve/lambert-v2.pdf


You'll probably want to discuss the similarities and differences between
Python and other languages. In my experience, the most confusing part of
learning a new language is the things which are *almost* but not quite
the same, rather than those which are radically different. When things
are obviously different, you come in to it with no preconceived ideas.


* Python uses name binding, not variables at fixed locations;

* therefore there are no pointers (except under the hood, in the
implementation);

* but you won't miss them. Honest.

* Python uses "call by object sharing", which is exactly the same calling
convention that the Java people call "call by value" and Ruby people call
"call by reference". Here's an opinionated post I wrote some years ago
describing the differences:

https://mail.python.org/pipermail/tutor/2010-December/080505.html


* Python is not Java, and Java is not Python either:

http://dirtsimple.org/2004/12/python-is-not-java.html
http://dirtsimple.org/2004/12/java-is-not-python-either.html

* Everything in Python is an object. *Everything*. There is no
distinction between boxed and unboxed integers, for example, they're all
boxed.

* When I say everything, I mean it. Functions and methods are objects
too. So are classes, and yes, that means that you can inspect the class
of a class (the metaclass).

* Need high performance numeric computing? Python tools like numpy,
pandas, nltk and others are rapidly becoming *the* standard tool for
numeric and scientific computing:

http://blog.mikiobraun.de/2013/11/how-python-became-the-language-of-
choice-for-data-science.html

http://www.talyarkoni.org/blog/2013/11/18/the-homogenization-of-
scientific-computing-or-why-python-is-steadily-eating-other-languages-
lunch/


* Some terminology differences:

- What some languages call members, or class variables and
instance variables, Python usually calls class or instance
attributes. (Although the documentation is a tad inconsistent
in this.) This makes sense: if a string variable is a
variable holding a string, and an int variable is a variable
holding an int, then surely a class variable is a variable
holding a class. (Remember what I said about classes being
objects too?)

- Python class methods are what Java calls static methods, and
Python static methods are kind of like functions only not.
(You'll probably never find a good use for static methods in
Python.)

- There are no procedures or void functions in Python, but
there are functions which return None, which is as close as
you'll get to nil or null.

- I already mentioned the pass by object sharing thing.

* The Zen of Python: at the interactive interpreter, type "import this".
It's not quite a joke and not quite serious, but a little of both, and it
gives a good insight into what the Python core developers consider best
practice.

* Note to Perl coders: you'll notice that "Only One Way To Do It" is NOT
in there, and it never has been.

* Docstrings and doctest.

* Unittest is great for test-driven development.

* Python 3 (although not Python 2) is one of the few languages that get
Unicode *right*. Strings in Python 3 are text, sequences of Unicode
characters, not a thinly disguised blob of bytes. Starting with Python
3.3, Python does away with the difference between "narrow builds" (which
save memory at the expense of correctness) and "wide builds" (which give
correct Unicode behaviour at the cost of memory). Instead, Python 3.3 now
has optimized strings that use only as much memory as needed. Pure ASCII
strings will use 1 byte per character, while Unicode strings use 1, 2 or
4 bytes per character as needed. And it all happens transparently.

* If you want a blob of bytes, Python 3 has the bytes and bytearray
classes. But don't use blobs of bytes when you want text.

* Python comes standard with support for the main Unicode encodings
(UTF-8, UTF-16, UTF-32 and UTF-7), plus a whole mess of legacy encodings,
like ASCII, Latin-1, ISO-8859-7, and many more.

* In Python, at least the standard CPython implementation, threads won't
give you any benefit in CPU-bound tasks, although they will speed up IO-
bound tasks. On Linux, at least, using multiple processes instead of
multiple threads is the way to go.

* List comprehensions (borrowed from Haskell, but with nicer syntax).

* Lazy processing with generators and generator expressions.

* Coroutines: http://dabeaz.com/coroutines/



Some of these things (e.g. coroutines, metaclasses) can be extremely
advanced, and perhaps you only want to mention them in passing just to
give a flavour for what you can do with Python.
 
N

Ned Batchelder

Hello,

I'm about held a short course with the title indicated in the subjects. The students are very experienced programmers of our company, with deep knoledge on C, C++, C#, Perl and similar languages, but very limited, or absolutely no knowledge on python.

what would you teach to such a group in 5x1.5 hours? I'm looking for the most interesting, unique topics, emphesizing python's strong points.

I have already a couple ideas:
- a general intro about tuples, lists, dicts, sets, and working with these
- functional programming tools, functools, itertools, lambda, map, filter
- wsgi, pickle

I'd appreciate a lot if you could add some ideas

thanks,
Mate

I gave a 45-minute presentation at the DevDays conference in 2009 to introduce programmers to Python. The slides are here: http://nedbatchelder.com/text/devdays.html Sorry there's no text to go with them.

They introduce the good points of Python, then go through two code exercises: Peter Norvig's spellchecker, which is great for showing off data structures; and a micro templating engine, which takes advantage of Python's dynamic nature.

--Ned.
 
D

Dan Stromberg

Teach that Python emphasizes readability. Perhaps talk about bugs /
lines_of_code being roughly a constant. Then talk about the fact that
Python generally takes fewer lines of code to express the same thing. This
implies fewer bugs for many projects.

Teach the fundamental types, with differences from other languages: int,
float (C double), decimal, maybe fractions. Booleans. lists, arrays,
dictionaries, sets, tuples, frozensets.

Teach that variables don't have a type, but values do. Teach a = b. Teach
a, b = b, a. Teach that python is duck typed (dynamically typed), and
isn't manifestly or statically typed. Provide definitions. Discuss what
it means to be "strongly typed", which doesn't mean what a lot of people
think it does: Python is strongly typed, the main exception being that you
can use almost anything in a boolean context.

Teach the control flow, with differences from other languages: while,
for/else, if/elif/else. break/continue, list comprehensions, and maybe
generator expressions. Include things like enumerate() and iterators and
with statements. Probably do yield too - it's not crucial to being
productive in python, but it's plenty useful; probably show how it can
generate powers of 2 forever or something.

Teach that python has builtins, not keywords - IOW, you can redefine list
or int, but you probably shouldn't. pylint helps with this.

Teach classes with __init__. Teach __str__, __repr__, and teach __cmp__
or __lt__ (depending on your python version), and perhaps some other magic
methods like (a subset of) emulating a container, or emulating a number.
Maybe talk about Python's stellar built in Timsort that was later adopted
by Java.

Teach pylint, including how to turn off unimportant warnings; I usually do
this in my code, but you can also use a pylintrc. A short time talking
about pylint (or pychecker or pyflakes, and perhaps pep8 too) should help
them teach themselves quite a bit - think of these as expert systems about
how to write better python. Personally, I use a pyflakes plugin in vim,
but my default "make" rule invokes pylint for "the" entire project, as well
as my automated tests one at a time. Sometimes my default "make" rule does
pep8 too, but not always; pylint covers a lot of what pep8 does anyway.

Touch briefly on a cross-platform debugger like winpdb (it's cross-platform
despite the name) or pudb. Some people will prefer to just do print
functions/statements (again depending on python version), but others will
really value the debugger, and some people will use some of both.

Stress the importance of automated tests relative to other languages. IMO,
even with pylint, having plenty of good automated tests is crucial in a
large python project, especially if it's multi-programmer.

If you have time, provide some guidance about whether to use Python 2.x or
3.x. IMO, projects that have their dependencies satisfied in 3.x (or have
no dependencies!), should use 3.x today. Otherwise, use 2.x with "from
__future__" imports where practical.

Talk about decorators.

If you have time, maybe talk about available interpreters: CPython 2.x,
CPython 3.x, Jython (python in java that can call java classes), Pypy
(python in python with a JIT), IronPython (IronPython lacks a standard
library for the most part, but lets you talk to .net classes). Maybe also
talk about Python in the browser:
http://stromberg.dnsalias.org/~strombrg/pybrowser/python-browser.html .
There was a time when Jython could be used for in-browser-python by
generating .class files, but I don't think it can anymore, and java browser
plugins seem to be disappearing anyway; the world seems to be heading
toward javascript for in-browser, RIA.

Feel free to raid
http://stromberg.dnsalias.org/~dstromberg/Intro-to-Python/for slides.

HTH
 
Ad

Advertisements

K

koch.mate

Thank you very much, that's much more detailed than I dared to hope for, it's going to be a great help. :) Since the course will begin in January, I'm just starting to prepare, I'm happy to hear any other ideas, comments.

Thank you all,
Mate
 
W

wxjmfauth

Le samedi 23 novembre 2013 03:01:26 UTC+1, Steven D'Aprano a écrit :
* Python 3 (although not Python 2) is one of the few languages that get

Unicode *right*. Strings in Python 3 are text, sequences of Unicode

characters, not a thinly disguised blob of bytes. Starting with Python

3.3, Python does away with the difference between "narrow builds" (which

save memory at the expense of correctness) and "wide builds" (which give

correct Unicode behaviour at the cost of memory). Instead, Python 3.3 now

has optimized strings that use only as much memory as needed. Pure ASCII

strings will use 1 byte per character, while Unicode strings use 1, 2 or

4 bytes per character as needed. And it all happens transparently.


----------



[topic beeing more of less closed]

Your paragraph is mixing different concepts.

When it comes to save memory, utf-8 is the choice. It
beats largely the FSR on the side of memory and on
the side of performances.

How and why? I suggest, you have a deeper understanding
of unicode.

May I recall, it is one of the coding scheme endorsed
by "Unicode.org" and it is intensively used. This is not
by chance.

jmf
 
M

Michael Torrie

I only respond here, as unicode in general is an important concept that
the OP will to make sure his students understand in Python, and I don't
want you to dishonestly sow the seeds of uncertainty and doubt.

Your paragraph is mixing different concepts.

On the contrary, it appears you are the one mixing the concepts, and
confusing a byte-encoding scheme with unicode.

In an ideal world, the programmer should not need to know or care about
what encoding scheme the language is using internally to store strings.
And it does not matter whether the internal encoding scheme is endorsed
by the unicode commission or not, provided it can handle all the valid
unicode constructs.

A string is unicode. Period. Hence you must concern yourself with
encoding only when reading or writing a byte stream.

Inside the language itself, the encoding is irrelevant. Ideally. In
python 3.3+ anyway. Of course reality is different in other languages
which is why programmers are used to worrying about things like exposing
surrogate pairs (as Javascript does), or having to tweak your algorithms
to deal with the fact that UTF-8 indexing is not O(1). To claim that a
programmer has to concern himself with internal language encoding in
Python 3 is not only untrue, it's ingenuousness at best, given the OP's
mission.
When it comes to save memory, utf-8 is the choice. It
beats largely the FSR on the side of memory and on
the side of performances.

So you would condemn everyone to use an O(n) encoding for a string when
FSR offers full unicode compliance that optimizes both speed and memory?

No, D'Aprano is correct. Python 3.3+ indeed does unicode right. It
offers O(1) slicing, is memory efficient, and never exposes things like
surrogate pairs.
How and why? I suggest, you have a deeper understanding
of unicode.

Indeed I'd say D'Aprano does have a deeper understanding of unicode.
May I recall, it is one of the coding scheme endorsed
by "Unicode.org" and it is intensively used. This is not
by chance.

Yes, you keep saying this. Have you encountered a real-world situation
where you are impacted by Python's FSR? You keep posting silly
benchmarks that prove nothing, and continue arguing, yet presumably you
are still using Python. Why haven't you switched to Google Go or
another language that implements unicode strings in UTF-8?
 
C

Chris Angelico

Have you encountered a real-world situation
where you are impacted by Python's FSR?

Python 3.3 was released back in September 2012, over a year ago. As
far as python-list can be aware, nobody - but nobody - has had any
problem with it except for jmf. I'm not entirely sure how this works -
it's fundamentally flawed for him, yet brilliant for everyone else.
Must be some sort of Bermuda Triangle effect around him, I think;
whatever it is, chaos scientists doubtless want to explore this.

Of course, a year isn't all that long, in computing. A 1GHz CPU core
can process about 3E16 instructions in that time. Maybe that's just
not sufficient evaluation time. Well, Pike's had the same
functionality - variable-width strings - since... well, I can't be
100% sure, but I found a reference to the size_shift field (1 for
8-bit, 2 for 16-bit, 3 for 32-bit) in a commit dated 1998, so I think
that's probably about when it was added. Somehow this concept has been
around and not breaking stuff for 15 years, and now it breaks all
jmf's code. There must be something very strange going on here, and I
really think it warrants investigation.

(Fifteen years. It's seventeen years since Unicode 2.0, when 16-bit
characters were outmoded. It's about time _every_ modern language
followed Python's and Pike's lead and got its Unicode support right.)

ChrisA
 
W

wxjmfauth

Le lundi 25 novembre 2013 16:11:22 UTC+1, Michael Torrie a écrit :
I only respond here, as unicode in general is an important concept that

the OP will to make sure his students understand in Python, and I don't

want you to dishonestly sow the seeds of uncertainty and doubt.







On the contrary, it appears you are the one mixing the concepts, and

confusing a byte-encoding scheme with unicode.



In an ideal world, the programmer should not need to know or care about

what encoding scheme the language is using internally to store strings.

And it does not matter whether the internal encoding scheme is endorsed

by the unicode commission or not, provided it can handle all the valid

unicode constructs.



A string is unicode. Period. Hence you must concern yourself with

encoding only when reading or writing a byte stream.



Inside the language itself, the encoding is irrelevant. Ideally. In

python 3.3+ anyway. Of course reality is different in other languages

which is why programmers are used to worrying about things like exposing

surrogate pairs (as Javascript does), or having to tweak your algorithms

to deal with the fact that UTF-8 indexing is not O(1). To claim that a

programmer has to concern himself with internal language encoding in

Python 3 is not only untrue, it's ingenuousness at best, given the OP's

mission.








So you would condemn everyone to use an O(n) encoding for a string when

FSR offers full unicode compliance that optimizes both speed and memory?



No, D'Aprano is correct. Python 3.3+ indeed does unicode right. It

offers O(1) slicing, is memory efficient, and never exposes things like

surrogate pairs.







Indeed I'd say D'Aprano does have a deeper understanding of unicode.








Yes, you keep saying this. Have you encountered a real-world situation

where you are impacted by Python's FSR? You keep posting silly

benchmarks that prove nothing, and continue arguing, yet presumably you

are still using Python. Why haven't you switched to Google Go or

another language that implements unicode strings in UTF-8?

------

Everybody has the right to have an opinion. Understand
I respect Steven's opinion.

---

I'm aware of the utf-8 indexing "effect" (it is in fact the
answer I expected), that's why I proposed to dive a little
bit more in "unicode".

Now something else.
I'm practically no more programming in the sense creating
applications, but mainly interested in unicode. I "toyed" with
many tools, C#, go, ruby2 and my favorite, the TeX unicode engines.
I just happen I have a large experience with Python and I'm finding
this FSR fascinating.

jmf
 
Ad

Advertisements

C

Chris Angelico

Most languages that already have some support for Unicode have a
significant amount of legacy code to continue supporting, though. Python
has the same problem: there're still heaps of Python 2 deployments out
there, and more being installed every day, none of which do Unicode
right.

To fix Unicode support in Python, the developers and community had to
initiate – and is still working through – a long, high-effort transition
across a backward-incompatible change in order to get the community to
Python 3, which finally does Unicode right.

Yes, but Python can start that process by creating Python 3; other
languages ought to be able to do something similar. Get the process
started. It's not going to get any easier by waiting.

And, more importantly: New languages are being developed. If their
designers look at Java, they'll see "UTF-16 is fine for them, so it'll
be fine for us", but if they look at Python, they'll see "The current
version of Python does it this way, everything else is just
maintenance mode, so this is obviously the way the Python designers
feel is right". Even if 99% of running Python code is Py2, that
message is still being sent, because Python 2.8 will never exist.
Other language communities will likely have to do a similar huge effort,
or forever live with nearly-right-but-fundamentally-broken Unicode
support.

See, for example, the enormous number of ECMAScript deployments in every
user-facing browser, all with the false assumption (§2 of ECMA-262
<URL:http://www.ecma-international.org/publications/standards/Ecma-262.htm>)
that UTF-16 and Unicode are the same thing and nothing outside the BMP
exists.

And ECMAScript is near the front of the programming language pack in
terms of Unicode support — most others have far more heinous flaws that
need to be fixed by breaking backward compatibility. I wish their
communities luck.

Yeah. I'm now of the opinion that JavaScript and ECMAScript can't be
fixed ("use strict" is entirely backward compatible, but changing
string handling wouldn't be), so it's time we had a new web browser
scripting language. Really, 1996 was long enough ago that using 16-bit
characters should be considered no less wrong than 8-bit characters.
If it weren't that we don't actually need the space any time soon, I
would consider the current limit of 11141112 characters to be a
problem too; there's really no reason to restrict ourselves based on
what UTF-16 is capable of encoding any more than we should define
Unicode based on what Code Page 437 can handle.
\ “Nature hath given men one tongue but two ears, that we may |
`\ hear from others twice as much as we speak.” —Epictetus, |
_o__) _Fragments_ |

One of my brothers just got married, and someone who's friended him on
Facebook was unaware of the invitations despite being a prolific
poster. I cited the modern equivalent of the above, namely that we
have ten fingers but only two eyes, so it's acceptable to write five
times as much as we actually bother to read...

ChrisA
 
P

Pavel Volkov


Thanks for all those references.
There's this statement in the first article:

"Got a switch statement? The Python translation is a hash table, not a bunch
of if-then statments. Got a bunch of if-then's that wouldn't be a switch
statement in Java because strings are involved? It's still a hash table. "

I can't figure out how would you translate a switch statement into hash table
in general case.
 
M

Michael Torrie

Thanks for all those references.
There's this statement in the first article:

"Got a switch statement? The Python translation is a hash table, not a bunch
of if-then statments. Got a bunch of if-then's that wouldn't be a switch
statement in Java because strings are involved? It's still a hash table. "

I can't figure out how would you translate a switch statement into hash table
in general case.

The general case is an if/elif ladder. But consider:

def func1(): pass
def func2(): pass
def func3(): pass

dispatch = { 0: func1,
1: func2,
2: func3,
}

# do some calc
result = somecalc()
try:
dispatch[result]()
except KeyError:
# invalid result

That's what the article is talking about.
 
Ad

Advertisements

C

Chris Angelico

"Got a switch statement? The Python translation is a hash table, not a bunch
of if-then statments. Got a bunch of if-then's that wouldn't be a switch
statement in Java because strings are involved? It's still a hash table. "

I actually disagree. There is no Python translation for a switch
statement. What you have is two ways (if/elif and dict lookup) to
implement what in other languages is often implemented with a switch.
Often, switch is used when a dispatch table is the ideal solution; but
other times, neither if/elif nor a dispatch table will perfectly cover
what you're trying to do, and it's not right to "translate" the switch
into a dict lookup. The right thing to do is to go back to what's
actually trying to be solved, and solve that.

ChrisA
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top