RE: Comments requested: brief summary of Python

Discussion in 'Python' started by Brian Quinlan, Feb 24, 2004.

  1. > For a book I am working on, I have written a brief (9 page) summary
    > of Python. The intent of this is that an experienced programmer who
    > did not know Python would be able to get enough information to read and
    > understand Python programs. It is not meant to be a 100% complete
    > summary of the language, but everything in there should be correct.


    ! Python is an interpreted language.

    Nope. Python is a language. The C implementation of which behaves similarly
    to your description of Java i.e. Python scripts are compiled into an
    intermediate format, known as bytecode, and then run through an bytecode
    interpreter.

    ! Statements in Python are terminated by a newline

    Or semicolon

    ! Python figures out which type a variable should be the first time it
    ! is used.

    No. In Python the concept of a variable is completely divorced from the
    concept of type. A type is NEVER associated with a variable so no figuring
    out is needed.

    | i = "Hello"
    | will make i a string.

    Same. i is a variable, not a string.

    | However, once the type of a variable is declared, it keeps that type; if
    | you declare: i = "5"

    Wrong for same reason, but this suggests that:

    i = "5"
    i = 10
    i = lambda x: x * 2

    wouldn't work. But it will.

    > Multiple variables can be assigned at once, as in two, three = 2, 3


    This should not be discussed here as it is not a new concept. This is just
    sequence unpacking and works with any sequence type.

    ! Multi-line strings are often included in Python code without being
    ! assigned to anything (which means they have no semantic relevance): it's a
    ! way to include multi-line comments in the code.

    They do have semantic significance if they start at the beginning of a
    module, function or method; they get assign to that object's __doc__
    attribute.

    These specific errors aside, I think that there is an overall tone problem
    with this description. I can't really qualify it but maybe the problem is
    that you are comparing Python to a statically-typed language throughout.
    Maybe you should make the first part more conceptual if you are targeting C
    programmers and worry about syntax in the last couple of pages?

    Cheers,
    Brian
    Brian Quinlan, Feb 24, 2004
    #1
    1. Advertising

  2. In article <>,
    Brian Quinlan <> wrote:
    .
    .
    .
    >! Python figures out which type a variable should be the first time it
    >! is used.
    >
    >No. In Python the concept of a variable is completely divorced from the
    >concept of type. A type is NEVER associated with a variable so no figuring
    >out is needed.
    >
    >| i = "Hello"
    >| will make i a string.
    >
    >Same. i is a variable, not a string.

    .
    [other errors noted and
    astutely corrected]
    .
    .
    The approach I like is to discard any language that
    encourages newcomers to regard
    i = "Hello"
    as an "assignment", and to identify it instead as
    what it is for Python: a *binding* to the name
    'i'.
    --

    Cameron Laird <>
    Business: http://www.Phaseit.net
    Cameron Laird, Feb 24, 2004
    #2
    1. Advertising

  3. Brian Quinlan

    Peter Hansen Guest

    Transitivity and direction of "binding" (was Re: Comments requested:brief summary of Python)

    Cameron Laird wrote:
    >
    > The approach I like is to discard any language that
    > encourages newcomers to regard
    > i = "Hello"
    > as an "assignment", and to identify it instead as
    > what it is for Python: a *binding* to the name 'i'.


    Is it "binding the object to the name", or is it "binding the name
    to the object".

    Or both?

    Or neither?

    Why?

    And does it matter? ;-)

    (Seriously though...)

    -Peter
    Peter Hansen, Feb 24, 2004
    #3
  4. Re: Transitivity and direction of "binding" (was Re: Comments requested: brief summary of Python)

    Peter Hansen <> wrote:

    >Is it "binding the object to the name", or is it "binding the name
    >to the object".
    >
    >Or both?
    >
    >Or neither?
    >
    >Why?
    >
    >And does it matter? ;-)
    >
    >(Seriously though...)


    IMHO this depends on whether one sees the set of currently unnamed
    Python objects as existing in some form or another inside the garbage
    collection namespace or as residing in a space of unbroken symmetries
    where they can be lifted out of by describing their shape.

    In the first case objects have a kind of Platonic existence even
    *before* they are bound to a name, and the name binding process just
    provides us with a reference to this object. For example if there is
    an object with name 'a' and value 1 then the operation of adding 1 to
    this name is not changing the value of the Platonic object 1 into 2
    but instead the name 'a' is now bound to *another* unchangeable
    Platonic object, in this case the object with value 2.

    This is confusing C-programmers endlessly since they are expecting to
    change the value of some memory location while having the name 'a'
    point to this same location invariably, until explicit instructions
    change that.

    In the second case where Python objects are seen as "created" by
    carving them out of the undefined background space of the universe
    there is even more room for confusion.

    The Python interpreter cannot execute magic or create information out
    of raw quantum uncertainties because it has to operate within a
    limited memory and computing environment. So it just stamps out
    objects according to some template, fooling us into thinking that the
    objects could have every conceivable shape, while in fact there are
    serious limitations.

    Next it tries to hide that fact instantly and acts as if everything is
    all right and we live in the nice and overseeable Platonic universe
    that was described before.

    So, well, yes, it does matter, but not here but for example in
    newsgroups as comp.ai.philosophy where subjects like mental
    representations -finding the cells in your brain that code for your
    grandmother- are much more current than here on comp.lang.python.

    The chance of finding the actual representation of an object inside
    the Python interpreters' underlying hardware is much better than
    solving the comp.ai.philosophy problems because of the less flexible
    stamping mechanism the interpreter uses compared to humans.

    That may well change in the future however and we might have to deal
    with the same humunculi as the philosophers have to concern themselves
    with. Until then we assume that we live in a Platonic universe and can
    use unit testing to scare the occasional hidden bug out of our code,
    fully aware that it's our computer that really runs the interpreter,
    but it will let us tinker for just a few more moments ...

    Anton
    Anton Vredegoor, Feb 24, 2004
    #4
  5. Re: Transitivity and direction of "binding" (was Re: Comments

    Peter Hansen <> writes:

    > Cameron Laird wrote:
    > >
    > > The approach I like is to discard any language that
    > > encourages newcomers to regard
    > > i = "Hello"
    > > as an "assignment", and to identify it instead as
    > > what it is for Python: a *binding* to the name 'i'.

    >
    > Is it "binding the object to the name", or is it "binding the name
    > to the object".


    I'd say it's "binding the name to the object".

    > Or both?


    No.

    > Or neither?


    No.

    > Why?


    A name has zero or one bindings, but an object may have an arbitrary
    number of bindings to it.

    > And does it matter? ;-)


    Not a lot.

    Cheers,
    mwh

    --
    The PROPER way to handle HTML postings is to cancel the article,
    then hire a hitman to kill the poster, his wife and kids, and ****
    his dog and smash his computer into little bits. Anything more is
    just extremism. -- Paul Tomblin, asr
    Michael Hudson, Feb 25, 2004
    #5
  6. Re: Transitivity and direction of "binding" (was Re: Comments

    Michael Hudson <> writes:

    > > Why?

    >
    > A name has zero or one bindings, but an object may have an arbitrary
    > number of bindings to it.
    >


    Additionally if you run the function 'def t(): a+=1' you get an
    UnboundLocalError, indicating that the local name "a" is not bound to
    any object.

    So there you have it, definitive proof from the interpreter itself.
    <.9 wink>

    --
    Christopher A. Craig <>
    Perl is like Vice Grips; You can do anything with it but it is the wrong tool
    for every job. -- Bruce Eckel
    Christopher A. Craig, Feb 25, 2004
    #6
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Adam Barr
    Replies:
    1
    Views:
    501
  2. Adam Barr
    Replies:
    6
    Views:
    399
    Adam Barr
    Feb 27, 2004
  3. Adam Barr

    Comments requested: brief summary of C

    Adam Barr, Feb 24, 2004, in forum: C Programming
    Replies:
    22
    Views:
    703
    Nils Petter Vaskinn
    Mar 1, 2004
  4. Adam Barr
    Replies:
    9
    Views:
    317
    Adam Barr
    Feb 25, 2004
  5. Adam Barr
    Replies:
    23
    Views:
    299
    Michele Dondi
    Feb 28, 2004
Loading...

Share This Page