Ten Essential Development Practices

[gyromagnetic]

The following url points to an article written by Damian Conway
entitled "Ten Essential Development Practices":
http://www.perl.com/pub/a/2005/07/14/bestpractices.html

Althought the article has Perl as a focus, I thought that some of the
general points made might be of interest to the Python community. It
would certainly be interesting to put together an analogous version of
this article that centers on Python.

Best Regards,
g

[Michael Hoffman]

gy**********@gmail.com wrote:

The following url points to an article written by Damian Conway
entitled "Ten Essential Development Practices":
http://www.perl.com/pub/a/2005/07/14/bestpractices.html

Althought the article has Perl as a focus, I thought that some of the
general points made might be of interest to the Python community. It
would certainly be interesting to put together an analogous version of
this article that centers on Python.

He spends so much space on "Create Consistent Command-Line Interfaces,"
a section that, in Python, could be replaced with a simple "Use optparse."
--
Michael Hoffman

[Jeremy Moles]

He spends so much space on "Create Consistent Command-Line Interfaces,"
a section that, in Python, could be replaced with a simple "Use optparse."
Haha... I don't know why but that really made me laugh. :) Might even
use it as a sig or something... :)

--
Michael Hoffman

[Robert Kern]

gy**********@gmail.com wrote:

The following url points to an article written by Damian Conway
entitled "Ten Essential Development Practices":
http://www.perl.com/pub/a/2005/07/14/bestpractices.html

Althought the article has Perl as a focus, I thought that some of the
general points made might be of interest to the Python community. It
would certainly be interesting to put together an analogous version of
this article that centers on Python.

import this

And you get 9 bonus Essential Development Practices, too! What a bargain!

--
Robert Kern
rk***@ucsd.edu

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

[Michael Hoffman]

Robert Kern wrote:

import this

And you get 9 bonus Essential Development Practices, too! What a bargain!

One of these days I'm going to figure out how to embody "Namespaces are
one honking great idea -- let's do more of those!" Then I shall be
enlightened.
--
Michael Hoffman

[Dan Sommers]

On Thu, 28 Jul 2005 21:19:53 +0100,
Michael Hoffman <ca*******@mh391.invalid> wrote:

Robert Kern wrote:

import this
And you get 9 bonus Essential Development Practices, too! What a
bargain!

One of these days I'm going to figure out how to embody "Namespaces are
one honking great idea -- let's do more of those!" Then I shall be
enlightened.

And when the one obvious way to do something *is* be obvious at first,
then I shall be Dutch! <wink>

Regards,
Dan

--
Dan Sommers
<http://www.tombstonezero.net/dan/>

[Aahz]

In article <dc**********@gemini.csx.cam.ac.uk>,
Michael Hoffman <ca*******@mh391.invalid> wrote:

Robert Kern wrote:

import this

And you get 9 bonus Essential Development Practices, too! What a bargain!

One of these days I'm going to figure out how to embody "Namespaces are
one honking great idea -- let's do more of those!" Then I shall be
enlightened.

What don't you understand about it? (This is a serious question -- I
can think of several answers to give you, but want to know what focus is
needed first.)
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

The way to build large Python applications is to componentize and
loosely-couple the hell out of everything.

[Michael Hoffman]

Aahz wrote:

One of these days I'm going to figure out how to embody "Namespaces are
one honking great idea -- let's do more of those!" Then I shall be
enlightened.

What don't you understand about it? (This is a serious question -- I
can think of several answers to give you, but want to know what focus is
needed first.)

I wasn't expecting a serious answer to this, but here goes.

First, I wasn't a Python user when namespaces were introduced. It's hard
for me to even imagine Python without namespaces. Did imported modules
just go into the same namespace as everything else? Yuck. It's too bad
this happened before there were PEPs so I could understand the design
and what came before.

Is it the fact that Python is unimaginable without namespaces that makes
them such a honking great idea? Aren't they somewhat of an obvious idea?
Several other languages have them.

Was the implementation of namespaces easy or hard to explain?

I'd love to do more honking great ideas, but I'm not even sure what the
Dutch ideal of a honking great idea is in the first place.
--
Michael Hoffman

[Robert Kern]

Michael Hoffman wrote:

Aahz wrote:

One of these days I'm going to figure out how to embody "Namespaces are
one honking great idea -- let's do more of those!" Then I shall be
enlightened.
What don't you understand about it? (This is a serious question -- I
can think of several answers to give you, but want to know what focus is
needed first.)

I wasn't expecting a serious answer to this, but here goes.

First, I wasn't a Python user when namespaces were introduced. It's hard
for me to even imagine Python without namespaces. Did imported modules
just go into the same namespace as everything else? Yuck. It's too bad
this happened before there were PEPs so I could understand the design
and what came before.

I'm pretty sure that namespaces are fundamental to the design of Python.
I don't think there was any "before namespaces."
Is it the fact that Python is unimaginable without namespaces that makes
them such a honking great idea? Aren't they somewhat of an obvious idea?
Several other languages have them.

Was the implementation of namespaces easy or hard to explain?

It isn't just that Python has namespaces, but that they are the
implementation for quite a lot of things. Modules: namespaces. Classes:
namespaces. Instances: namespaces. Scope: namespaces. It's a very
elegant way to handle a broad class of language features very consistently.

