python needs leaning stuff from other language

[Tim Wintle]

On Fri, 2009-04-03 at 18:27 -0500, Robert Kern wrote:
> > agreed. If .clear was to be added then really assignments to slices
> > should be entirely removed.
> 
> Please tell me you are joking.

Well I'm not joking as such.

I've noticed that python-ideas seems to be positive on the idea, and has
a patch ready for Guido, obviously I'm not that anti it that I'd always
be complaining if it is implemented, I just see it as unnecessary:
http://mail.python.org/pipermail/python-ideas/2009-April/003933.html

(I didn't expect such strong responses btw!)


you can already do:
del mylist[:]
* or *
mylist[:] = []
* or *
mylist = []


which, although semantically similar are different as far as the
interpreter are concerned (since two of them create a new list):

(Python 2.5.2 - don't have a newer version on this machine to check)
{{{
import dis
>>> def f(a):
...   del a[:]
...
>>> def g(a):
...   a[:] = []
...
>>> def h(a):
...   a = []
...
>>> dis.dis(f)
  2           0 LOAD_FAST                0 (a)
              3 DELETE_SLICE+0      
              4 LOAD_CONST               0 (None)
              7 RETURN_VALUE        
>>> dis.dis(g)
  2           0 BUILD_LIST               0
              3 LOAD_FAST                0 (a)
              6 STORE_SLICE+0       
              7 LOAD_CONST               0 (None)
             10 RETURN_VALUE        
>>> dis.dis(h)
  2           0 BUILD_LIST               0
              3 STORE_FAST               0 (a)
              6 LOAD_CONST               0 (None)
              9 RETURN_VALUE        
}}}

so it seems silly to introduce a *third* formal description of what is
(almost) semantically the same!

My knowledge of the interpreter begins to get fuzzy here, but would this
add extra overhead by the look-ups to the .clear method (really don't
have the time to compile a patched version of trunk to test!) - it might
be a constant change, but it's still a difference to what I believe is
likely to be required to be fairly high-performance when it is used.

e.g. 
{{{
>>> def f(a):
...   a.clear()
... 
>>> dis.dis(f)
  2           0 LOAD_FAST                0 (a)
              3 LOAD_ATTR                0 (clear)
              6 CALL_FUNCTION            0
              9 POP_TOP             
             10 LOAD_CONST               0 (None)
             13 RETURN_VALUE        
}}}

The current versions at least do two different things quite efficiently
- if you are clearing the list and expect the list to be small / zero
length next time, then (I believe) it's more memory efficient to try 
mylist = []

,where
del mylist[:] 

will (I'm assuming - correct me if I'm wrong) reduce the size of the
list, but using the clever list memory usage it will scale to a large
size again fairly well.

As for:
"Should we also remove .update from dict?"

Am I missing something? What is the single statement that is equivalent
to .update (although personally I don't think I have *ever* used .update
- I'm normally using a set for situations where I would require .update)


Oh, and can I have the reference for Raymond Hettinger's blessing
(mentioned in a different branch of this thread)? As far as I can see he
has only (in archives at least) replied to a question about whether it's
worth formalising the request as a PEP, and hasn't entered a vote either
way:

"""
Just ask Guido for his blessing.  The implementation is trivial.
"""
http://mail.python.org/pipermail/python-ideas/2009-April/003938.html

Ironically much of my - very limited - knowledge of the interpreter
stems from many of his talks, which were the encouragement to start
actually reading the source for the interpreter!

I'm more than willing to drop my issue if it's voted against, but it
does feel dirty to me to add extra syntax that have completely parallel
semantics. 

In general language design (not just programming languages) I personally
take any (provable) requirement for this as a _possible_ problem with
the chosen basis / semantic value function (in 1st order language
terms), although I understand that it is sometimes unavoidable in real
life.

For example, this makes me question the orthogonality of "ordered" and
"collection" with semantics dictated by their methods/features. 

Proposing that the object:
mylist[a:b:c] 

return an iterator that is non-assignable appears to fix this
non-orthogonality as far as I can immediately see (although I am *very*
tired, and haven't thought it through far enough!)


Tim Wintle