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

[Dan Sommers]

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

In article <m2************ @unique.fully.q ualified.domain .name.yeah.righ t>,
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.tombstoneze ro.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**@pythoncraf t.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********@gma il.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.