That said, I made a boo-boo. The Zen of Python is really a set of design
principles (and some of them, like this one, are more specifically
*language* design principles), not Essential Development Practices.
That'll teach me to not RTFA.

--
Robert Kern
rk***@ucsd.edu

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

[Dan Sommers]

On Thu, 28 Jul 2005 15:35:54 -0700,
Robert Kern <rk***@ucsd.edu> wrote:

That said, I made a boo-boo. The Zen of Python is really a set of
design principles (and some of them, like this one, are more
specifically *language* design principles), not Essential Development
Practices. That'll teach me to not RTFA.

May I respectfully disagree? The Zen applies to all aspects of software
(and other things, too, but they're off topic here), from human readable
reports and requirements and documentation, to GUI's, to test cases, to
code, to database schemta, as well as the development methodology and
practices themselves.

Sometimes you have to look at the Zen sideways, so that "implementation"
appears to be replaced by the particular aspect or aspects (or the
software, or just software, as a whole, for the true Masters out there)
you happen to be working on at the time, but such is the nature of Zen.

Regards,
Dan

--
Dan Sommers
<http://www.tombstonezero.net/dan/>

[Peter Hansen]

Dan Sommers wrote:

The Zen applies to all aspects of software
(and other things, too, but they're off topic here), from human readable
reports and requirements and documentation, to GUI's, to test cases, to
code, to database schemta, as well as the development methodology and
practices themselves.

Sometimes you have to look at the Zen sideways, so that "implementation"
appears to be replaced by the particular aspect or aspects (or the
software, or just software, as a whole, for the true Masters out there)
you happen to be working on at the time, but such is the nature of Zen.

It also applies to Motorcycle Maintenance, of course... (as in "Zen and
the Art of").

-Peter

[Robert Kern]

Dan Sommers wrote:

On Thu, 28 Jul 2005 15:35:54 -0700,
Robert Kern <rk***@ucsd.edu> wrote:

That said, I made a boo-boo. The Zen of Python is really a set of
design principles (and some of them, like this one, are more
specifically *language* design principles), not Essential Development
Practices. That'll teach me to not RTFA.
May I respectfully disagree?

No, I'm afraid that you may only disrespectfully disagree with me. I
will not tolerate politeness. Why? Uh, my .sig quote justifies rudeness!
Yes, that's it![1]
The Zen applies to all aspects of software
(and other things, too, but they're off topic here), from human readable
reports and requirements and documentation, to GUI's, to test cases, to
code, to database schemta, as well as the development methodology and
practices themselves.
Sure, and I can find programming advice in the Old Testament, too, if I
try hard enough[2]. But that doesn't change the fact that the "Essential
Development Practices" (e.g. "Use a source control system") are in a
different category than the Zen of Python (e.g. "Namespaces are one
honking great idea -- let's do more of those!"). Hence Michael Hoffman's
very good question about how he might embody that particular bit of Zen:
it's just not applicable to the things he's doing because it's a design
principle for Python the language, not about development (or even
design!) in general.

Of course other pieces of the Zen are more generally applicable
("Readability counts.") as a "development practice," but that's
something of an accident. Usually, they're about design, sometimes
specifically about the design of Python the language.
Sometimes you have to look at the Zen sideways, so that "implementation"
appears to be replaced by the particular aspect or aspects (or the
software, or just software, as a whole, for the true Masters out there)
you happen to be working on at the time, but such is the nature of Zen.

That's a bit too much navel-gazing for me. With enough effort, you make
anything a symbol of anything else. But that doesn't get any code written.

[1]
http://groups-beta.google.com/group/...f205c9b6709163

[2] Proverbs 28:14 JPS "Happy is the man that feareth alway; but he that
hardeneth his heart shall fall into evil." Obviously an exhortation to
not ignore raised exceptions with "except: pass".

--
Robert Kern
rk***@ucsd.edu

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

[Steve Holden]

Dan Sommers wrote:

On Thu, 28 Jul 2005 15:35:54 -0700,
Robert Kern <rk***@ucsd.edu> wrote:

That said, I made a boo-boo. The Zen of Python is really a set of
design principles (and some of them, like this one, are more
specifically *language* design principles), not Essential Development
Practices. That'll teach me to not RTFA.

May I respectfully disagree? The Zen applies to all aspects of software
(and other things, too, but they're off topic here), from human readable
reports and requirements and documentation, to GUI's, to test cases, to
code, to database schemta, as well as the development methodology and
practices themselves.

Sometimes you have to look at the Zen sideways, so that "implementation"
appears to be replaced by the particular aspect or aspects (or the
software, or just software, as a whole, for the true Masters out there)
you happen to be working on at the time, but such is the nature of Zen.

Regards,
Dan

If I canpoint out the obvious, the output from "import this" *is* headed
"The Zen of Python", so clearly it isn;t intended to be universal in its
applicability.

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC http://www.holdenweb.com/

[Michael Hudson]

Steve Holden <st***@holdenweb.com> writes:

If I canpoint out the obvious, the output from "import this" *is*
headed "The Zen of Python", so clearly it isn;t intended to be
universal in its applicability.

It's also mistitled there, given that it was originally posted as '19
Pythonic Theses' and nailed to, erm, something.

Cheers,
mwh

--
Remember - if all you have is an axe, every problem looks
like hours of fun. -- Frossie
-- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html

[Dan Sommers]

On Fri, 29 Jul 2005 10:08:15 +0100,
Steve Holden <st***@holdenweb.com> wrote:

If I canpoint out the obvious, the output from "import this" *is*
headed "The Zen of Python", so clearly it isn;t intended to be
universal in its applicability.

Ok, not universal. But as usual, Zen is not easily nailed to a tree.

Was Tim writing about developing Python itself, or about developing
other programs with Python?

Regards,
Dan

--
Dan Sommers
<http://www.tombstonezero.net/dan/>

[Paolino]

gy**********@gmail.com wrote:

The following url points to an article written by Damian Conway
entitled "Ten Essential Development Practices":
http://www.perl.com/pub/a/2005/07/14/bestpractices.html

Althought the article has Perl as a focus, I thought that some of the
general points made might be of interest to the Python community. It
would certainly be interesting to put together an analogous version of
this article that centers on Python.

Hmm, Perl is called a write once language, but it has thousands of
libraries.Any comment appreciated.

That said,those points are mixing different responsabilities in writing
code.I keep on mixing for fun:

-Writing libraries is not writing scripts.
-Writing readable,well structured,non redundant code is somewhat
perpendicular to tests.
-Writing tests is a must for more people to work on the same code.
-Deciding the interface and writing docs before coding can be bad for
experimental coding.
-Logic optimization can influence interfaces.
-Time optimization is a leverage to get paid in open source
software.Never think about that for free.

Paolino

___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it

[Tim Peters]

[Steve Holden]

If I canpoint out the obvious, the output from "import this" *is*
headed "The Zen of Python", so clearly it isn;t intended to be
universal in its applicability.

[Michael Hudson] It's also mistitled there, given that it was originally posted as '19
Pythonic Theses' and nailed to, erm, something.

'Twas actually posted as "20 Pythonic Theses", although most times I
count them I find19. Nevertheless, that there are in fact 20 was
channeled directly from Guido's perfectly Pythonic mind, so 20 there
must be. I suspect he withheld one -- although, as some argue, it's
possible he thinks in base 9.5, that just doesn't seem Pythonic to me.

[Tim Peters]

[Dan Sommers]

Ok, not universal. But as usual, Zen is not easily nailed to a tree.

Was Tim writing about developing Python itself, or about developing
other programs with Python?

Tim was channeling Guido, and that's as far as our certain knowledge
can go. It _seems_ reasonable to believe that since Guido's mind is,
by definition, perfectly Pythonic, any truth channeled from it
necessarily applies to all things Pythonic.

nevertheless-we-interpret-the-gods-at-our-peril-ly y'rs - tim

[Aahz]

In article <m2************@unique.fully.qualified.domain.name .yeah.right>,
Dan Sommers <[e-mail]> wrote:

Was Tim writing about developing Python itself, or about developing
other programs with Python?

Yes.

(C'mon, didja really expect any other answer?)
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

The way to build large Python applications is to componentize and
loosely-couple the hell out of everything.

[Bill Mill]

<snip>

although, as some argue, it's
possible [GvR] thinks in base 9.5, that just doesn't seem Pythonic to me.

+1 QOTW

Peace
Bill Mill
bi*******@gmail.com

[Dark Cowherd]

I am new to Python. I tried it out and think it is fantastic.

I really loved this from import this statements:

There should be one-- and preferably only one --obvious way to do it.

But this not true of Python.
GUI, Web development, Application Framework - it is shambles. It is so
frustrating for a person who comes from a well designed environment /
framework like Delphi.
-Quote - Phillip J. Eby from dirtsimple.org
Python as a community is plagued by massive amounts of
wheel-reinvention. The infamous web framework proliferation problem is
just the most egregious example.

Why is Python "blessed" with so much reinvention? Because it's often
cheaper to rewrite than to reuse. Python code is easy to write, but
hard to depend on. You pretty much have to:

1. limit yourself to platforms with a suitable packaging system,
2. bundle all your dependencies into your distribution, or
3. make your users do all the work themselves

Ouch. No wonder rewriting looks easier. The only way to stop this
trend is to make it easier to reuse than to rewrite, which has been my
mission with setuptools and EasyInstall
-UnQuote

My organisation writes products for Small and Medium Enterprises. We
are using Delphi, we want to do more web based and Linux solutions, so
I was evaluating Python, but even though I love the language and will
probably do hobby programming using the language, I wouldnt really
recommend our organisation to plan and execute a tranisition.

We have been around a while and we have planned and done transitions
from Clipper to FoxproW to VB to Delphi.

From what I understand Database access was in similar shambles in

Python but a SIG took up the task and made some decisions which has
now streamlined database access in Python.

I really would love to have a Python where TOOWTDI

Is there some place to discuss topics like this? Is this the right place?
--
DarkCowherd

[Michael Hoffman]

Dark Cowherd wrote:

GUI, Web development, Application Framework - it is shambles.
Yeah, I agree. When I finally make that GUI application I still don't
know whether I am going to use wx or PyGTK.
Is there some place to discuss topics like this? Is this the right place?

Sure, although you might want to start a new thread. ;)
--
Michael Hoffman

[Daniel Dittmar]

Dark Cowherd wrote:

There should be one-- and preferably only one --obvious way to do it.

But this not true of Python.
GUI, Web development, Application Framework - it is shambles. It is so
That's because there is no *obvious* way to do these.
-Quote - Phillip J. Eby from dirtsimple.org
Python as a community is plagued by massive amounts of
wheel-reinvention. The infamous web framework proliferation problem is
just the most egregious example.

In stark contrast to Java, where everybody uses standard components like
JSP, Struts, Tapestry, JSF, Spring, ...

Daniel

[Torsten Bronger]

Hallöchen!

Michael Hoffman <ca*******@mh391.invalid> writes:

Dark Cowherd wrote:

GUI, Web development, Application Framework - it is shambles.

Yeah, I agree. When I finally make that GUI application I still
don't know whether I am going to use wx or PyGTK.

I agree, too, although I can only talk about GUI toolkits. At first
one thinks "well, perfect, I have the choice between four great GUI
systems". However, except for very special demands, there is no
clear winner. You start learning one, and immediately wonder
whether the other might be better. Although it sounds paradoxical,
this can be quite frustrating. After all, most of us don't have the
energy or motivation to test all candidates thoroughly.

Besides, development resources are shared between all projects.
This is especially sad with regard to IDEs. There are even more
IDEs/dialog editors/widget builders than Toolkits, none of them
being mature.

Is there some place to discuss topics like this? Is this the right place?

Sure, although you might want to start a new thread. ;)

At least a new subject ...

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus

[Michael Hoffman]

Torsten Bronger wrote:

Hallöchen!

Michael Hoffman <ca*******@mh391.invalid> writes:

Dark Cowherd wrote:

GUI, Web development, Application Framework - it is shambles.

Yeah, I agree. When I finally make that GUI application I still
don't know whether I am going to use wx or PyGTK.

I agree, too, although I can only talk about GUI toolkits. At first
one thinks "well, perfect, I have the choice between four great GUI
systems". However, except for very special demands, there is no
clear winner. You start learning one, and immediately wonder
whether the other might be better. Although it sounds paradoxical,
this can be quite frustrating. After all, most of us don't have the
energy or motivation to test all candidates thoroughly.

The PEP process can be quite good for whittling this down and getting
the best of all worlds. For example, the current stdlib csv module was
based on three previous modules[1]. We only really need one.

However, since GUI toolkits are so complicated, I wonder if they will
ever be subject to this process.

[1] http://www.python.org/peps/pep-0305....isting-modules
--
Michael Hoffman

[Calvin Spealman]

The choice is GUI toolkits is largely seperate from Python. Consider
that they are just bindings to libraries that are developed completely
seperate of the language. GUI is should be seperate from the language,
and thus not bound to same expectations and desires as elements of the
language itself. Unless, of course, you're VB or Java..

On 7/29/05, Torsten Bronger <br*****@physik.rwth-aachen.de> wrote:

Hallöchen!

Michael Hoffman <ca*******@mh391.invalid> writes:

Dark Cowherd wrote:

GUI, Web development, Application Framework - it is shambles.

Yeah, I agree. When I finally make that GUI application I still
don't know whether I am going to use wx or PyGTK.

I agree, too, although I can only talk about GUI toolkits. At first
one thinks "well, perfect, I have the choice between four great GUI
systems". However, except for very special demands, there is no
clear winner. You start learning one, and immediately wonder
whether the other might be better. Although it sounds paradoxical,
this can be quite frustrating. After all, most of us don't have the
energy or motivation to test all candidates thoroughly.

Besides, development resources are shared between all projects.
This is especially sad with regard to IDEs. There are even more
IDEs/dialog editors/widget builders than Toolkits, none of them
being mature.

Is there some place to discuss topics like this? Is this the right place?

Sure, although you might want to start a new thread. ;)

At least a new subject ...

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus
--
http://mail.python.org/mailman/listinfo/python-list

[Calvin Spealman]

On 7/29/05, Dark Cowherd <da*********@gmail.com> wrote:

I am new to Python. I tried it out and think it is fantastic.
Congrats and have fun learning all there is to learn.
I really loved this from import this statements:

There should be one-- and preferably only one --obvious way to do it.

But this not true of Python.
GUI, Web development, Application Framework - it is shambles. It is so
frustrating for a person who comes from a well designed environment /
framework like Delphi.
Well, consider also that all these frameworks and similar such
projects are not Python the Language, and as such are allowed to have
a few more ways to do it. There is movement toward convergence on many
fronts, with efforts such as WSGI and the anygui package. I don't
believe there should be only one way to do a thing at the beginning,
and in many ways we are still at the beginning of many areas, but we
need to spread our collective tentacles into many ideas and try what
works.

What is great about Python is that after some time with works being
quite seperate, such as the many implementations of interfaces and
adaptation systems, we are able to converge them, as is currently
proposed and likely to occure soon. We need to test out many things
and get a feel for the use of something before we can decide what the
one way to do it should be. Python makes it easy to test all the
different waters, and then to combine them into the best solution,
when the community is ready to do so.
My organisation writes products for Small and Medium Enterprises. We
are using Delphi, we want to do more web based and Linux solutions, so
I was evaluating Python, but even though I love the language and will
probably do hobby programming using the language, I wouldnt really
recommend our organisation to plan and execute a tranisition.
Thats a shame, really.
We have been around a while and we have planned and done transitions
from Clipper to FoxproW to VB to Delphi.

From what I understand Database access was in similar shambles in

Python but a SIG took up the task and made some decisions which has
now streamlined database access in Python.

I really would love to have a Python where TOOWTDI

Is there some place to discuss topics like this? Is this the right place?
--
DarkCowherd
--
http://mail.python.org/mailman/listinfo/python-list

[Jeremy Moles]

On Fri, 2005-07-29 at 17:59 +0200, Torsten Bronger wrote:

Hallöchen!

Michael Hoffman <ca*******@mh391.invalid> writes:

Dark Cowherd wrote:

GUI, Web development, Application Framework - it is shambles.
Yeah, I agree. When I finally make that GUI application I still
don't know whether I am going to use wx or PyGTK.

I agree, too, although I can only talk about GUI toolkits. At first
one thinks "well, perfect, I have the choice between four

Four?

1. wx
2. PyGTK
3. Tk (Are you including this one even?)
4. ???

Of the few I can think of, only one would qualify as great. :)

wink<< great GUI
systems". However, except for very special demands, there is no
clear winner. You start learning one, and immediately wonder
whether the other might be better. Although it sounds paradoxical,
this can be quite frustrating. After all, most of us don't have the
energy or motivation to test all candidates thoroughly.

Besides, development resources are shared between all projects.
This is especially sad with regard to IDEs. There are even more
IDEs/dialog editors/widget builders than Toolkits, none of them
being mature.
Is there some place to discuss topics like this? Is this the right place?

Sure, although you might want to start a new thread. ;)

At least a new subject ...

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus
--
http://mail.python.org/mailman/listinfo/python-list

[Jorge Godoy]

Michael Hoffman wrote:

He spends so much space on "Create Consistent Command-Line Interfaces,"
a section that, in Python, could be replaced with a simple "Use optparse."

In Perl there's also the equivalent of optparse, but where does it guarantee
that you'll use consistent name options and design a good interface? I
think he's point is much broader than parsing input from the command line.

--
Jorge Godoy <go***@ieee.org>

[Jorge Godoy]

Jeremy Moles wrote:

Four?

1. wx
2. PyGTK
3. Tk (Are you including this one even?)
4. ???
PyQt / PyKDE.
Of the few I can think of, only one would qualify as great. :)

The fourth one? ;-)

