A bundle of questions from a Python newbie

[Carel Fellinger]

Gonçalo Rodrigues <op73418 at mail.telepac.pt> wrote:
...nice introduction snipped

Welcome aboard.  Le'me start with complimenting you with your
questions.  They show a keen understanding of programming and Python
in particular not often find with people claiming not to do much
programming.  That will make anwsering them much easier:)
I'll anwser the easy ones.

> 1. The way I thought that an assignment like

> var += 1 

> worked was that the interpreter would go to the place pointed by var and
> add 1. In particular, id(var) should remain constant. But this is not
> what happens as a simple test shows it. So what is wrong in my
> perception of what += does? Is this an implemetation issue?

var is indeed `pointing to' something, but that something here isn't
something that can increment itself.  It's a number, and numbers are
immutable objects in Python.

In general augmented assignment works like:

   var <operator>= <expression>   <==>  var = var <operator> <expression>

but for those var's that have redefined that augmented assignment operator
like in:

   class AA:
	def __init__(self, value):  self.value = value
        def __iadd__(self, value):  self.value += value; return self

   a = AA(1);   b = a;   a += 2
   assert a.value == 3  and a is b


> 2. What is the idea of having in the loop

> for var in range(10):
>     pass

> the var variable still available after it? Wasn't it supposed to die (as
> in being out of scope) when the loop ends? And is this a feature, or
> something that we should not count on? Somehow, I believe that the a new
> var should be created when the loop starts and then destroyed when it
> ends avoiding any variable shadowing along the way.

In python the for statement doesn't start a new scope. This comes in
handy when e.g. searching a list, like:

    for line in lines:
	if line.startswith("spam"): break
    # now line is thee first line in lines that starts with "spam".

> 3. This is not a question just a small complaint. I really miss the
> do-until control flow in Python. I always have to waste some extra brain
> cycles to convert it to the while 1, etc. idiom. Hey, we all have a
> right to our complaints, right? ;-)

do-until is not my favorit, but I do miss the more generic
loop-and-a-half construct:)


> 6. Is there a reason why 3.__abs__() does not work? After all 3 is an
> object (in the wider sense of the word). And it does work if we assign
> it to a variable, eg, 

> var = 3
> var.__abs__()

> I know that code like the above (methods applied to number literals) is
> probably rare, but consistence is also a good thing.

It's a parser thing.  `3.' would be parsed as a real.


> 9. What would be better in terms of speed?

> for i in range(<whatever>):
>     <whatever> 

> Or to code an iterator like

time it:)


> 10. I have a class that works like a list in the sense that supports the
> method __getitem__ and its relatives. But I'm at a loss as to what I
> have to do to support the slice notation.

In the __getitem__ method check whether tha argument passed is a slice
object and act accordingly.

> 11. Generators seem to be a very powerful concept. Still,

> a. Why can't a return statement have an expression?

It's deemed wise to make a clear distinction between `yielding' and stopping.

> b. Is there any way to "reset" a generator, e.g. upon a subsequent call
> it starts as if it is being called for the first time?

Not straightforward, but one could concieve a generator that after
each yield checks for some `global' flag whether it should start
afresh. like:

   class ResettableGenerator:
       def gen(self, N):
          self.again = 0
          while 1:
             for n in range(N):
                 yield n
                 if self.again:
                    break
             if not self.again:
                break

> 12. This is not exactly about Python, but about programming in general.
> I keep reading about continuations and coroutines and I would like to
> know, in simple terms if possible, what the heck are they and in what
> ways they differ from generators as they exist in Python.

Continuations give you the possibility to save all/most of a program
state go on whith the program and later on resume from the saved state.

Coroutines give you a form of pseudo parallellism, they are capable
of passing control over to an other coroutine and resume where they
left once control is passed back to them again.  When control is
passed over it's possible to pass/receive information from/to the
other coroutine.
-- 
groetjes, carel