Weblogs Forum - A Response to Bruce Eckel

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
A Response to Bruce Eckel

32 replies on 3 pages. Most recent reply: Mar 9, 2009 7:23 PM by Bill Manaris

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 32 replies on 3 pages [ « | 1 2 3 ]

Martijn Vos

Posts: 1
Nickname: mcv
Registered: Feb, 2008

Re: Bell Labs Proverbs

Posted: Feb 13, 2008 3:36 AM

> 1. "Library design is language design"
> 2. "Language design is library design"

I completely agree with this. I think the size, consistency and quality of the Java libraries are one of its main strengths. And the main thing that's now drawing me towards Python are the excellent native libraries.

Let's be honest here: I don't care much for the language itself. I don't like the explicit self, I completely agree with Bruce Eckel that multithreading support is vital if Python aspires to be a serious application language and not a glorified script language, and I'm afraid that despite the popularity of dynamic typing, static typing still feels somehow better or more reliable to me. In other words, I'm a Java man. But there are some things that Python does better than Java, many of which are related to its libraries.

Libraries are what makes the language. Care about your libraries, because syntax isn't going to win you any fresh souls.

David Johnson

Posts: 2
Nickname: dhj
Registered: May, 2008

Re: A Response to Bruce Eckel

Posted: May 8, 2008 8:42 AM

I completely agree with Bill Manaris and Bruce Eckel on this. The explicit self is a violation of consistency and clarity in the python language. I think that self should be made a keyword and that class method definitions should ignore the self keyword if appearing in the front of the parameter list. Variable references within class functions should start with local scope, followed by the class scope automatically. If the self keyword appears within a method definition then it refers to the "class instance" scope.

This explicit self and inconsistency with the number of parameters called vs claimed by the interpreter is definitely a problem with the consistency and clarity of the python language.

The whitespace issue isn't even an issue, it's a syntax that helps code readability. Whitespace and explicit self shouldn't even be referred to in the same sentence. In my opinion one is a "got it right" the other is a "got it wrong". Surely there is a way to keep functions as "first-class citizens" and still have the self parameter and scoping taken care of in method definitions. I think it could be done by making self a keyword, but maybe there's a better way.

--David

p.s. I know I don't have any clout in the python community, but I feel strongly enough about this to post anyways. I feel that this is the only serious problem with python. It still makes no sense when I get invalid number of argument errors even though I know now why it's giving me errors that don't agree with the code I have written. Just my opinion.

Bill Manaris

Posts: 4
Nickname: manaris
Registered: Nov, 2007

Re: A Response to Bruce Eckel

Posted: Mar 9, 2009 7:23 PM

> I completely agree with Bill Manaris and Bruce Eckel on
> this. The explicit self is a violation of consistency and
> clarity in the python language.

I think I finally have the answer... on how it is technically (and easily) feasible to get rid of 'self'. It took a couple of years, but here it is:

As George Sakkis said,

> obj.meth(*args, **kwds)
>
> is typically equivalent to
>
> obj.__class__.meth(obj, *args, **kwds)

So, instead of having the reader/parser do the above transformation, when calling a member function (as opposed to a free function):

1) Add a 'parent' ('owner'?) attribute within function objects.

2) When defining a free function, the evaluator sets the 'parent' attribute to 'None'.

3) When instantiating an object, the evaluator sets every 'parent' attribute of the object's member functions to the object itself.

4) When dynamically adding a free function to an object, e.g.,

>>> obj.method = freeMethod

the assignment operator updates the 'parent' attribute of 'freeMethod' to 'obj'. Both fields are readily available.

It sure looks simple, clean, and elegant. Goodbye explicit self!? Wouldn't that be something?

What am I missing?

Thanks,

Bill

Flat View: This topic has 32 replies on 3 pages [ « | 1 2 3 ]

Previous Topic

Next Topic


	Web Artima.com