--
Jorge Godoy <go***@ieee.org>

[Dan Sommers]

On 29 Jul 2005 07:45:33 -0700,
aa**@pythoncraft.com (Aahz) wrote:

In article <m2************@unique.fully.qualified.domain.name .yeah.right>,
Dan Sommers <[e-mail]> wrote:

Was Tim writing about developing Python itself, or about developing
other programs with Python?

Yes. (C'mon, didja really expect any other answer?)

It was a rhetorical question. :-)

Regards,
Dan

--
Dan Sommers
<http://www.tombstonezero.net/dan/>

[Jeremy Moles]

On Fri, 2005-07-29 at 14:19 -0300, Jorge Godoy wrote:

Jeremy Moles wrote:

Four?

1. wx
2. PyGTK
3. Tk (Are you including this one even?)
4. ???
PyQt / PyKDE.

Ah! Can't believe I forgot that one! :)

Of the few I can think of, only one would qualify as great. :)

The fourth one? ;-)

Hehe. :) I was going to say PyGTK... but in all honesty I'm just a GTK
fanboy who hasn't really even TRIED anything else. I remember
experimenting a few years back with compiled Qt apps in C/C++, but the
whole notion of a MOC just scared me--not that I knew enough back then
to really label it as "a bad thing", nor do I now. :)
--
Jorge Godoy <go***@ieee.org>

