FAQ
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

Search Discussions

  • Steven D'Aprano at Nov 23, 2013 at 2:01 am

    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
  • Wxjmfauth at Nov 25, 2013 at 10:12 am

    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
  • Mark Lawrence at Nov 25, 2013 at 1:33 pm

    On 25/11/2013 10:12, wxjmfauth at 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
  • Michael Torrie at Nov 25, 2013 at 3:11 pm
    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 at 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?
  • Chris Angelico at Nov 25, 2013 at 3:38 pm

    On Tue, Nov 26, 2013 at 2:11 AM, Michael Torrie 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
  • Ben Finney at Nov 25, 2013 at 11:35 pm

    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
  • Chris Angelico at Nov 26, 2013 at 12:09 am

    On Tue, Nov 26, 2013 at 10:35 AM, Ben Finney 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
  • Wxjmfauth at Nov 25, 2013 at 4:17 pm

    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 at 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
  • Pavel Volkov at Nov 27, 2013 at 6:05 pm

    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.
  • Michael Torrie at Nov 27, 2013 at 6:15 pm

    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.
  • Jean-Michel Pichavant at Nov 27, 2013 at 6:16 pm

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

    It actually refers to python dictionaries, they use hash-able object as keys:


    switch (foo):
       1: do_something()
       2: do_someotherthing()


    can be written in python that way:


    {
       1: do_something,
       2: do_someotherthing,
    }[foo]()


    There are some limitation though, without going into details.


    JM




    -- IMPORTANT NOTICE:


    The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
  • Chris Angelico at Nov 27, 2013 at 11:11 pm

    On Thu, Nov 28, 2013 at 5:05 AM, Pavel Volkov 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
  • Ned Batchelder at Nov 23, 2013 at 2:32 am

    On Friday, November 22, 2013 6:59:19 PM UTC-5, koch... at 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.
  • Dan Stromberg at Nov 23, 2013 at 6:28 am
    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, 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
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/python-list/attachments/20131122/51f562dc/attachment.html>
  • Dan Stromberg at Nov 23, 2013 at 6:36 am
    I almost forgot: Talk about pypi and pip (or similar) too.

    On Fri, Nov 22, 2013 at 3:59 PM, 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
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/python-list/attachments/20131122/eafee047/attachment.html>
  • Chris Angelico at Nov 23, 2013 at 7:25 am

    On Sat, Nov 23, 2013 at 5:28 PM, Dan Stromberg 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
  • Koch Mate at Nov 24, 2013 at 12:54 am
    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppython-list @
categoriespython
postedNov 22, '13 at 11:59p
activeNov 27, '13 at 11:11p
posts18
users11
websitepython.org

People

Translate

site design / logo © 2022 Grokbase