Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #60254 > unrolled thread

python for everyday tasks

Back to article view | Back to comp.lang.python

Contents

  python for everyday tasks koch.mate@gmail.com - 2013-11-22 15:59 -0800
    Re: python for everyday tasks Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-11-23 02:01 +0000
      Re: python for everyday tasks wxjmfauth@gmail.com - 2013-11-25 02:12 -0800
        Re: python for everyday tasks Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-11-25 13:33 +0000
        Re: python for everyday tasks Michael Torrie <torriem@gmail.com> - 2013-11-25 08:11 -0700
          Re: python for everyday tasks wxjmfauth@gmail.com - 2013-11-25 08:17 -0800
        Re: python for everyday tasks Chris Angelico <rosuav@gmail.com> - 2013-11-26 02:38 +1100
        Re: python for everyday tasks Ben Finney <ben+python@benfinney.id.au> - 2013-11-26 10:35 +1100
        Re: python for everyday tasks Chris Angelico <rosuav@gmail.com> - 2013-11-26 11:09 +1100
      Re: python for everyday tasks Pavel Volkov <negaipub@gmail.com> - 2013-11-27 22:05 +0400
      Re: python for everyday tasks Michael Torrie <torriem@gmail.com> - 2013-11-27 11:15 -0700
      Re: python for everyday tasks Chris Angelico <rosuav@gmail.com> - 2013-11-28 10:11 +1100
    Re: python for everyday tasks Ned Batchelder <ned@nedbatchelder.com> - 2013-11-22 18:32 -0800
    Re: python for everyday tasks Dan Stromberg <drsalists@gmail.com> - 2013-11-22 22:28 -0800
    Re: python for everyday tasks Dan Stromberg <drsalists@gmail.com> - 2013-11-22 22:36 -0800
    Re: python for everyday tasks Chris Angelico <rosuav@gmail.com> - 2013-11-23 18:25 +1100
      Re: python for everyday tasks koch.mate@gmail.com - 2013-11-23 16:54 -0800

#60254 — python for everyday tasks

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

[toc] | [next] | [standalone]

#60263

On Fri, 22 Nov 2013 15:59:19 -0800, koch.mate wrote:

> 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. 


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#60406

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

[toc] | [prev] | [next] | [standalone]

#60416

On 25/11/2013 10:12, wxjmfauth@gmail.com wrote:
> 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
>

Yet more double spaced crap.

-- 
Python is the second best programming language in the world.
But the best has yet to be invented.  Christian Tismer

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#60427

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 11/25/2013 03:12 AM, wxjmfauth@gmail.com wrote:
> 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?

[toc] | [prev] | [next] | [standalone]

#60432

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 11/25/2013 03:12 AM, wxjmfauth@gmail.com wrote:
> 
> > 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?

------

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

[toc] | [prev] | [next] | [standalone]

#60429

On Tue, Nov 26, 2013 at 2:11 AM, Michael Torrie <torriem@gmail.com> wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#60467

Chris Angelico <rosuav@gmail.com> writes:

> (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.)

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.

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.

-- 
 \         “Nature hath given men one tongue but two ears, that we may |
  `\          hear from others twice as much as we speak.” —Epictetus, |
_o__)                                                      _Fragments_ |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#60473

On Tue, Nov 26, 2013 at 10:35 AM, Ben Finney <ben+python@benfinney.id.au> wrote:
> Chris Angelico <rosuav@gmail.com> writes:
>
>> (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.)
>
> 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

[toc] | [prev] | [next] | [standalone]

#60626

On Saturday 23 November 2013 02:01:26 Steven D'Aprano wrote:
> * 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

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.

[toc] | [prev] | [next] | [standalone]

#60628

On 11/27/2013 11:05 AM, Pavel Volkov wrote:
> 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.

[toc] | [prev] | [next] | [standalone]

#60647

On Thu, Nov 28, 2013 at 5:05 AM, Pavel Volkov <negaipub@gmail.com> wrote:
> "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

[toc] | [prev] | [next] | [standalone]

#60269

On Friday, November 22, 2013 6:59:19 PM UTC-5, koch...@gmail.com wrote:
> 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.

[toc] | [prev] | [next] | [standalone]

#60275

[Multipart message — attachments visible in raw view] — view raw

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



On Fri, Nov 22, 2013 at 3:59 PM, <koch.mate@gmail.com> wrote:

> 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
> --
> https://mail.python.org/mailman/listinfo/python-list
>

[toc] | [prev] | [next] | [standalone]

#60277

[Multipart message — attachments visible in raw view] — view raw

I almost forgot: Talk about pypi and pip (or similar) too.

On Fri, Nov 22, 2013 at 3:59 PM, <koch.mate@gmail.com> wrote:
>
>> 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
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
>
>

[toc] | [prev] | [next] | [standalone]

#60279

On Sat, Nov 23, 2013 at 5:28 PM, Dan Stromberg <drsalists@gmail.com> wrote:
> Teach that python has builtins, not keywords - IOW, you can redefine list or
> int, but you probably shouldn't.  pylint helps with this.

Well, Python has keywords, but uses builtins for many things that
other languages use keywords (or magic) for.

>>> None=1
SyntaxError: assignment to keyword
>>> list=[]
>>> del list

ChrisA

[toc] | [prev] | [next] | [standalone]

#60344

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web