On Fri, Jul 29, 2005 at 01:18:10PM -0400, Jeremy Moles wrote:

On Fri, 2005-07-29 at 17:59 +0200, Torsten Bronger wrote:

one thinks "well, perfect, I have the choice between four

Four?

1. wx
2. PyGTK
3. Tk (Are you including this one even?)
4. ???

Well, QT at least. And sure there is Tk.

--
jk

[Michael Hoffman]

Jorge Godoy wrote:

Michael Hoffman wrote:

He spends so much space on "Create Consistent Command-Line Interfaces,"
a section that, in Python, could be replaced with a simple "Use optparse."

In Perl there's also the equivalent of optparse, but where does it guarantee
that you'll use consistent name options and design a good interface? I
think he's point is much broader than parsing input from the command line.

True, but a lot of his point *is* parsing input from the command line.
Consider the following points paraphrased from his article:

* Don't mix multiple ways of specifying options. (Solved by optparse)
* If a flag expects an associated value, allow an optional = between the
flag and the value. (Solved by optparse)
* Allow single-letter options to be "bundled" after a single dash.
(Solved by optparse)
* Always allow -- as a file list marker. (Solved by optparse)

And a lot of the other points are things that are made much, much,
simpler by optparse, to the point that they become somewhat obvious.
--
Michael Hoffman

