Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > python needs leaning stuff from other language

Reply
Thread Tools

python needs leaning stuff from other language

 
 
MRAB
Guest
Posts: n/a
 
      04-03-2009
Tim Wintle wrote:
> On Fri, 2009-04-03 at 13:12 -0400, Mel wrote:
>>>>> 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.
 
Reply With Quote
 
 
 
 
Robert Kern
Guest
Posts: n/a
 
      04-03-2009
On 2009-04-03 16:42, Tim Wintle wrote:
> On Fri, 2009-04-03 at 13:12 -0400, Mel wrote:
>>>>> 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

 
Reply With Quote
 
 
 
 
Steven D'Aprano
Guest
Posts: n/a
 
      04-04-2009
On Fri, 03 Apr 2009 22:42:33 +0100, Tim Wintle wrote:

> On Fri, 2009-04-03 at 13:12 -0400, Mel wrote:
>> >>> 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)



--
Steven
 
Reply With Quote
 
Giampaolo Rodola'
Guest
Posts: n/a
 
      04-04-2009
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
 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      04-04-2009
On Fri, 03 Apr 2009 18:52:52 -0700, Giampaolo Rodola' wrote:

> 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/pyt...ly/054564.html

http://mail.python.org/pipermail/pyt...il/549278.html

http://mail.python.org/pipermail/pyt...ay/556977.html

http://mail.python.org/pipermail/pyt...ay/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/pyt...il/003897.html


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


--
Steven
 
Reply With Quote
 
Tim Wintle
Guest
Posts: n/a
 
      04-04-2009
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/pyt...il/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/pyt...il/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



 
Reply With Quote
 
Robert Kern
Guest
Posts: n/a
 
      04-04-2009
On 2009-04-03 23:48, Tim Wintle wrote:
> 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/pyt...il/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

 
Reply With Quote
 
Giampaolo Rodola'
Guest
Posts: n/a
 
      04-04-2009
On 4 Apr, 04:19, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.au> wrote:
> On Fri, 03 Apr 2009 18:52:52 -0700, Giampaolo Rodola' wrote:
> > 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/pyt...ly/054564.html
>
> http://mail.python.org/pipermail/pyt...il/549278.html
>
> http://mail.python.org/pipermail/pyt...ay/556977.html
>
> http://mail.python.org/pipermail/pyt...ay/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/pyt...il/003897.html
>
> Keep your fingers crossed that this is the last time we need to have this
> discussion!
>
> --
> Steven


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


--- Giampaolo
http://code.google.com/p/pyftpdlib
 
Reply With Quote
 
Paul McGuire
Guest
Posts: n/a
 
      04-04-2009
On Apr 3, 11:48*pm, Tim Wintle <(E-Mail Removed)> wrote:
> 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
 
Reply With Quote
 
Zamnedix
Guest
Posts: n/a
 
      04-04-2009
On Apr 3, 8:48*am, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.au> wrote:
> On Fri, 03 Apr 2009 08:23:22 -0700, Zamnedix wrote:
> > On Apr 2, 3:25 pm, (E-Mail Removed) wrote:
> >> python's list needs a thing *list.clear() *like c# arraylist and
> >> python needs a writeline() method

>
> > Please don't post things like list before you do any research. You don't
> > know what you are talking about.

>
> 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.
>
> --
> Steven


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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Left leaning red black trees Antoninus Twink C Programming 10 12-03-2009 01:31 PM
Leaning out Vista 64 a little? Don Windows 64bit 5 02-24-2008 11:18 PM
Is there any provisions for leaning difficulties in the mcse exams =?Utf-8?B?ZW5ncmhhcnY=?= Microsoft Certification 1 04-14-2005 10:02 AM
Long trip - Leaning towards Coolpix 8800 - PLEASE ADVISE! ggal Digital Photography 3 03-28-2005 11:26 PM
MONA LISA AND THE LEANING TOWER OF PIZZI Bendt Ten Brock Digital Photography 0 01-19-2004 11:32 AM



Advertisments