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

 
 
Tim Wintle
Guest
Posts: n/a
 
      04-04-2009
On Sat, 2009-04-04 at 02:03 -0500, Robert Kern wrote:
>
> 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

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


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

 
Reply With Quote
 
 
 
 
Diez B. Roggisch
Guest
Posts: n/a
 
      04-04-2009
Tim Wintle schrieb:
> On Sat, 2009-04-04 at 02:03 -0500, Robert Kern wrote:
>> 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
>
>>> (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.

>
> 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
 
Reply With Quote
 
 
 
 
Robert Kern
Guest
Posts: n/a
 
      04-04-2009
On 2009-04-04 12:07, Tim Wintle wrote:
> On Sat, 2009-04-04 at 02:03 -0500, Robert Kern wrote:
>> 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
>
>>> (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.

>
> 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?


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


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

 
Reply With Quote
 
Tim Wintle
Guest
Posts: n/a
 
      04-05-2009
On Sat, 2009-04-04 at 15:36 -0500, Robert Kern wrote:
> On 2009-04-04 12:07, Tim Wintle wrote:
> >>> (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.

> >
> > 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?
>


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

 
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