[Jorge Godoy]

Michael Hoffman wrote:

True, but a lot of his point *is* parsing input from the command line.
Consider the following points paraphrased from his article:

* Don't mix multiple ways of specifying options. (Solved by optparse)
* If a flag expects an associated value, allow an optional = between the
flag and the value. (Solved by optparse)
* Allow single-letter options to be "bundled" after a single dash.
(Solved by optparse)
* Always allow -- as a file list marker. (Solved by optparse)

And a lot of the other points are things that are made much, much,
simpler by optparse, to the point that they become somewhat obvious.

Take a look at the Perl module, then. You'll see that all of these are also
solved there "automagically". I've stoped coding Perl almost 3 years ago,
and even then I never had to write anything to parse command line input by
hand.

I suggest you take a look at Getopt::Long, at CPAN.

http://search.cpan.org/~jv/Getopt-Long-2.34/
http://search.cpan.org/src/JV/Getopt-Long-2.34/README
Be seeing you,
--
Jorge Godoy <go***@ieee.org>

[Peter Hansen]

Dan Sommers wrote:

aa**@pythoncraft.com (Aahz) wrote:

Dan Sommers <[e-mail]> wrote:

Was Tim writing about developing Python itself, or about developing
other programs with Python?

Yes.

It was a rhetorical question. :-)

