python needs leaning stuff from other language

[MRAB]

I think it would also be better to have One (and prefereably Only One)
Obvious Way To Do It. That obvious way, for those who work with
Python's ‘set’ and ‘dict’, is a ‘clear’ method. It seems best to have
‘list’ conform with this also.
Does that mean a one-off special case rule to forbid slices having a
default?
Why would it do that?

Well, if list.clear were truly and strictly to be the only way to clear the
contents of a list, then assigning nothing via the default slice would have
to be ruled out. `somelist[:] = []` is just a special case of assignment to
a slice generally.

agreed. If .clear was to be added then really assignments to slices
should be entirely removed.

Should we also remove .update from dict?

I see no problem in collections having a .clear method. Saying that "if
c is a collection then c.clear() clears that collection" seems to be a
very duck-typy(?) thing to me.

Assignments to slices is just a feature of ordered collections (well,
lists), and clearing a list by assigning an empty list is just a special
case of that.

 

[Robert Kern]

I think it would also be better to have One (and prefereably Only One)
Obvious Way To Do It. That obvious way, for those who work with
Python's ‘set’ and ‘dict’, is a ‘clear’ method. It seems best to have
‘list’ conform with this also.
Does that mean a one-off special case rule to forbid slices having a
default?
Why would it do that?

Well, if list.clear were truly and strictly to be the only way to clear the
contents of a list, then assigning nothing via the default slice would have
to be ruled out. `somelist[:] = []` is just a special case of assignment to
a slice generally.

agreed. If .clear was to be added then really assignments to slices
should be entirely removed.

Please tell me you are joking.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

 

