Re: The del statement
George Sakkis wrote: > I think you're trying to imply that it is consistent with setting a > value (same with getting). I guess what bugs me about "del" is that > it's a keyword and not some universally well-known punctuation. Do you > you feel that Python misses a "pop" keyword and respective > expressions ? Typically the word "pop" has a different meaning than you describe. Most programmers think of pop in conjunction with push, for working with FIFOs. Normally pop would not be expected to take any arguments, or maybe an argument of a number describing how many items to pop off of a FIFO (stack). Thus I don't think a pop method would be the right way to go here. I don't feel python misses a pop keyword because pop is already used as methods of classes implementing stacks and FIFOs where appropriate. > > (1) pop x: Remove x from the current namespace and return it. > (2) pop x[i]: Instead of x.pop(i) > (3) pop x.a: Equivalent to "_y=x.a; del x.a; return y" The confusion over del does stem from it's behavior, so I can see where you're coming from. del doesn't delete anything; it just removes a name. However pop would be just as confusing in my opinion, given that it's already associated with data structures. -- http://mail.python.org/mailman/listinfo/python-list
Re: The del statement
"George Sakkis" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| One of the few Python constructs that feels less elegant than
| necessary to me is the del statement. For one thing, it is overloaded
| to mean three different things:
| (1) del x: Remove x from the current namespace
| (2) del x[i]: Equivalent to x.__delitem__(i)
| (3) del x.a: Equivalent to x.__delattr__('a') (or delattr(x,'a'))
Since I see del x.a as deleting a from the attribute namespace of x, I see
this as the same meaning. A namespace is a specialized association (keys
are identifier strings). A dict is more generalized (keys merely
hashable). So ditto for del dic[key].
The only different meaning is del somelist[i]. The implicit association
between counts in range(n=len(somelist)) *is* broken, but unless i == n-1,
items are 'shifted down' so that some other item become associated with i,
and j's for i < j < n-1 get new associations and n-1 is left with none.
One could imagine del somelist[i] as simple leaving a void in the list.
(Which is not to say that that would be terribly useful.)
tjr
--
http://mail.python.org/mailman/listinfo/python-list
Re: The del statement
On May 8, 2:58 am, Arnaud Delobelle <[EMAIL PROTECTED]> wrote:
> George Sakkis wrote:
> > One of the few Python constructs that feels less elegant than
> > necessary to me is the del statement. For one thing, it is overloaded
> > to mean three different things:
> > (1) del x: Remove x from the current namespace
> > (2) del x[i]: Equivalent to x.__delitem__(i)
> > (3) del x.a: Equivalent to x.__delattr__('a') (or delattr(x,'a'))
>
> Note that the 'X = Y' construct has the corresponding three meanings:
>
> (1) x = 4 # Bind x to 4 in the 'current namespace'
> (2) x[i] = 4 # equivalent to x.__setitem__(i, 4)
> (3) x.a = 4 # Equivalent to x.__setattr__('a', 4)
>
> What conclusion should we draw from that?
I think you're trying to imply that it is consistent with setting a
value (same with getting). I guess what bugs me about "del" is that
it's a keyword and not some universally well-known punctuation. Do you
you feel that Python misses a "pop" keyword and respective
expressions ?
(1) pop x: Remove x from the current namespace and return it.
(2) pop x[i]: Instead of x.pop(i)
(3) pop x.a: Equivalent to "_y=x.a; del x.a; return y"
George
--
http://mail.python.org/mailman/listinfo/python-list
Re: The del statement
Arnaud Delobelle <[EMAIL PROTECTED]> wrote:
>
>
> Duncan Booth wrote:
>> Arnaud Delobelle <[EMAIL PROTECTED]> wrote:
>>
>> >
>> >
>> > George Sakkis wrote:
>> >> One of the few Python constructs that feels less elegant than
>> >> necessary to me is the del statement. For one thing, it is
overloaded
>> >> to mean three different things:
>> >> (1) del x: Remove x from the current namespace
>> >> (2) del x[i]: Equivalent to x.__delitem__(i)
>> >> (3) del x.a: Equivalent to x.__delattr__('a') (or delattr(x,'a'))
>> >
>> > Note that the 'X = Y' construct has the corresponding three
meanings:
>> >
>> > (1) x = 4 # Bind x to 4 in the 'current namespace'
>> > (2) x[i] = 4 # equivalent to x.__setitem__(i, 4)
>> > (3) x.a = 4 # Equivalent to x.__setattr__('a', 4)
>>
>> I think you both missed a case:
>>
>> (1b) global x; del x# Remove x from global namespace
>> (1b) global x; x = 4# Bind x to 4 in the global namespace
>
> This is why you put 'current namespace' in quotes! But all three of
> us missed the case:
I'd assumed you were just trying to say that the current namespace might
be different things: locals or a class namespace. I would say that the
global statement makes the assign/del refer to a non-current namespace.
>
> (1-3000) What about nonlocal?
What about nonlocal? You can't (in Python 2.x) assign or del a name from
an enclosing scope if that's what you mean. If that isn't what you mean
then you'll have to explain it to me in simpler terms.
--
http://mail.python.org/mailman/listinfo/python-list
Re: The del statement
Duncan Booth wrote:
> Arnaud Delobelle <[EMAIL PROTECTED]> wrote:
>
> >
> >
> > George Sakkis wrote:
> >> One of the few Python constructs that feels less elegant than
> >> necessary to me is the del statement. For one thing, it is overloaded
> >> to mean three different things:
> >> (1) del x: Remove x from the current namespace
> >> (2) del x[i]: Equivalent to x.__delitem__(i)
> >> (3) del x.a: Equivalent to x.__delattr__('a') (or delattr(x,'a'))
> >
> > Note that the 'X = Y' construct has the corresponding three meanings:
> >
> > (1) x = 4 # Bind x to 4 in the 'current namespace'
> > (2) x[i] = 4 # equivalent to x.__setitem__(i, 4)
> > (3) x.a = 4 # Equivalent to x.__setattr__('a', 4)
>
> I think you both missed a case:
>
> (1b) global x; del x# Remove x from global namespace
> (1b) global x; x = 4# Bind x to 4 in the global namespace
This is why you put 'current namespace' in quotes! But all three of
us missed the case:
(1-3000) What about nonlocal?
> That Python is simple and consistent.
Seems reasonable to me.
--
Arnaud
--
http://mail.python.org/mailman/listinfo/python-list
Re: The del statement
Arnaud Delobelle <[EMAIL PROTECTED]> wrote:
>
>
> George Sakkis wrote:
>> One of the few Python constructs that feels less elegant than
>> necessary to me is the del statement. For one thing, it is overloaded
>> to mean three different things:
>> (1) del x: Remove x from the current namespace
>> (2) del x[i]: Equivalent to x.__delitem__(i)
>> (3) del x.a: Equivalent to x.__delattr__('a') (or delattr(x,'a'))
>
> Note that the 'X = Y' construct has the corresponding three meanings:
>
> (1) x = 4 # Bind x to 4 in the 'current namespace'
> (2) x[i] = 4 # equivalent to x.__setitem__(i, 4)
> (3) x.a = 4 # Equivalent to x.__setattr__('a', 4)
I think you both missed a case:
(1b) global x; del x# Remove x from global namespace
(1b) global x; x = 4# Bind x to 4 in the global namespace
> What conclusion should we draw from that?
That Python is simple and consistent.
--
http://mail.python.org/mailman/listinfo/python-list
Re: The del statement
George Sakkis wrote:
> One of the few Python constructs that feels less elegant than
> necessary to me is the del statement. For one thing, it is overloaded
> to mean three different things:
> (1) del x: Remove x from the current namespace
> (2) del x[i]: Equivalent to x.__delitem__(i)
> (3) del x.a: Equivalent to x.__delattr__('a') (or delattr(x,'a'))
Note that the 'X = Y' construct has the corresponding three meanings:
(1) x = 4 # Bind x to 4 in the 'current namespace'
(2) x[i] = 4 # equivalent to x.__setitem__(i, 4)
(3) x.a = 4 # Equivalent to x.__setattr__('a', 4)
What conclusion should we draw from that?
--
Arnaud
--
http://mail.python.org/mailman/listinfo/python-list
The del statement
One of the few Python constructs that feels less elegant than
necessary to me is the del statement. For one thing, it is overloaded
to mean three different things:
(1) del x: Remove x from the current namespace
(2) del x[i]: Equivalent to x.__delitem__(i)
(3) del x.a: Equivalent to x.__delattr__('a') (or delattr(x,'a'))
(1) is useful, or even necessary, at least as long as there are only
two namespaces (local and global) instead of a separate namespace per
block, so that's ok for now. The other two though, don't justify IMO a
separate statement.
I would strongly prefer (2) to be implemented by a normal method
instead of a special syntax and method. See the inconsistency:
s = ['a', 'b']
s.pop(0)
del s[0]
Likewise for dicts. Why not s.del(0) ? And just in case someone argues
"for the same reason we have __getitem__ and __setitem__", it is not
the same; the syntax for get/set (s[0], s[0] = 'a') doesn't introduce
a new keyword (or overload an existing one), it is pretty intuitive
and used across many languages. As for (3), it is pretty uncommon to
deserve its own syntax; delattr() or directly modifying self.__dict__
are good enough.
I understand that no more proposals are accepted for Python 3 but it
looks like a missed opportunity to make the language a bit simpler and
more consistent. Anyone else have an opinion on this?
George
--
http://mail.python.org/mailman/listinfo/python-list
Re: The del statement
Marco Aschwanden wrote: > I am not convinced though that del should also remove elements > from a container/sequence. in today's Python, you can use "del" on all targets that you can assign to. I'm not sure how breaking this consistency would somehow improve things... -- http://mail.python.org/mailman/listinfo/python-list
Re: The del statement
Thanks for the answers. I see that the del statement does remove an object from the namespace. And yes, it makes perfect sense to handle it from "outside" with the del command. I am not convinced though that del should also remove elements from a container/sequence. Thanks for the enlighting answers, Marco -- http://mail.python.org/mailman/listinfo/python-list
Re: The del statement
Marco Aschwanden <[EMAIL PROTECTED]> wrote: [ ... ] >> so what about >> >> del x > >Ups. I never used it for an object. So far I only used it for deletion of >elements of a container. In that case del has two purposes: > >1. Deletes an item from a container (and of course destructs it) --> >list.remove(elem) >2. Calls the destructor of an object --> list.destruct() > >One statement and two distinct purposes. Leaving aside the discussion about whether Python has destructors or not, you are mistaken on two counts: 1. del *is not responsible for an object being destroyed*. That is done by the garbage collector. 2. del is only ever used to "delete an item from a container". It's just that in the plain "del x" case, the container is implicitly the current namespace. (In any case, it's not really "deleting an item from a container", it's removing a reference to the item from the container.) -- \S -- [EMAIL PROTECTED] -- http://www.chaos.org.uk/~sion/ ___ | "Frankly I have no feelings towards penguins one way or the other" \X/ |-- Arthur C. Clarke her nu becomeþ se bera eadward ofdun hlæddre heafdes bæce bump bump bump -- http://mail.python.org/mailman/listinfo/python-list
Re: The del statement
Marco Aschwanden wrote: > > do you find the x[i] syntax for calling the getitem/setitem methods a > > bit awkward too? what about HTTP's use of "GET" and "POST" for most > > about everything ? ;-) > > No. I like the x[i] syntax. I use it in every second row of my code and > getting an item like: > > x.getitem(i) That's spelled "x.__getitem__(i)". Still prefer the method call? > would be a viable (in this case clumsy) way but here I find the introduced > syntax justified. > del on the other hand is used sparingly througout my code. If no del > keyword would exist, it wouldn't disturb me. "del x[i]" calls "x.__delitem__(i)". I can't say specifically what list.__delitem__ does, but looking it up in IDLE (l is an instance of list): >>> l.remove >>> l.__getitem__ >>> l.__delitem__ It seems that list.__delitem__ is a different type than the rest, called method-wrapper. I can only guess from this point; someone else is bound to know about this. > Marco I can see some builtin functions leaving, but the del keyword isn't exactly unimportant. Looking at the documentation on the del statement: http://docs.python.org/ref/del.html There is no note saying that del is deprecated. That really doesn't mean anything; it could always become deprecated in the future, but it doesn't seem likely. -- http://mail.python.org/mailman/listinfo/python-list
Re: The del statement
> do you find the x[i] syntax for calling the getitem/setitem methods a > bit awkward too? what about HTTP's use of "GET" and "POST" for most > about everything ? ;-) No. I like the x[i] syntax. I use it in every second row of my code and getting an item like: x.getitem(i) would be a viable (in this case clumsy) way but here I find the introduced syntax justified. del on the other hand is used sparingly througout my code. If no del keyword would exist, it wouldn't disturb me. Marco -- http://mail.python.org/mailman/listinfo/python-list
Re: The del statement
Marco Aschwanden wrote: > 2. Calls the destructor of an object --> list.destruct() "del name" only removes the name from the current namespace, it doesn't destroy the object: http://effbot.org/pyref/del the actual destruction is handled by the garbage collector, when the time is right. > The del keyword for removing an element in a container is a bit > awkward to me. do you find the x[i] syntax for calling the getitem/setitem methods a bit awkward too? what about HTTP's use of "GET" and "POST" for most about everything ? ;-) -- http://mail.python.org/mailman/listinfo/python-list
Re: The del statement
> so what about > > del x Ups. I never used it for an object. So far I only used it for deletion of elements of a container. In that case del has two purposes: 1. Deletes an item from a container (and of course destructs it) --> list.remove(elem) 2. Calls the destructor of an object --> list.destruct() One statement and two distinct purposes. Why not having two "standard" function (for containers we have a remove-function) and all objects have a destruct-function. Still no need for a del keyword. A del keyword that calls the destructor... well that is okay (it could be handled without). I am used to see the del keyword in opposition to the new keyword (which does not exist/is implicit in Python). The del keyword for removing an element in a container is a bit awkward to me. I am not as knowledgeable about languages as you are and I am hoping people like you can enlighten me about the language decision taken. > for the curious, guido's rationale for len() can be found here: > >http://preview.tinyurl.com/y6vavp Thanks for the hint. Marco -- http://mail.python.org/mailman/listinfo/python-list
Re: The del statement
Marco Aschwanden wrote: > Where > > list.del(elem) > map.del(elem) > > would achieve the same result (and I think, this is what happens in the > backend). so what about del x ? > The same discussion was done for the "external" len-function (list.len() > vs. len(list)). for the curious, guido's rationale for len() can be found here: http://preview.tinyurl.com/y6vavp -- http://mail.python.org/mailman/listinfo/python-list
The del statement
Hi I was wondering whether the del statment was going to stay in Python3000? It is a bit awkward to use the del statement where a method call would do the same without the need for a new keyword. del list[elem] del map[elem] Where list.del(elem) map.del(elem) would achieve the same result (and I think, this is what happens in the backend). The same discussion was done for the "external" len-function (list.len() vs. len(list)). I don't dare to say that the del-keyword is superflous, but I would like to know the pros and cons of the external keyword approach. Greetings, Marco -- http://mail.python.org/mailman/listinfo/python-list