That's all right... Aahz gave a rhetorical answer. ;-)

-Peter

[Michael Hoffman]

Jorge Godoy wrote:

Michael Hoffman wrote:

True, but a lot of his point *is* parsing input from the command line.
Consider the following points paraphrased from his article:

* Don't mix multiple ways of specifying options. (Solved by optparse)
* If a flag expects an associated value, allow an optional = between the
flag and the value. (Solved by optparse)
* Allow single-letter options to be "bundled" after a single dash.
(Solved by optparse)
* Always allow -- as a file list marker. (Solved by optparse)

And a lot of the other points are things that are made much, much,
simpler by optparse, to the point that they become somewhat obvious.

Take a look at the Perl module, then. You'll see that all of these are also
solved there "automagically".

In that case, I think he just wasted a lot of time in the article, and
would have been better off saying "use Getopt::Long."
--
Michael Hoffman

[Jorge Godoy]

Michael Hoffman wrote:

In that case, I think he just wasted a lot of time in the article, and
would have been better off saying "use Getopt::Long."

This is why I think he was more concerned with design than implementation.

--
Jorge Godoy <go***@ieee.org>

[Torsten Bronger]

Hallöchen!

Calvin Spealman <ir********@gmail.com> writes:

The choice is GUI toolkits is largely seperate from
Python. Consider that they are just bindings to libraries that are
developed completely seperate of the language. GUI is should be
seperate from the language, and thus not bound to same
expectations and desires as elements of the language itself.

I disagree. A modern language must provide a convenient and
well-embedded way to write GUI applications. This is not a sign of
decadence, but a very good promotional argument. Delphi and first
and foremost VB are extremely popular, and it's sad to see that
Python could get a lot more of the cake if the efforts for IDEs and
toolkits were somewhat streamlined. Besides, all other already good
aspects of Python wouldn't suffer at all.

Tkinter fits into Python very well and it is very easily (if not
trivially) accessible for users of our applications. People
complain about non-native look-and-feel on Windows, but sorry, I
simply find it unacceptably ugly on all platforms. Don't
misunderstand me: I don't like neat GUI effects just for the sake of
it but Tkinter makes an outdated impression on the end-user.

I've been having a closer look at wxPython which is not Pythonic at
all and bad documented. Probably I'll use it nevertheless. PyGTK
and PyQt may have their own advantages and disadvantages.

However, in my opinion we don't need yet another binding so thin
that C or C++ is shining through, but a modern replacement for
Tkinter with its Pythonic way of thinking.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus

[matt.schinckel]

Dark Cowherd wrote:

GUI, Web development, Application Framework - it is shambles.

Yeah, I agree. When I finally make that GUI application I still don't
know whether I am going to use wx or PyGTK.

