Confessions of a Python fanboy

Just Another Victim of the Ambient Morality ihatespam at hotmail.com
Wed Aug 5 14:47:58 EDT 2009


"Steven D'Aprano" <steven at REMOVE.THIS.cybersource.com.au> wrote in message 
news:pan.2009.08.04.09.28.49 at REMOVE.THIS.cybersource.com.au...
> On Tue, 04 Aug 2009 10:03:53 +0200, Bruno Desthuilliers wrote:
>
>>> Disadvantages: your code is filled with line noise. It's an arbitrary
>>> choice between @@ meaning instance attribute and @@ meaning class
>>> attribute -- there's no logical reason for choosing one over the other,
>>> so you have to memorise which is which. It's easy to get it wrong.
>>
>> So far that's something I have no difficulty living with.
>
> I don't like arbitrary symbols. Most people don't -- that's why "line
> noise" is unpopular. It's hard to read, hard to write, hard to maintain,
> and hard to talk about. The more line-noise, the worse the language.

    It's not "line noise" if it conveys information...


> Of course, *ultimately* every symbol is arbitrary. There's no reason why
> "2" should mean the integer two, or "list" should mean a sequence type,
> but some symbols have such a long history, or have some other connection
> (say, with human languages), that the arbitrariness is lost. For
> instance, "+" is the obvious, non-arbitrary choice for the addition
> operator in any programming language using Latin symbols, and probably
> any programming language on Earth. (Not the *only* choice, but the
> obvious one.)
>
> I have a similar dislike for decorator syntax, because "@" ("at" in
> English) has nothing to do with decorations. It's an arbitrary symbol.
> One might argue that "$" would have been a more logical choice, because
> we turn numerals into currency by decorating it with a $ sign. (At least
> in the US, Canada, Australia, and a few other countries.) I use
> decorators all the time, and they are a fantastic invention, but the
> arbitrariness of the @ syntax is a negative. Oh well, one negative out of
> a whole lot of positives isn't too bad.

    You can think of "@" as describing something being "at" the instance or 
the class.  "$" is totally arbitrary to me 'cause I don't thnk of my code as 
currency...


> At least I only have to deal with *one* such arbitrary symbol that needs
> memorizing. There's no need to distinguish between @@function_decorator
> and @class_decorator (or should it be the other way around?). Similarly,
> Python's choice of syntax for attributes is consistent: object.attribute
> works for everything, whether object is a class, an instance, a module,
> and whether attribute is callable or not. You can even use it on ints,
> provided you are clever about it:

    You can think of "@" as being at an instance or "@@" to be more 
emphatically (as the Japanese do in their language) integrated with a class, 
being available to all instances... or you can simply understand that 
instance vairables are more common than class variables so the shorter 
notation is used for the more common case...
    You want to talk about arbitrariness?  Why is len() a function you pass 
objects into while objects can have methods that describe themselves to you? 
At least Ruby defines operators using the actual name of the operator 
instead of you having to remember an arbitrary magic incantation that 
corresponds to the operator...

class Test
    attr_reader :data

    def initialize(data)
        @data = data
    end

    # This is the operator part...
    def + right
        Test.new @data + right.data
    end
end


>>>>> Somebody who knows more Ruby than me should try writing the Zen of
>>>>> Ruby. Something like:
>>>> (snip childish parody of Python Zen)
>>>>
>>>> Steven, is that any useful ?
>>>
>>> It made me feel good.
>>
>> Why ???
>>
>> You don't like Ruby ? Fine, don't use it. Period. I can't see the point
>> of all these pissing contests.
>
> Criticism of a language is a pissing contest?
>
> Yeah, okay, I was a tad dismissive. I un-apologetically jump to strong
> impressions about languages based on minimal use -- but I'm also willing
> to change my mind. Ruby certainly looks to me like it has some nice
> features. Syntax that looks like Perl isn't one of them though.

    Yeah, that would be the "pissing contest" part.
    You could simply have gone to the Ruby newsgroup and posted some 
criticisms to see what was behind those decisions.  However, that would have 
avoided the pissing contest and perhaps you wanted one...


>>> Just because Smalltalk had a particular (mis?)feature
>>
>> You can drop the 'mis' part IMHO. The point of code blocks in Smalltalk
>> is that once you have something as powerful as the message+code blocks
>> combo, you just don't need any other 'special form' for control flow.
>
> Well, maybe, but remember, programming languages are only partly for
> communication to the compiler. They also have the requirement to
> communicate with human programmers as well, and that's even more
> important, because
>
> (1) humans spent a lot more time working with code than compilers do;
>
> (2) human programmers charge much more money than compilers do;
>
> (3) and you can modify the compiler to suit human needs much more easily
> than you can modify programmers to suit the compiler's needs.
>
> So I'd ask, does Smalltalk's message passing model match the way human
> beings think? If not, then that's a good sign it might be a misfeature.

    I think this is overstated.  Not all humans think in exactly the same 
way so it's very presumptuous.  It also ignores our intellect.  We can 
change the way we think and we can use this versatility to our advantage. 
We can increase our productivity in certain tasks by changing the way we 
think to some other paradigm that better serves a given purpose...


>>> doesn't mean that
>>> other languages should copy it.
>>
>> Nope. But OTHO, Python is famous for all the features it copied from
>> other languages !-)
>
> Absolutely! There's nothing wrong with copying *good* features :)

    The trick, of course, is figuring out which features are good! 





More information about the Python-list mailing list