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 | » ]

Paul Boddie

Posts: 26
Nickname: pboddie
Registered: Jan, 2006

Re: A Response to Bruce Eckel

Posted: Sep 12, 2007 9:01 AM

John M Camara writes: "Why would less political alternatives be overlooked if either Guido or the Python community as a whole makes a selection via a vote during PyCon?"

So PyCon is "the community" now, is it? Ignoring the reason why there are alternatives and why it isn't always necessary to pick a winner, let us consider the mechanisms involved in putting something in the standard library.

First, the developers have to be comfortable with periodically synchronising their code (and bundling a certain amount of it) with the Python distribution. Then, both those developers and the Python developers have to be comfortable with fielding or forwarding bug reports on what might well be an increasingly archaic release of the software - this doesn't matter with Tk since it's not exactly blazing new trails. Finally, everyone has to live with either a heavy distribution containing all the libraries or a slightly lighter distribution containing some of the libraries, all while people argue about the licence of the bundled code - this last issue being quite a showstopper given the size and nature of most frameworks.

"I'm sure if it's left up to the community to make a decision a debate will take place and all important issues will be discussed."

I note that the last time this came up, a brand new in-progress solution was proposed. I'm not sure if Guido wants another stdwin in the standard library.

"The real issue that needs to be addressed is that Python's image is hurt by not having support for a world class UI framework. Don't get me wrong there are reasonable good options available but none are as good as what is available for C# for instance."

Really? The only image issue as far as I can see is that some people can't bear to see various copyleft frameworks promoted as Python-based solutions because they personally favour permissive licences (and yet have no problems promoting Microsoft products in some instances) - a shame given the world-class nature of some of those copyleft frameworks.

The best thing would be to unbundle Tk and show people the three or more major framework families in this domain. Sometimes, Python the product is more than just the code in the tarball from python.org - it's about the whole "story" of what works with the language and what people are doing with it.

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: A Response to Bruce Eckel

Posted: Sep 13, 2007 12:56 PM

Started a reply, turned it into a weblog entry:
http://www.artima.com/weblogs/viewpost.jsp?thread=214480

Sergey Kostov

Posts: 3
Nickname: batserjo
Registered: Sep, 2007

Re: A Response to Bruce Eckel

Posted: Sep 16, 2007 12:36 PM

Bruce the right answer to the GUI/UI problem is this:
Strict, structured, interface bridge - defined in Python as a strict API class. Hierarchy of Widgets primitives etc. This is going to be only a interface, no need of default implementation.

Then every GUI kit that wants to be Python compatible MUST implement the methods. How, it's their problem (most likley trivially). No more ugly lib specific code in Python. We define interfaces. And every one that wants to take advantage of his kit under Python follows the interface. No exceptions ( problem we cannot enforce this on language level ).

The beauty of this aproach is that you isolate the interpreter from the outside world, but not limiting it in it's own only. Simply giving a strict way for communication to the outside world.

Sergey Kostov

Posts: 3
Nickname: batserjo
Registered: Sep, 2007

Re: A Response to Bruce Eckel

Posted: Sep 16, 2007 12:54 PM

An interface. An hopefully we will discourage others to make incompatible bindings, because the mases will use only the standart that is ALWAYS there. This can also be implemented in a number of other places.

Ron Stephens

Posts: 2
Nickname: awaretek
Registered: Jan, 2003

Re: A Response to Bruce Eckel

Posted: Sep 16, 2007 1:07 PM

Sergey,

Could the GUI interface bridge also include support for voice input and output, and maybe gestures? OK, I guess I'm off-the-wall, but hey, build it and they might come?

Ron

Sergey Kostov

Posts: 3
Nickname: batserjo
Registered: Sep, 2007

Re: A Response to Bruce Eckel

Posted: Sep 16, 2007 1:33 PM

Totaly YES yes on every level as long as it's sane.
Lets think of it like a ginat os that expands to give more power to the user apps (our programs) and the expansion is with functionaluty but sctrict. The way every kernel does this is system calls. Well this is an interface. And only FS now a days is not enoughf, compression, xml and network, All this must have a interface, and bind it to the lower system.

In general one might say strct FULL-RAD-API interface. Wich will be expandable on the fly. Dynamic loading.

Krishna Sankar

Posts: 3
Nickname: ksankar
Registered: Nov, 2003

Re: A Response to Bruce Eckel

Posted: Sep 16, 2007 2:41 PM