I was part of the anygui development team, back when it was still
active (I think I technically am still part of the team, we just
haven't checked in any new code since I left BeOS!).

It was a plan to allow GUI access to be as simple and 'once' as anydb
does for accessing the database systems it does.

We failed. Although we did actually have some code that was working
really well, across several platforms and GUI systems.

[Peter Decker]

On 7/30/05, Torsten Bronger <br*****@physik.rwth-aachen.de> wrote:

I've been having a closer look at wxPython which is not Pythonic at
all and bad documented. Probably I'll use it nevertheless. PyGTK
and PyQt may have their own advantages and disadvantages.

However, in my opinion we don't need yet another binding so thin
that C or C++ is shining through, but a modern replacement for
Tkinter with its Pythonic way of thinking.

I had the exact same impression when I started working with wxPython:
it looked and ran great, but I held my nose when coding in it - it
just was too un-Pythonic for my tastes. I then discovered Dabo
(http://dabodev.com), which is a full application framework, but whose
UI layer is a very Pythonic wrapper around wxPython. I've created
several apps now using Dabo, even though I haven't even looked at the
data connectivity aspects of it; the UI code works fine without it.

The authors have done such a great job I'm surprised that it hasn't
been more widely adopted. Its development is very active, and they
have great support for their users.

# p.d.

[phil hunt]

On Sat, 30 Jul 2005 08:54:59 +0200, Torsten Bronger <br*****@physik.rwth-aachen.de> wrote:

Hallöchen!

Calvin Spealman <ir********@gmail.com> writes:

The choice is GUI toolkits is largely seperate from
Python. Consider that they are just bindings to libraries that are
developed completely seperate of the language. GUI is should be
seperate from the language, and thus not bound to same
expectations and desires as elements of the language itself.
I disagree. A modern language must provide a convenient and
well-embedded way to write GUI applications. This is not a sign of
decadence, but a very good promotional argument. Delphi and first
and foremost VB are extremely popular, and it's sad to see that
Python could get a lot more of the cake if the efforts for IDEs and
toolkits were somewhat streamlined. Besides, all other already good
aspects of Python wouldn't suffer at all.

Tkinter fits into Python very well and it is very easily (if not
trivially) accessible for users of our applications. People
complain about non-native look-and-feel on Windows, but sorry, I
simply find it unacceptably ugly on all platforms. Don't
misunderstand me: I don't like neat GUI effects just for the sake of
it but Tkinter makes an outdated impression on the end-user.

I've been having a closer look at wxPython which is not Pythonic at
all and bad documented.

Tkinter is hardly brilliantly documented, IMO.
Probably I'll use it nevertheless. PyGTK
and PyQt may have their own advantages and disadvantages.

However, in my opinion we don't need yet another binding so thin
that C or C++ is shining through, but a modern replacement for
Tkinter with its Pythonic way of thinking.

How about sometihing with the same API as Tkinter (so no need to
relearn), but which looks prettier? Would that fix your gripes?

--
Email: zen19725 at zen dot co dot uk

[Torsten Bronger]

Hallöchen!

Peter Decker <py******@gmail.com> writes:

On 7/30/05, Torsten Bronger <br*****@physik.rwth-aachen.de> wrote:

I've been having a closer look at wxPython which is not Pythonic
at all and bad documented. Probably I'll use it nevertheless.
PyGTK and PyQt may have their own advantages and disadvantages.

However, in my opinion we don't need yet another binding so thin
that C or C++ is shining through, but a modern replacement for
Tkinter with its Pythonic way of thinking.

I had the exact same impression when I started working with
wxPython: [...] I then discovered Dabo (http://dabodev.com), which
is a full application framework, but whose UI layer is a very
Pythonic wrapper around wxPython. I've created several apps now
using Dabo, even though I haven't even looked at the data
connectivity aspects of it; the UI code works fine without it.

I'm aware of it (and there is Wax and maybe a third one). Actually
it illustrates my point quite well: These projects are small and
instable (Dabo has a developer basis of very few people, Wax has
only one); they are even worse documented; they add another layer
which slows down and requires the end-user to install another
package; they force you to test even more GUI approaches.

==> They contribute heavily to Dark Cowherd's observation that "it
is shambles".

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus

[Torsten Bronger]

Hallöchen!

ze******@zen.co.uk (phil hunt) writes:

[...]

How about sometihing with the same API as Tkinter (so no need to
relearn), but which looks prettier? Would that fix your gripes?

I haven't learned Tkinter. Well, I programed toy applications with
different toolkits (including Tkinter) and tried to make a rather
competent decision, that's all.

So for me, it needn't be like Tkinter. The three most important
attributes for me are Pythonic, modern (both nice-looking and
comprehensive), and non-niche.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus

[Peter Decker]

On 7/30/05, Torsten Bronger <br*****@physik.rwth-aachen.de> wrote:

I'm aware of it (and there is Wax and maybe a third one). Actually
it illustrates my point quite well: These projects are small and
instable (Dabo has a developer basis of very few people, Wax has
only one); they are even worse documented; they add another layer
which slows down and requires the end-user to install another
package; they force you to test even more GUI approaches.

Well, wxPython itself is largely the work of a single person, but I
doubt that many consider that a reason to avoid it.

As far as your comment about 'slowing down' the app, I've found that
Dabo and pure-wxPython apps run indistinguishably. Perhaps there are
some microseconds of extra processing, but I sure haven't noticed it.
And I don't think that the comment about installing another package is
fair; *anything* outside of the standard distribution requires that,
and Dabo is no more difficult than copying to site-packages.

I do agree about the documentation aspect of Dabo, though. The authors
have put together some basic stuff to get you started, but have chosen
to focus their time on continued development for the time being. But
having said that, I found that Dabo uses a very consistent syntax, and
was no more difficult to pick up than Python itself. With wxPython, I
constantly had to refer to the docs, as every class did things
slightly differently. For example, many controls have some text
associated with them. Depending on the control, you need to call
SetText(), SetLabel(), SetBitmapLabel(), SetTitle(), etc. Dabo wrapped
all of these controls so that the identifying text for each is
controlled by a single property: Caption. In any Dabo control,
executing ctl.Caption="Something" will change its associated text.
This sort of consistency removes the need to constantly refer to
documentation in order to write your code.

--

# p.d.

[Torsten Bronger]

Hallöchen!

Peter Decker <py******@gmail.com> writes:

On 7/30/05, Torsten Bronger <br*****@physik.rwth-aachen.de> wrote:

I'm aware of it (and there is Wax and maybe a third one).
Actually it illustrates my point quite well: These projects are
small and instable (Dabo has a developer basis of very few
people, Wax has only one); they are even worse documented; they
add another layer which slows down and requires the end-user to
install another package; they force you to test even more GUI
approaches.
Well, wxPython itself is largely the work of a single person, but
I doubt that many consider that a reason to avoid it.

But the developer and contributor base is much larger, so the
project has reached the critical mass.
As far as your comment about 'slowing down' the app, I've found
that Dabo and pure-wxPython apps run indistinguishably. Perhaps
there are some microseconds of extra processing, but I sure
haven't noticed it. And I don't think that the comment about
installing another package is fair; *anything* outside of the
standard distribution requires that, and Dabo is no more difficult
than copying to site-packages.

I didn't want to say that Dabo is bad. I just wanted to point out
that its presence (and the presence of comparable projects) doesn't
ease the IMO unfortunate situation with GUI toolkits for Python.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus

[Kay Schluehr]

Dark Cowherd wrote:

-Quote - Phillip J. Eby from dirtsimple.org
Python as a community is plagued by massive amounts of
wheel-reinvention. The infamous web framework proliferation problem is
just the most egregious example.

Why is Python "blessed" with so much reinvention? Because it's often
cheaper to rewrite than to reuse. Python code is easy to write, but
hard to depend on. You pretty much have to:

1. limit yourself to platforms with a suitable packaging system,
2. bundle all your dependencies into your distribution, or
3. make your users do all the work themselves

Ouch. No wonder rewriting looks easier. The only way to stop this
trend is to make it easier to reuse than to rewrite, which has been my
mission with setuptools and EasyInstall
-UnQuote

I think that Phillip misrepresents the problem a little bit, because it
is not true that there are too few reusable components that need just
another hero programmer like himself or anyone of us to implement. What
is missing is just a simple distinction that does not exist in an open
source community guided by hackers at least not on a certain level (
the PEP process would be a counter-example ) but is well known in
contemporary industry practice: some people are just writing specs. SUN
with Java for example employs people that model systems and write API
specs that are finally licenced and implemented by 3rd-party vendors.
J2EE or the JavaCard API are prominent examples. This is very different
from the just-for-fun or heroic-hacker attitude due to spare-time
programmers who create a bit of code they are interested in and leaving
the rest aside. It's not all just marketing blabla that makes Javas
success.

Kay

[Peter Decker]

On 7/30/05, Torsten Bronger <br*****@physik.rwth-aachen.de> wrote:

Well, wxPython itself is largely the work of a single person, but
I doubt that many consider that a reason to avoid it.

But the developer and contributor base is much larger, so the
project has reached the critical mass.

So until it reached that critical mass, you would have argued against
supporting it or using it? That seems to be what you're doing here.
Dabo is about a year and a half along; IMO, its progress in such a
short time frame is a very positive thing, not at all a negative.

As far as your comment about 'slowing down' the app, I've found
that Dabo and pure-wxPython apps run indistinguishably. Perhaps
there are some microseconds of extra processing, but I sure
haven't noticed it. And I don't think that the comment about
installing another package is fair; *anything* outside of the
standard distribution requires that, and Dabo is no more difficult
than copying to site-packages.

I didn't want to say that Dabo is bad. I just wanted to point out
that its presence (and the presence of comparable projects) doesn't
ease the IMO unfortunate situation with GUI toolkits for Python.

Perhaps, but I see it differently, since Dabo doesn't attempt to add a
new toolkit. I greatly preferred the look of wxPython over TkInter and
PyGtk, since I do a lot of cross-platform work. But while I liked the
results, I didn't like coding in wxPython. Dabo is giving me the best
of both worlds: a Pythonic language, and great-looking GUI apps. So I
feel that it is improving the situation with GUI toolkits for Python
in that it is allowing me to use the best toolkit without having to
write un-Pythonic code.

It would be great if the wxPython folks would adopt Dabo, and
eventually integrate it so that there is but a single, Pythonic way of
working with wxPython, but it seems that they have their hands full
just wrapping the C++ code of wxWidgets.
--

# p.d.

[Ed Leafe]

On Saturday 30 July 2005 12:28, Peter Decker wrote:

It would be great if the wxPython folks would adopt Dabo, and
eventually integrate it so that there is but a single, Pythonic way of
working with wxPython, but it seems that they have their hands full
just wrapping the C++ code of wxWidgets.

*Thanks for the vote of encouragement!
*
*Our goal isn't to muddy the waters; it is simply to create a consistent API
for coding. There is already a great GUI toolkit for Python; we're just
trying to make it easier to code.

-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com

[Torsten Bronger]

Hallöchen!

Peter Decker <py******@gmail.com> writes:

On 7/30/05, Torsten Bronger <br*****@physik.rwth-aachen.de> wrote:

[...]

I didn't want to say that Dabo is bad. I just wanted to point
out that its presence (and the presence of comparable projects)
doesn't ease the IMO unfortunate situation with GUI toolkits for
Python.
Perhaps, but I see it differently, since Dabo doesn't attempt to
add a new toolkit.

Well, effectively, it does so because from the human point of view,
the programming interface is what you have to deal with.
[...] Dabo is giving me the best of both worlds: a Pythonic
language, and great-looking GUI apps. So I feel that it is
improving the situation with GUI toolkits for Python in that it is
allowing me to use the best toolkit without having to write
un-Pythonic code.
You found a solution for you, which is a good thing. I don't want
to rule out to use Dabo myself. But in my institute I'd like to
present Python as a viable alternative to Delphi. In order to
convince people who are used to a homogeneous rock-solid system, you
must present something equivalent. Of course an open-source project
can never be as homogeneous, but I can't make the whole team switch
to a niche project, ignoring all other GUI alternatives about which
you can even buy books in German! They'll think "strange, that
Python" (or maybe "strange that Torsten" ;).
It would be great if the wxPython folks would adopt Dabo, and
eventually integrate it so that there is but a single, Pythonic
way of working with wxPython,

Yes indeed.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus