[Python-il] [pyweb-il:1072] Python coding question

Amit Aronovitch aronovitch at gmail.com
Fri Jul 9 15:31:16 IDT 2010


On Thu, Jul 8, 2010 at 12:18 AM, Shai Berger <shai at platonix.com> wrote:

> On Wednesday 07 July 2010, Amit Aronovitch wrote:
> >
> > I was not complaining about what it does.
> > Only about the choice of symbol (too many people come from Java and C).
> > Many questions on mailing lists are caused by this (Maybe <- or := would
> > have been a little better).
>
> "[p]racticality beats purity" (Tim Peters, "The Zen of Python"). Making the
> common thing (binding) use one character is IMHO a very good decision; it
> was
> good for C, and it is good for Python.
>
>
Well, the difference between one and two characters is not such a big deal.
(Well, maybe for me and you it does matter. Remember the good-ole APL days,
Shai? :-) ).
Avoiding confusion/bugs for C and Java programmers is a *practical*
consideration.

However, Python has a BDFL, so in this case your choice is the *right* one,
and mine is wrong of course.

 > Introducing += made the problem even worse. For example, too many people
> are
> > trying to find magic-methods to overload 'the operator =', when in fact
> it
> > has nothing to do with the object on the RHS (only manipulates the local
> > namespace).
>
> It is not people coming from C or Java (both of which lack operator
> overloading) who bring these issues up.


True. Bad example (C++ to blame for that specific question. Examples in the
wiki are more relevant).

And += is another one of those
> brilliant contributions of C, making the common case simpler and increasing
> readability. I wouldn't like the trade-off where you "win" a couple of
> questions on mailing-lists and pay for it with the DRY in
>

complex_or_just_long_reference = complex_or_just_long_reference + 1
>
>
(My complaints about += discussed last night)


---> [Quoting Rani Hod]

> >
> > But wouldn't you prefer something like
> >   complex_or_just_long_reference = same + 1
> > which turns out to be more powerful than the standard pack of syntactic
> > sugar constructs:
> >   complex_or_just_long_reference = max(same, new_thing)
> > or
> >   complex_or_just_long_reference = "(" + same + ")"
> > IMHO, this is more readable and saves most of the mess with long names.
> >
>
<---

> This is an interesting idea -- I agree that it has merits, but I also see
> why
> it wouldn't be included in a language where 'self' is a convention and not
> a
> keyword.
>
>
Maybe a graphical character ('$', '@', ...) could be used instead of a
keyword?
The idea seems like an inline version of the interactive interpreter's "_"
variable (last output), so maybe "__" would be a good option for that
keyword (however, "__" is used by ipython for something else).


> > We have created a list of functions, each supposedly defined over a
> >
> > > different
> > > value of i. Each is a separate object, because in principle the
> closures
> > > are
> > > different. If i were really nothing but a name that gets re-bound in
> > > every loop iteration, we would expect, for any j in 0..4, to have
> > > funcs[j]()==j...
> > >
> > > >>> funcs[1]()
> > >
> > > 4
> > >
> > > ...but in fact, they all return the last value; the closure references
> a
> > > variable, not a name.
> >
>

 --->[AA: Quoting Rani]

> > Cannot see how what you say here contradicts the explanation on the Wiki.
> > This only shows that the resolution of the name "i" happens on function
> > execution rather than on function definition, which is the expected
> > behavior for agile languages.
>
<---

> Indeed, the example I gave was not exactly supporting my claim. It did show
> a
> place where a name behaves like a variable reference, but as you correctly
> argue, the behavior can be explained by late binding.
>
> However, if that were the whole story, this code would raise a NameError:
>
> >>> def f():
> ...     i=5
> ...     def g(): return i
> ...     del i
> ...     return g
> ...
> >>> f()()
>
> In fact, the deletion of i in f is a syntax error, complaining about
> deletion
> of a variable. This is done because "If a name binding operation occurs
> anywhere within a code block, all uses of the name within the block are
> treated as references to the current block"
> (http://docs.python.org/reference/executionmodel.html) -- that is, while
> the
> exact object bound to the name is looked up as late as possible, the scope
> of
> the name is set already at function definition (compilation) time.
>
> Thus, the nested function will only look for the current binding of i in
> the
> local namespace of its containing function; IMHO, this qualifies as a true
> variable (though, true, it is not a constant place in memory).
>
>
Note that the "i" here:

>>> def f1():
...     i=5

is a different creature than the "i" here

>>> def f2():
...     i=5
...     def g(): return i

They generate different bytecode (STORE_FAST in the first case, STORE_DEREF
in the second one).

The first kind of name might not qualify as a variable even by your
definition.
The second kind of name (cell variables/free variables) was introduced in
Python2.2 in order to implement nested scopes efficiently
http://www.python.org/dev/peps/pep-0227/
so my statement about "no variables in python" was probably true when I
first conceived it (though I think cell variables already did exist when I
wrote it down in the wiki).

I hope this is still interesting to people here,
>
>
Probably most of them are just ignoring this. But just to make sure, I'll
shut up unless they ask for more :-)

      AA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://hamakor.org.il/pipermail/python-il/attachments/20100709/096e39cd/attachment.htm 


More information about the Python-il mailing list