> Python 3000 is mostly the work of a handful of people,
> who mostly care about the core language (which is the
> hardest thing to evolve). Bruce's post (apart from the
> anti-self rant) is mostly about issues around the
> language, like libraries and components. These things can
> easily be added by motivated individuals. It's open
> source. What are you all waiting for?!
> </div>
I have proposed an exploratory PEP (around the multi-core topic) at http://mail.python.org/pipermail/python-ideas/2007-September/000971.html.
Would like to get insights and help from all.

Cheers
<k/>

ian o

Posts: 8
Nickname: iano
Registered: Aug, 2007

Re: A Response to Bruce Eckel

Posted: Sep 18, 2007 4:36 AM

Robust debate is great to have. In the end I think you come to the picture that Python3k is answering what can be answered right now and that what is suggested but not tackled is mostly that which needs further debate at best.

I do think there is one exception. The GUI. Yes, Tk is antiquated, and yes there are two many alternatives to make moving to a direct alternative worthwhile.

So if we solving the traditional GUI is difficult, what about the foundation for 'the browser is the GUI' model? Python is already one of the two solid choices for developing web based apps, the easy and logical path to improving the language for this would be an upgrade to string formatting for output. Mako and Genshi Jinja....there are some great template solutions and choosing one to make standard is too early if not inappropriate for other reasons. What is already happening is the best choice, an upgrade to the old % formatting.

But is the upgrade syntax locked in stone? What is happening has already been critiqued before (e.g. http://arstechnica.com/journals/linux.ars/2007/09/02/afirst-look-at-python-3-0-alpha-1
)
I would not be so critical, but what worries me is that in common to most templating solutions is a two-character sequence to open substitution strings. E.g. '${' in place of the single '{'. The larger the text being processed, the greater the chance of needing to escape the special characters. Double special characters radically reduces the amount of escaping and makes working with larger text format blocks vastly more workable. I wish the new format approach was more suitable for formatting web output by using a double character open symbol. The current approach means any text incorporating braces (including javascript strings) becomes a real mess!

Doing this right may prove to be the best answer to the future user interface needs.

Bill Manaris

Posts: 4
Nickname: manaris
Registered: Nov, 2007

Re: Get rid of self (was: A Response to Bruce Eckel)

Posted: Nov 27, 2007 3:34 AM

Getting rid of self should be straightforward:

> Get rid of self:
> I think this has been addressed in the responses; it's not
> as easy as you'd think,

Simply, have the Python reader automatically insert a self reference to any function defined within a class block.

In other words, have the <FUNCTION-WITHIN-CLASS> grammar rule, within its action, insert a <SELF> token where it's needed in the internal representation used by the evaluator, to maintain the "uniform interpretation of methods".