[Steven D'Aprano]

I think it would also be better to have One (and prefereably Only
One) Obvious Way To Do It. That obvious way, for those who work
with Python's ‘set’ and ‘dict’, is a ‘clear’ method. It seems best
to have ‘list’ conform with this also.

Does that mean a one-off special case rule to forbid slices having a
default?

Why would it do that?

Well, if list.clear were truly and strictly to be the only way to clear
the contents of a list, then assigning nothing via the default slice
would have to be ruled out. `somelist[:] = []` is just a special case
of assignment to a slice generally.

agreed. If .clear was to be added then really assignments to slices
should be entirely removed.

That's total nonsense. Where do people get this ridiculous urban legend
that there is "only one way to do it" in Python?

The Zen says:

"There should be one-- and preferably only one --obvious way to do it."

does not mean "only one way to do it". It is a *prescription* that there
SHOULD be one OBVIOUS way to do a task, not a prohibition on more than
one way to do a task.

Such a prohibition would be stupid *and* impossible to enforce:

# Four ways to remove trailing spaces from a string. There are others.

s.rstrip(" ") # the one obvious way


while s.endswith(" "):
s = s[:-1]


while True:
if s[-1] == ' ':
s = s[0:-1]
else:
break


L = []
trailing_spaces = True
for c in reversed(s):
if c == ' ' and trailing_spaces:
continue
trailing_spaces = False
L.append(c)
L.reverse()
s = ''.join(L)

 

[Giampaolo Rodola']

If "there should be one-- and preferably only one --obvious way to do
it" then my_list.clear() is more obvious than del my_list[:].
Honestly I'm a little surprised that such a topic hasn't been raised
before.


--- Giampaolo
http://code.google.com/p/pyftpdlib

 

[Steven D'Aprano]

If "there should be one-- and preferably only one --obvious way to do
it" then my_list.clear() is more obvious than del my_list[:]. Honestly
I'm a little surprised that such a topic hasn't been raised before.

I'm a little surprised that you didn't bother googling before making that
statement. Of course it has been raised before. See (for example) these
threads:

http://mail.python.org/pipermail/python-dev/2005-July/054564.html

http://mail.python.org/pipermail/python-list/2006-April/549278.html

http://mail.python.org/pipermail/python-list/2006-May/556977.html

http://mail.python.org/pipermail/python-ideas/2007-May/000692.html


The good news is that Python-Ideas seems to be receptive to the idea,
including some heavy-weights like Raymond Hettinger, which leads me to be
hopeful that Python-Dev and Guido himself will agree:

http://mail.python.org/pipermail/python-ideas/2009-April/003897.html


Keep your fingers crossed that this is the last time we need to have this
discussion!

 

[Tim Wintle]

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.... del a[:]
........ a[:] = []
........ a = []
.... 2 0 LOAD_FAST 0 (a)
3 DELETE_SLICE+0
4 LOAD_CONST 0 (None)
7 RETURN_VALUE 2 0 BUILD_LIST 0
3 LOAD_FAST 0 (a)
6 STORE_SLICE+0
7 LOAD_CONST 0 (None)
10 RETURN_VALUE 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.
{{{.... a.clear()
.... 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

 

[Robert Kern]

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

Let's be clear: python-ideas seems positive on the idea of adding a .clear()
method. *Completely removing* slice assignment has not been broached there.

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

You are proposing the removal of a general, orthogonal feature (and breaking
code in consequence!) just because of a new syntax for a single special case of
that feature. That is quite simply ridiculous.

..clear() would be non-orthogonal syntactic sugar. That's okay! Python has
syntactic sugar in a number of other places, too! Appropriate doses of syntactic
sugar and non-orthogonality are precisely what lets you implement "There should
be one-- and preferably only one --obvious way to do it." The really key word in
that sentence is "obvious", not "one".

FWIW, removing slice assignment would be a gross form of non-orthogonality, too.
__getitem__, __setitem__ and __delitem__ should all be able to accept the same
indices (or else raise exceptions in the case of immutability).

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

 

[Giampaolo Rodola']

If "there should be one-- and preferably only one --obvious way to do
it" then my_list.clear() is more obvious than del my_list[:]. Honestly
I'm a little surprised that such a topic hasn't been raised before.

I'm a little surprised that you didn't bother googling before making that
statement. Of course it has been raised before. See (for example) these
threads:

http://mail.python.org/pipermail/python-dev/2005-July/054564.html

http://mail.python.org/pipermail/python-list/2006-April/549278.html

http://mail.python.org/pipermail/python-list/2006-May/556977.html

http://mail.python.org/pipermail/python-ideas/2007-May/000692.html

The good news is that Python-Ideas seems to be receptive to the idea,
including some heavy-weights like Raymond Hettinger, which leads me to be
hopeful that Python-Dev and Guido himself will agree:

http://mail.python.org/pipermail/python-ideas/2009-April/003897.html

Keep your fingers crossed that this is the last time we need to have this
discussion!

Sorry, it was 3:52 AM, that's why I didn't bother. =)


--- Giampaolo
http://code.google.com/p/pyftpdlib

 

[Paul McGuire]

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):

Only the last item creates a new list of any consequence. The first
two retain the original list and delete or discard the items in it. A
temporary list gets created in the 2nd option, and is then used to
assign new contents to mylist's [:] slice - so yes, technically, a new
list *is* created in the case of this option. But mylist does not get
bound to it as in the 3rd case. In case 2, mylist's binding is
unchanged, and the temporary list gets GC'ed almost immediately.

-- Paul

 

[Zamnedix]

The original poster may or may not know what he is talking about, but
adding a clear() method to lists seems to be very much in demand. I'd
vote Yes for one.

Besides, this news group is for people to ask questions about Python,
even stupid questions. It's not just for experts only.

Sorry. It was inappropriate. I just get a little mad at people who
don't even ATTEMPT to speak proper English. And then they go on
bashing our language without any sort of context.

 

[Tim Wintle]

Let's be clear: python-ideas seems positive on the idea of adding a .clear()
method. *Completely removing* slice assignment has not been broached there.

Yup, sorry - I did mean to refer to the initial suggestion, rather than
my comments

You are proposing the removal of a general, orthogonal feature (and breaking
code in consequence!) just because of a new syntax for a single special case of
that feature. That is quite simply ridiculous.

Ok, I may have come across a little strongly (was very tired) - I'm not
_actually_ saying we should remove it, I'm just pointing out why
adding .clear() to lists seems to be unnecessary and slightly messy. The
suggested removal of assignments to slices is a theoretical statement.

.clear() would be non-orthogonal syntactic sugar. That's okay! Python has
syntactic sugar in a number of other places, too! Appropriate doses of syntactic
sugar and non-orthogonality are precisely what lets you implement "There should
be one-- and preferably only one --obvious way to do it." The really key word in
that sentence is "obvious", not "one".

FWIW, removing slice assignment would be a gross form of non-orthogonality, too.
__getitem__, __setitem__ and __delitem__ should all be able to accept the same
indices (or else raise exceptions in the case of immutability).

hummm - I'm sure it would be confusing behaviour if it was not
available, but I'm not sure how it would be non-orthogonal

 

[Diez B. Roggisch]

Let's be clear: python-ideas seems positive on the idea of adding a .clear()
method. *Completely removing* slice assignment has not been broached there.

Yup, sorry - I did mean to refer to the initial suggestion, rather than
my comments

You are proposing the removal of a general, orthogonal feature (and breaking
code in consequence!) just because of a new syntax for a single special case of
that feature. That is quite simply ridiculous.

Ok, I may have come across a little strongly (was very tired) - I'm not
_actually_ saying we should remove it, I'm just pointing out why
adding .clear() to lists seems to be unnecessary and slightly messy. The
suggested removal of assignments to slices is a theoretical statement.

.clear() would be non-orthogonal syntactic sugar. That's okay! Python has
syntactic sugar in a number of other places, too! Appropriate doses of syntactic
sugar and non-orthogonality are precisely what lets you implement "There should
be one-- and preferably only one --obvious way to do it." The really key word in
that sentence is "obvious", not "one".

FWIW, removing slice assignment would be a gross form of non-orthogonality, too.
__getitem__, __setitem__ and __delitem__ should all be able to accept the same
indices (or else raise exceptions in the case of immutability).

hummm - I'm sure it would be confusing behaviour if it was not
available, but I'm not sure how it would be non-orthogonal

>>> l = range(10)
>>> l[3:7] = range(4)
>>> l

[0, 1, 2, 0, 1, 2, 3, 7, 8, 9]

How do you want to do that with clear?

That l[:] = [] clears a list is more of an "accident" than the intent of
slice-assignment. Removing it in favor of clear() would remove an
orthogonal feature of updating parts of a list with another iterable.

Diez

 

[Robert Kern]

Yup, sorry - I did mean to refer to the initial suggestion, rather than
my comments


Ok, I may have come across a little strongly (was very tired) - I'm not
_actually_ saying we should remove it, I'm just pointing out why
adding .clear() to lists seems to be unnecessary and slightly messy. The
suggested removal of assignments to slices is a theoretical statement.

But can you see why your wording might lead the rest of us to believe otherwise?

hummm - I'm sure it would be confusing behaviour if it was not
available, but I'm not sure how it would be non-orthogonal

I might be abusing the term, but to me, orthogonality doesn't just mean avoiding
overlapping functionality. It also means not putting in special-case limitations
for otherwise general features. It would be odd if you could use integer indices
for __getitem__, __setitem__ and __delitem__, but slice indices would work for
__getitem__ and not the others.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

 

[Tim Wintle]

But can you see why your wording might lead the rest of us to believe otherwise?

Yes I do - sorry, I tend to check mailing lists at the end of the day
when I am quite tired.

I think I could argue 'till the cows come home about why adding .clear
feels messy to me, bu as it's not my decision in the slightest, I think
I will end this thread here

Tim