> and there are important advantages
> to the uniform interpretation of methods as "just
> functions that get called in a funky way". In Ruby,
> everything is a method, or an anonymous block, and there
> are no "free functions". Python uses the
> complimentary approach, treating functions as
> first-class citizens. Both approaches are complete; they
> are however incompatible, and you can't easily morph one
> into the other. (Personally, I find that the criticm of
> explicit self has about as much merit as the criticism of
> Python's use of whitespace.)

There is a big difference. Explicit self violates the HCI principles of consistency and visibility (whitespace doesn't):

Class functions are defined with x parameters, but are called with x-1 parameters. Plus, the error message generated when calling a class function with the wrong number of parameters refers to x parameters, which gives wrong feedback - very confusing.

This is inconsistent with Python's clarity, simplicity, directness, etc.

George Sakkis

Posts: 14
Nickname: gsakkis
Registered: Jun, 2007

Re: Get rid of self (was: A Response to Bruce Eckel)

Posted: Dec 12, 2007 12:35 PM

> Getting rid of self should be straightforward:
>
> > Get rid of self:
> > I think this has been addressed in the responses; it's
> not
> > as easy as you'd think,
>
> Simply, have the Python reader automatically insert a self
> reference to any function defined within a class block.
>
> In other words, have the <FUNCTION-WITHIN-CLASS> grammar
> rule, within its action, insert a <SELF> token where it's
> needed in the internal representation used by the
> evaluator, to maintain the "uniform interpretation of
> methods".

Are you aware of the fact that methods can be added to classes dynamically ? What you suggest cannot be done statically by the parser in Python, let alone that 'self' is not a keyword, it's the conventional name for the first argument in methods.

> > and there are important advantages
> > to the uniform interpretation of methods as "just
> > functions that get called in a funky way". In Ruby,
> > everything is a method, or an anonymous block, and
> there
> > are no "free functions". Python uses the
> > complimentary approach, treating functions as
> > first-class citizens. Both approaches are complete;
> they
> > are however incompatible, and you can't easily morph
> one
> > into the other. (Personally, I find that the criticm
> of
> > explicit self has about as much merit as the criticism
> of
> > Python's use of whitespace.)
>
> There is a big difference. Explicit self violates the HCI
> principles of consistency and visibility (whitespace
> doesn't):
>
> Class functions are defined with x parameters, but are
> called with x-1 parameters.

No they are not; they are called with x parameters too, only the syntax is different for the first argument.

obj.meth(*args, **kwds)

is typically equivalent to

obj.__class__.meth(obj, *args, **kwds)

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: A Response to Bruce Eckel

Posted: Dec 13, 2007 12:10 PM

Pop-up adverts that come up between me and the text that I'm reading have started appearing on Artima. It's unbelievably stupid and irritating and downright rude. Am I in a minority or do people actually welcome and respond to such adverts?

Bill Manaris

Posts: 4
Nickname: manaris
Registered: Nov, 2007

Re: Get rid of self (was: A Response to Bruce Eckel)

Posted: Dec 13, 2007 4:59 PM

> > There is a big difference. Explicit self violates the
> HCI
> > principles of consistency and visibility (whitespace
> > doesn't):
> >
> > Class functions are defined with x parameters, but are
> > called with x-1 parameters.
>
> No they are not; they are called with x parameters too,
> only the syntax is different for the first argument.
>

obj.meth(*args, **kwds)

is typically
> equivalent to

obj.__class__.meth(obj, *args,
> **kwds)

.

Well, from an HCI (user) perspective, class functions are defined with x parameters, and are called with x-1 parameters.

> Are you aware of the fact that methods can be added to
> classes dynamically ?

No I was not, but I should have been. It clearly follows from the conceptual model.

I still feel there must be a better way to handle this inconsistency.

So, the problem is that, when a function is encapsulated within a class, it requires a reference to the surrounding object.

Current Solution: The reference comes through the first parameter (e.g., 'self'), which is required at function definition, but not at function invocation. This discrepancy causes unnecessary usability breakdowns.

Possible Solution: Have the keyword 'self' be a reserved word. Have every instantiated object automatically contain a 'self' reference pointing to the object itself (similar to Java's 'this'). Have free functions that are being defined to be dynamically added to a class use the 'nonlocal' mechanism (statement) to define 'self'. Have each function defined within a class, implicitly use the same mechanism to reach out and access that reference automatically (no parameter list "pollution"). Wouldn't that work?

If so, this solution may be cleaner and may fix the usability problem with 'self' being passed as a parameter. Usability (learnability, consistency, etc.) is a major reason that Python is such a successful language. This is key.

Just a thought.

Michele Costabile

Posts: 2
Nickname: cosmic
Registered: Jan, 2008

Re: A Response to Bruce Eckel

Posted: Jan 20, 2008 2:56 PM

I think that native toolkits are a god thing and library emulations are a bad thing.
This is why I do not like TCL or the Java Swing library. This is also why everybody loves writing Java apps and everybody hates using Java apps.
In the Java community the problem of going as native as possibile for convenience and speed has been addressed by the Eclipse toolkit, the SWT.
I think that if there has to be a new graphic toolkit it should be as native and as cross platform as possible, with an approach similar to SWT.
Otherwise, I agree with Guido: TCL is good as anything else and anything else can be an autonomous library.

Scott Corley

Posts: 1
Nickname: scorley
Registered: Jan, 2008

Bell Labs Proverbs

Posted: Jan 20, 2008 7:47 PM

Guido -
Often, you dismiss issues that are of high interest and importance with variations of the phrase: "In any case this is a library issue that I cannot do much about...".

Every time I see that, I am reminded of these two Bell Labs proverbs:

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

And I have always assumed that those proverbs were the inspiration behind another ideal, "Batteries Included."

You can't expect to wield supreme executive power just because some watery tart threw a sword at you.

Thanks for all continued pythonic goodness,
- Scott

Zooko O'Whielacronx

Posts: 1
Nickname: zooko
Registered: Jan, 2008

Re: A Response to Bruce Eckel

Posted: Jan 24, 2008 5:13 AM

"Eggs and Easyinstall standardized: From the response it's pretty clear why these particular solutions aren't standardized yet -- they are at best controversial."

Wait -- what response? The responses to Bruce Eckel's post included one comment in favor of including setuptools in the standard library, and one comment saying that setuptools wasn't as good as Ruby Gems and Rake.

Where's the controversy?

Setuptools is good, and it is important. This is not the time to start making something new and better, but instead to capitalize on its value by making it standard.

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

Previous Topic

Next Topic