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

[Peter Hansen]

Ed Leafe wrote:

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

It would be great if the wxPython folks would adopt Dabo,

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.

The last time I checked (as I recall), at least Wax and possibly Dabo
both either lagged well behind recent wxPython developments of provide
relatively limited support, leaving out a sizable and (to me) important
number of features from what they wrapped.

Is this a remotely accurate and current picture of things? Or is it
more fair to say that by adopting Dabo (or Wax?) one really loses
nothing in terms of flexibility, and gains only improved write- and
readability?

-Peter

[Ed Leafe]

On Saturday 30 July 2005 13:41, Peter Hansen wrote:

The last time I checked (as I recall), at least Wax and possibly Dabo
both either lagged well behind recent wxPython developments of provide
relatively limited support, leaving out a sizable and (to me) important
number of features from what they wrapped.

Is this a remotely accurate and current picture of things? *Or is it
more fair to say that by adopting Dabo (or Wax?) one really loses
nothing in terms of flexibility, and gains only improved write- and
readability?

I can't speak for Wax, but you don't lose anything from wxPython when you
work with Dabo. At the very least, if there is something that wxPython has
added that has not been integrated into Dabo yet, you can still code in
native wxPython. I've taken that approach in my current work on the Visual
Designer: some of the things that I needed to do couldn't be done in Dabo.
But in the spirit of 'eating your own dogfood', I then go back into the UI
framework code and add those things, so that the Designer is ultimately 100%
Dabo code.

There are also several classes in wxPython that Dabo has not wrapped,
primarily the lower-level drawing classes and some of the newer graphics
classes, mainly because they weren't needed for a database application
framework. However, if there's a need, we'll be glad to add it.

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

[Peter Decker]

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

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" ;).

I understand the difficulty of convincing your bosses to use something
that isn't the 'most popular'. I have had many disagreements with
management who insisted that development be done in Visual Basic
instead of Python, because it was the 'standard'. Ugh.

But with any luck, enough people will discover the combination of
Python, wxPython and Dabo to reach that 'critical mass' that you
mentioned earlier. That can only make things better than they are now!
--

# p.d.

[Dennis Lee Bieber]

On 30 Jul 2005 03:34:10 -0700, ma************@gmail.com declaimed the
following in comp.lang.python:

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.
One glance at an old book from the 80s would show that
difficulty... "The Viewport Technician: A Guide to Portable Software
Design" (Michael Brian Bentley; 1988 Scott, Foresman and Co.)

The book starts with an overview of C, then goes into describing
equivalent features of Windows (3.x), GEM (!), Macintosh, Amiga, and
Apple II GS (!) with the goal of creating a workable subset interface
library (rewrite the library for each native system, and the rest of
one's code should run without change).

-- ================================================== ============ <
wl*****@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
wu******@dm.net | Bestiaria Support Staff <
================================================== ============ <
Home Page: <http://www.dm.net/~wulfraed/> <
Overflow Page: <http://wlfraed.home.netcom.com/> <

[Paul Rubin]

Peter Hansen <pe***@engcorp.com> writes:

The last time I checked (as I recall), at least Wax and possibly Dabo
both either lagged well behind recent wxPython developments of provide
relatively limited support, leaving out a sizable and (to me)
important number of features from what they wrapped.

wxPython also depends on wxWidgets which lags behind GTK.

[Peter Decker]

On 30 Jul 2005 12:06:43 -0700, Paul Rubin
<"http://phr.cx"@nospam.invalid> wrote:

wxPython also depends on wxWidgets which lags behind GTK.

Can you elaborate on that? It's been over a year since I last looked
at GTK, but I do remember not being very impressed with how it looked
on Windows and OS X.
--

# p.d.

[Jorge Godoy]

Ed Leafe wrote:

There are also several classes in wxPython that Dabo has not wrapped,
primarily the lower-level drawing classes and some of the newer graphics
classes, mainly because they weren't needed for a database application
framework. However, if there's a need, we'll be glad to add it.

If it is added, let us know. I can't think of a better way to visualize
database reports in an easy and fast way. Specially for BI.

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

[Ed Leafe]

On Saturday 30 July 2005 16:06, Jorge Godoy wrote:

If it is added, let us know. *I can't think of a better way to visualize
database reports in an easy and fast way. *Specially for BI.

What specifically are you looking for? We are working on the report writing
engine now, tying in ReportLab.

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

[Cliff Wells]

On Sat, 2005-07-30 at 12:06 -0700, Paul Rubin wrote:

Peter Hansen <pe***@engcorp.com> writes:

The last time I checked (as I recall), at least Wax and possibly Dabo
both either lagged well behind recent wxPython developments of provide
relatively limited support, leaving out a sizable and (to me)
important number of features from what they wrapped.

wxPython also depends on wxWidgets which lags behind GTK.

But how stable is GTK on systems such as Windows and OS/X? That has
been what has kept me from using it. Most GTK apps I've used on Windows
(including the venerable GIMP) are nowhere near as stable as their Linux
counterparts (although this may not be entirely the fault of GTK).
Also, GTK on OS/X requires Fink, which is a pretty hefty requirement to
place on an end user.

Regards,
Cliff
--
cl***@develix.com
http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists ::

[Jorge Godoy]

Ed Leafe wrote:

On Saturday 30 July 2005 16:06, Jorge Godoy wrote:

If it is added, let us know. Â*I can't think of a better way to visualize
database reports in an easy and fast way. Â*Specially for BI.

What specifically are you looking for? We are working on the report
writing engine now, tying in ReportLab.

Bar and line graphics, mainly. In an easy and portable way. Something that
calculates the axis scales automatically, that allows users to change some
information, add legends, put values in specific points and all those
things that are common to business graphs.

I know it is a lot complex, specially due to user interaction, but it is
doable. I have some ideas and I'll be implementing them with PyQt for some
projects, but they aren't my first priority now.
--
Jorge Godoy <go***@ieee.org>

[Ed Leafe]

On Saturday 30 July 2005 17:44, Jorge Godoy wrote:

Bar and line graphics, mainly. Â*In an easy and portable way. Â*Something
that calculates the axis scales automatically, that allows users to change
some information, add legends, put values in specific points and all those
things that are common to business graphs.

OIC - I thought that you were referring to a specific part of wxPython that
we haven't wrapped yet.

I'll defer this to my partner, Paul McNett. He's spearheading the reporting
module for Dabo, and may know of some tools that are already out there that
could generate the image, which Dabo could then display.

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

[Jorge Godoy]

Ed Leafe wrote:

I'll defer this to my partner, Paul McNett. He's spearheading the
reporting
module for Dabo, and may know of some tools that are already out there
that could generate the image, which Dabo could then display.

There are some out there. There's one implementation that is compatible
with Matlab and is also compatible with wxPython. Take a look at
matplotlib: http://matplotlib.sourceforge.net/

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

[Bugs]

Cliff Wells wrote:

But how stable is GTK on systems such as Windows and OS/X? That has
been what has kept me from using it. Most GTK apps I've used on Windows
(including the venerable GIMP) are nowhere near as stable as their Linux
counterparts (although this may not be entirely the fault of GTK).
Also, GTK on OS/X requires Fink, which is a pretty hefty requirement to
place on an end user.

wxWidgets only uses GTK on Linux. On Windows and OS X it uses native
widgets where possible.

[Mike Meyer]

Torsten Bronger <br*****@physik.rwth-aachen.de> writes:

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.

I disagree. A modern development environment aimed at developers of
desktop applications may be required to provide that; not being a
developer of desktop applications, I'm not really qualified to say. A
*language* doesn't need to provide that. I'd say that a language
providing that would limit the language. Or cause it to branch when it
got ported to platforms for which the graphics elements of the
language were totally unsuitable.

The tools for writing GUI applications belong in a library, not the
langauge.
This is not a sign of decadence, but a very good promotional argument.
But it's not required for the language to succeed. C and C++ are both
doing very well without your a well-embedded way to write GUI
applications.

However, you can get compilers for both that come bundled with a good
GUI library. Could it be that that's what you really want - someone to
distribute Python bundled with an enterprise-class GUI library and
IDE?
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 don't particularly like Tkinter, but it seems to me that it's pretty
much won. It seems to be installed on every desktop platform along
with Python. That means that if I want to distribute GUI apps, I'm
going to cause the least headache for my end users by writing them in
Tkinter.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Torsten Bronger]

Hallöchen!

Mike Meyer <mw*@mired.org> writes:

Torsten Bronger <br*****@physik.rwth-aachen.de> writes:

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.

[...]

The tools for writing GUI applications belong in a library, not
the langauge.

None of us has talked about changing syntax. However, the standard
library is part of the language unless you're really very petty.

This is not a sign of decadence, but a very good promotional
argument.

But it's not required for the language to succeed.

Today it is (except for very special-purpose languages).
C and C++ are both doing very well without your a well-embedded
way to write GUI applications.
I don't think that much money is made with new C programs. Almost
all money with C++ is made with VC which has been having a GUI
toolkit in its standard library right from the beginning. And most
money is made with VB AFAIK.
However, you can get compilers for both that come bundled with a
good GUI library. Could it be that that's what you really want -
someone to distribute Python bundled with an enterprise-class GUI
library and IDE?

Well, a nice thing to have, but besides my point.

We do have a standard library with a robust GUI package, and a
standard distribution with a so-called IDE. What I really want is a
better GUI included into the standard library.

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 don't particularly like Tkinter, but it seems to me that it's
pretty much won. It seems to be installed on every desktop
platform along with Python. That means that if I want to
distribute GUI apps, I'm going to cause the least headache for my
end users by writing them in Tkinter.

A "replacement for Tkinter" would have the same properties,
otherwise it wouldn't be a replacement.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus

[phil hunt]

On Sat, 30 Jul 2005 16:51:13 +0200, Torsten Bronger <br*****@physik.rwth-aachen.de> wrote:

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.

You mightn't have, but I suspect more Python programers who've
written GUI apps have used Tkinter than any of the other APIs.

Not that I'm a particular fan of it, it's just I like
standardisation, because then you get network effects.
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.

What you say Pythonic, what do you mean? And how do you rate
Tkinter, PyGtk, PyQt/PyKDE, wxWindows for "Pythonicness"?

--
Email: zen19725 at zen dot co dot uk

[Torsten Bronger]

Hallöchen!

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

On Sat, 30 Jul 2005 16:51:13 +0200, Torsten Bronger <br*****@physik.rwth-aachen.de> wrote:

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.

[...]

Not that I'm a particular fan of it, it's just I like
standardisation, because then you get network effects.

Me too. Therefore I'd like to see a new toolkit in the standard
library to see a new network growing. You mustn't do something like
this too often of course but I think in this case it would be the
right time.

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.

What you say Pythonic, what do you mean? And how do you rate
Tkinter, PyGtk, PyQt/PyKDE, wxWindows for "Pythonicness"?

I don't like to set arguments to -1 or NULL, but to None. I'd like
to have extensive support for keyword arguments. I don't like
mucking about with ID values. Partly this is cosmetical but partly
it's a rich source of errors.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus

[Cliff Wells]

On Sun, 2005-07-31 at 00:59 -0400, Mike Meyer wrote:

I don't particularly like Tkinter, but it seems to me that it's pretty
much won. It seems to be installed on every desktop platform along
with Python. That means that if I want to distribute GUI apps, I'm
going to cause the least headache for my end users by writing them in
Tkinter.

By this argument, we should just give up and use Visual* on Windows.

The least headache for end users comes from properly packaging your
application. End users shouldn't need to worry about installing third
party packages (or even Python for that matter). Tools such as py2exe
and Inno installer make this pretty simple on Windows, and py2app on
OS/X accomplishes the same. It should be irrelevant to end users what
libraries or tools you use to develop the app.

Regards,
Cliff

--
cl***@develix.com
http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists ::

[Cliff Wells]

On Sat, 2005-07-30 at 16:52 -0700, Bugs wrote:

Cliff Wells wrote:

But how stable is GTK on systems such as Windows and OS/X? That has
been what has kept me from using it. Most GTK apps I've used on Windows
(including the venerable GIMP) are nowhere near as stable as their Linux
counterparts (although this may not be entirely the fault of GTK).
Also, GTK on OS/X requires Fink, which is a pretty hefty requirement to
place on an end user.

wxWidgets only uses GTK on Linux. On Windows and OS X it uses native
widgets where possible.

You missed my point. I'm advocating wxPython over PyGTK for this
reason. I'm quite aware of how wxPython functions.

Regards,
Cliff

--
cl***@develix.com
http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists ::

[Paul Rubin]

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

What you say Pythonic, what do you mean? And how do you rate
Tkinter, PyGtk, PyQt/PyKDE, wxWindows for "Pythonicness"?

Tkinter is not very Pythonic because it's sort of a Frankenstein
hybrid of Python and Tcl, but at least it's there and it more or less
works. The others are non-Pythonic because they're not included in
the standard distro and therefore the Pythonic "use the included
batteries" tenet says to use Tkinter despite its flaws.

[Torsten Bronger]

Hallöchen!

Cliff Wells <cl***@develix.com> writes:

[...]

The least headache for end users comes from properly packaging your
application. End users shouldn't need to worry about installing third
party packages (or even Python for that matter). Tools such as py2exe
and Inno installer make this pretty simple on Windows, and py2app on
OS/X accomplishes the same.

Does py2exe work for all GUI libraries? It'll highly probably work
with Tkinter, and I've read that it also works with pyGTK, but does
it also work with wxPython or PyQt?

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus

[Paul Rubin]

Torsten Bronger <br*****@physik.rwth-aachen.de> writes:

Does py2exe work for all GUI libraries?

No, it's Windows-only.

[Paul Rubin]

Cliff Wells <cl***@develix.com> writes:

application. End users shouldn't need to worry about installing third
party packages (or even Python for that matter). Tools such as py2exe
and Inno installer make this pretty simple on Windows, and py2app on
OS/X accomplishes the same. It should be irrelevant to end users what
libraries or tools you use to develop the app.

What if I want to be able to write multi-platform applications without
having to deal with OS-specific packaging schemes for every OS that I
want to run on? Even if I only want to run on Linux, I don't see how
to package a wxPython application to minimize end user hassle. The
only realistic GUI's to use are Tkinter or HTTP/HTML over a local
socket talking to a user-provided web browser.

[phil hunt]

On Sun, 31 Jul 2005 08:22:23 +0200, Torsten Bronger <br*****@physik.rwth-aachen.de> wrote:

What you say Pythonic, what do you mean? And how do you rate
Tkinter, PyGtk, PyQt/PyKDE, wxWindows for "Pythonicness"?
I don't like to set arguments to -1 or NULL, but to None.

Fair enough
I'd like
to have extensive support for keyword arguments.

Tkinter has that
--
Email: zen19725 at zen dot co dot uk

[phil hunt]

On 31 Jul 2005 00:23:38 -0700, Paul Rubin <http://ph****@NOSPAM.invalid> wrote:

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

What you say Pythonic, what do you mean? And how do you rate
Tkinter, PyGtk, PyQt/PyKDE, wxWindows for "Pythonicness"?

Tkinter is not very Pythonic because it's sort of a Frankenstein
hybrid of Python and Tcl, but at least it's there and it more or less
works. The others are non-Pythonic because they're not included in
the standard distro and therefore the Pythonic "use the included
batteries" tenet says to use Tkinter despite its flaws.

OK, hows this for an idea:

1. create a new API, loosely based on the Tkinter API, but more
Pythonic

2. implement Tk using this API (probably won't be difficult because
we can use Tkinter as a base)

3. Implement bindings to Gtk and Qt/KDE using this API.

--
Email: zen19725 at zen dot co dot uk

[Torsten Bronger]

Hallöchen!

Paul Rubin <http://ph****@NOSPAM.invalid> writes:

Torsten Bronger <br*****@physik.rwth-aachen.de> writes:

Does py2exe work for all GUI libraries?

No, it's Windows-only.

However, OS'es and GUI libraries are different axes in the space of
possibilities.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus

[Robert Kern]

phil hunt wrote:

OK, hows this for an idea:

1. create a new API, loosely based on the Tkinter API, but more
Pythonic

2. implement Tk using this API (probably won't be difficult because
we can use Tkinter as a base)

3. Implement bindings to Gtk and Qt/KDE using this API.

Like PyGUI, more or less?

http://www.cosc.canterbury.ac.nz/~greg/python_gui/

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

[Paul Rubin]

Torsten Bronger <br*****@physik.rwth-aachen.de> writes:

Does py2exe work for all GUI libraries?

No, it's Windows-only.

However, OS'es and GUI libraries are different axes in the space of
possibilities.

I'm not sure what you mean. Whatever GUI library the Mac uses, py2exe
doesn't work with it, since py2exe doesn't work for Macs.

[Torsten Bronger]

Hallöchen!

Paul Rubin <http://ph****@NOSPAM.invalid> writes:

Torsten Bronger <br*****@physik.rwth-aachen.de> writes:

Does py2exe work for all GUI libraries?

No, it's Windows-only.

However, OS'es and GUI libraries are different axes in the space
of possibilities.

I'm not sure what you mean.

I didn't ask "does it work with OSX" but "does it work with wxPython
or PyQt". py2exe only creates Windows files, that's right, but why
is this important here?

Be that as it may, some Google postings suggest that it works at
least with wxPython.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus

[Paul Rubin]

Torsten Bronger <br*****@physik.rwth-aachen.de> writes:

> Does py2exe work for all GUI libraries?
No, it's Windows-only.

I didn't ask "does it work with OSX" but "does it work with wxPython
or PyQt". py2exe only creates Windows files, that's right, but why
is this important here?

You asked whether it works with all GUI libraries. If the context
limited "all" to "wxPython or PyQt", I missed that. At any rate,
I believe it does work with wxPython under Windows. I don't know
about PyQt. It doesn't work with any non-Windows libraries.

[Ed Leafe]

On Sunday 31 July 2005 01:02, phil hunt wrote:

You mightn't have, but I suspect more Python programers who've
written GUI apps have used Tkinter than any of the other APIs.

Not that I'm a particular fan of it, it's just I like
standardisation, because then you get network effects.

At PyCon DC 2004, Guido was asked about wxPython: "wxPython is the best and
most mature cross-platform GUI toolkit, given a number of constraints. The
only reason wxPython isn't the standard Python GUI toolkit is that Tkinter
was there first."

I don't think that this is a sign that we should discourage further work with
wxPython.

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

[Jorge Godoy]

Mike Meyer wrote:

[ Having GUI stuff included on a standard installation of Python ]

However, you can get compilers for both that come bundled with a good
GUI library. Could it be that that's what you really want - someone to
distribute Python bundled with an enterprise-class GUI library and
IDE?

And then you are going to have three or four different distributors of
Python using three or four different GUI toolkits and also python.org
distributing Python for free without any (or with TKinter)... Which one
will be the "standard" distributor so that it gets documented and adopted?

In an international project I see othe problems as well -- cost, logistics,
S&H, customs, etc.

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

[Terry Hancock]

On Saturday 30 July 2005 01:54 am, Torsten Bronger wrote:

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.

I know I'm diving into this conversation late, and I haven't read
the whole thread, but has someone yet mentioned the
"anygui" project? This has stalled, but it was IMHO a good idea.

It sounds as if you are re-voicing the need that instigated the
project in the first place.

http://anygui.sourceforge.net/

AFAIK, the project stalled because not enough people were
sufficiently interested in the need. Some people said that
just using wx or Tkinter was easier.

--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks http://www.anansispaceworks.com

[Torsten Bronger]

Hallöchen!

Terry Hancock <ha*****@anansispaceworks.com> writes:

On Saturday 30 July 2005 01:54 am, Torsten Bronger wrote:

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.

I know I'm diving into this conversation late, and I haven't read
the whole thread, but has someone yet mentioned the "anygui"
project? This has stalled, but it was IMHO a good idea.

I don't know exactly why this project died, but I'd start with a
Pythonic variant of wxPython. I've read many discussions about the
people who didn't like the wxPython's C++ style, so there are
chances to get fellow developers and users. You must reach the
critical mass quickly in order to get a survivable project, and
being not too far away from an existing one is a good stating point.

Possibly Dabo manages such a thing.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus

[Ed Leafe]

On Sunday 31 July 2005 10:32, Torsten Bronger wrote:

I know I'm diving into this conversation late, and I haven't read
the whole thread, but has someone yet mentioned the "anygui"
project? Â*This has stalled, but it was IMHO a good idea.

I don't know exactly why this project died, but I'd start with a

Pythonic variant of wxPython. Â*I've read many discussions about the
people who didn't like the wxPython's C++ style, so there are
chances to get fellow developers and users. Â*You must reach the
critical mass quickly in order to get a survivable project, and
being not too far away from an existing one is a good stating point.

Possibly Dabo manages such a thing.

We certainly are striving for such a goal. And while Dabo only supports
wxPython now, we've designed the UI layer so that it is toolkit-agnostic (in
theory, at least). After we have a full, robust implementation using
wxPython, we then plan on implementing Tkinter and Qt, assuming that there is
demand for those toolkits. But since UIs are incredibly complex beasts, we've
chosen to tackle one at a time, and after looking at them all and considering
different issues, we chose wxPython as the best toolkit for creating
platform-independent apps.

--

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

[Paul Rubin]

Ed Leafe <[e-mail]> writes:

But since UIs are incredibly complex beasts, we've
chosen to tackle one at a time, and after looking at them all and considering
different issues, we chose wxPython as the best toolkit for creating
platform-independent apps.

How on earth did you decide that, since tkinter actually runs out of
the box when you install Python on most platforms, and wxPython doesn't?
I can't even think about trying out Dabo unless I'm willing to go through
some enormous pain of getting wxPython to work.

[Torsten Bronger]

Hallöchen!

Paul Rubin <http://ph****@NOSPAM.invalid> writes:

Ed Leafe <[e-mail]> writes:

But since UIs are incredibly complex beasts, we've chosen to
tackle one at a time, and after looking at them all and
considering different issues, we chose wxPython as the best
toolkit for creating platform-independent apps.

How on earth did you decide that, since tkinter actually runs out
of the box when you install Python on most platforms, and wxPython
doesn't?

I can't really understand your hostility towards non-Tkinter
toolkits. In the case of wxPython, it's part of SUSE, which is
probably also true for Fedora and Mandriva. Installing is as easy
as selecting a checkbox. This covers a very great deal of Linux
users. On Windows you have to call an exe file.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus

[Andrea Griffini]

On Sun, 31 Jul 2005 02:23:39 -0700, Robert Kern <rk***@ucsd.edu>
wrote:

Like PyGUI, more or less?

http://www.cosc.canterbury.ac.nz/~greg/python_gui/

We ended up using (py)Qt, and it's a nice library
but to my eyes is a lot un-pythonic. In many
cases there are convoluted solutions that seem
to me good ideas for a C++ library, but that
just do not make any sense in Python where
the problem they solve simply do not exist.

My impression about PyGUI is that it would be
(would have been?) a nice plug for a hole in
the python offer, unfortunately I also perceive
the clear impression the authors don't (didn't?)
actually want it to be used in the real world.

Andrea

[Kay Schluehr]

Ed Leafe wrote:

On Sunday 31 July 2005 01:02, phil hunt wrote:

You mightn't have, but I suspect more Python programers who've
written GUI apps have used Tkinter than any of the other APIs.

Not that I'm a particular fan of it, it's just I like
standardisation, because then you get network effects.

At PyCon DC 2004, Guido was asked about wxPython: "wxPython is the best and
most mature cross-platform GUI toolkit, given a number of constraints. The
only reason wxPython isn't the standard Python GUI toolkit is that Tkinter
was there first."

Maybe. But Guidos intention with Python was to create a secondary
language originally - an extension language of C - ( unlike Java that
was concepted as a radically platform independent language and a
successor of C++ ). Now since Python is 15 years old, some people
start learning Python as their primary language and they begin to ask
why it does not support a native GUI toolkit like TCL with Tk i.e.
something in it's own right with just some C-modules for interfacing
with OS dependent libs ( if any - thanks to the ctypes ffi ! ) and some
other extensions for optimization and maybe scintilla for pluging it
in.

Some other people already abandoned Python not for the worst reasons:

http://www.kevin-walzer.com/pivot/entry.php?id=69

My objection with wrappers around wrappers around wrappers is that I
have no hope ever watching the ground. If some error occurs, which
layer has to be addressed? Which developing group is reponsible? My own
or that of team A, team B, team C ... ? The baroque concept is
repulsive to me and only acceptable in case of legacy code that gets
wrapped around old one and is dedicated to substitute it continously.

Kay

[Cliff Wells]

On Sun, 2005-07-31 at 10:01 +0200, Torsten Bronger wrote:

Hallöchen!

Cliff Wells <cl***@develix.com> writes:

[...]

The least headache for end users comes from properly packaging your
application. End users shouldn't need to worry about installing third
party packages (or even Python for that matter). Tools such as py2exe
and Inno installer make this pretty simple on Windows, and py2app on
OS/X accomplishes the same.

Does py2exe work for all GUI libraries? It'll highly probably work
with Tkinter, and I've read that it also works with pyGTK, but does
it also work with wxPython or PyQt?

py2exe and py2app work for wxPython at least, not sure about the other
gui toolkits.

Regards,
Cliff

--
cl***@develix.com
http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists ::

[Cliff Wells]

On Sun, 2005-07-31 at 04:23 -0700, Paul Rubin wrote:

Torsten Bronger <br*****@physik.rwth-aachen.de> writes:

> Does py2exe work for all GUI libraries?
No, it's Windows-only.

However, OS'es and GUI libraries are different axes in the space of
possibilities.

I'm not sure what you mean. Whatever GUI library the Mac uses, py2exe
doesn't work with it, since py2exe doesn't work for Macs.

py2app is the py2exe equivalent for OS/X. And it works fine with
wxPython as well.

Regards,
Cliff

--
cl***@develix.com
http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists ::

[Cliff Wells]

On Sun, 2005-07-31 at 01:08 -0700, Paul Rubin wrote:

Cliff Wells <cl***@develix.com> writes:

application. End users shouldn't need to worry about installing third
party packages (or even Python for that matter). Tools such as py2exe
and Inno installer make this pretty simple on Windows, and py2app on
OS/X accomplishes the same. It should be irrelevant to end users what
libraries or tools you use to develop the app.

What if I want to be able to write multi-platform applications without
having to deal with OS-specific packaging schemes for every OS that I
want to run on? Even if I only want to run on Linux, I don't see how
to package a wxPython application to minimize end user hassle. The
only realistic GUI's to use are Tkinter or HTTP/HTML over a local
socket talking to a user-provided web browser.

Hm. That's odd, I thought I had just finished a fairly sophisticated
app that runs on Windows, Linux and Mac OSX using wxPython... I must be
mistaken.

Regardless, if you are doing cross-platform work for *end-users* you had
better be prepared for a little pain as there is no magic bullet.

As far as Linux only apps go... if a Linux user can't figure out how to
install wxPython (which is provided in several common packaging
formats), then I suspect they are used to pain.

The bottom line is this: some people like Tk, some wxPython. Each has
advantages and disadvantages. But to claim that you *can only* do
something in one or the other only demonstrates that you haven't really
tried.

Regards,
Cliff

--
cl***@develix.com
http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists ::

[Cliff Wells]

On Sun, 2005-07-31 at 00:23 -0700, Paul Rubin wrote:

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

What you say Pythonic, what do you mean? And how do you rate
Tkinter, PyGtk, PyQt/PyKDE, wxWindows for "Pythonicness"?

Tkinter is not very Pythonic because it's sort of a Frankenstein
hybrid of Python and Tcl, but at least it's there and it more or less
works. The others are non-Pythonic because they're not included in
the standard distro and therefore the Pythonic "use the included
batteries" tenet says to use Tkinter despite its flaws.

Am I to assume that you don't use *any* third party libraries?

As far as the "use the included batteries" tenet... has Python changed
from a programming language to a cult in the few months I've been off
the list? Where are these "tenets"? I've never heard such nonsense.

Cliff
--
cl***@develix.com
http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists ::

[Mike Meyer]

Torsten Bronger <br*****@physik.rwth-aachen.de> writes:

Hallöchen!
Mike Meyer <mw*@mired.org> writes:

Torsten Bronger <br*****@physik.rwth-aachen.de> writes:

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. The tools for writing GUI applications belong in a library, not
the langauge.

None of us has talked about changing syntax. However, the standard
library is part of the language unless you're really very petty.

Or you use different Python implementations. There are four different
Python implementations in the world. Not everything in the CPYthon
standard library runs in all of them. Or are you going to claim that
someone usin Jython isn't using Python because they can't use the full
standard library? If they're using python, then the parts of the
standard library they can't use aren't part of the language. Which
calls into question everything in the standard library.

This is not a sign of decadence, but a very good promotional
argument.

But it's not required for the language to succeed.

Today it is (except for very special-purpose languages).

To put this differently, it's required if you want to succeed as a
language for the specific purpose of creating GUI applications. I'd
agree to that. But there are *lots* of other application areas around,
so limiting your definition of "success" to that one field is very
short-sighted.

C and C++ are both doing very well without your a well-embedded
way to write GUI applications.

I don't think that much money is made with new C programs. Almost
all money with C++ is made with VC which has been having a GUI
toolkit in its standard library right from the beginning. And most
money is made with VB AFAIK.

Your definition of success is clearly different than mine. You
restrict your definition of success to proprietary applications -
which I almost never use. If I were using a definition as stilted as
yours, I'd say that success was measured by the number of lines of
source code in that language that were freely available. By which
measure C is still immensely popular, because of the large number of
older applications that are written in it that are available - Python
being one such. On the other hand, I do recognize that proprietary
applications exist. The only real measure of the success of a language
is how many applications are being written in it - and that measure
will change depending on the application area in question. I'd say
Python has succeeded as a web development language, and as a systems
scripting language - and I've certainly missed some. Now that it's
available for the S60 series phone (I'm going to get one, I swear),
I'd say it's set to succeed as a development language for portable
devices. None of these are what you call "specific-purpose" areas,
just application development areas that don't need a GUI.

By restricting yourself to projects that make money, you're also
limiting the apparent success of VB. From what I can tell, most
applications written in VB are in-house tools of various kinds. That
makes it even more successful than your measure would lead you to
believe.

C++ succeeded on platforms that VC doesn't run on, so you can hardly
claim that VC was responsible for C++'s success.

Since you brought up the off-topic point of VB, I'd say that the
*most* money is made with SQL. That's based on far to many years of
watching the want ads. Almost all of them require some language other
than SQL, and a lot of those are indeed VB.

However, you can get compilers for both that come bundled with a
good GUI library. Could it be that that's what you really want -
someone to distribute Python bundled with an enterprise-class GUI
library and IDE?

Well, a nice thing to have, but besides my point.

Then you seem to have missed some of your own points. C++ succeeded
without having a standard GUI library. You claimed that that success
was because of a single distribution that included the things you are
looking for. Why can't the same thing work for Python?
We do have a standard library with a robust GUI package, and a
standard distribution with a so-called IDE. What I really want is a
better GUI included into the standard library.

I think you're the first person I've heard call IDLE an IDE. Then
again, I don't pay much attention to it. Or maybe you meant something
else.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Mike Meyer]

Cliff Wells <cl***@develix.com> writes:

On Sun, 2005-07-31 at 00:59 -0400, Mike Meyer wrote:

I don't particularly like Tkinter, but it seems to me that it's pretty
much won. It seems to be installed on every desktop platform along
with Python. That means that if I want to distribute GUI apps, I'm
going to cause the least headache for my end users by writing them in
Tkinter.
By this argument, we should just give up and use Visual* on Windows.

Not for me - my end users don't run Windows. Well, some of them may,
but for those, my distribution is even easier to use than the ones you
build with py2exe.
The least headache for end users comes from properly packaging your
application. End users shouldn't need to worry about installing third
party packages (or even Python for that matter). Tools such as py2exe
and Inno installer make this pretty simple on Windows, and py2app on
OS/X accomplishes the same. It should be irrelevant to end users what
libraries or tools you use to develop the app.

And what do I use to bundle my application for Unix? Most of the
things I build get installed on Unix servers.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Mike Meyer]

Jorge Godoy <go***@ieee.org> writes:

Mike Meyer wrote:

[ Having GUI stuff included on a standard installation of Python ]

However, you can get compilers for both that come bundled with a good
GUI library. Could it be that that's what you really want - someone to
distribute Python bundled with an enterprise-class GUI library and
IDE?
And then you are going to have three or four different distributors of
Python using three or four different GUI toolkits and also python.org
distributing Python for free without any (or with TKinter)... Which one
will be the "standard" distributor so that it gets documented and adopted?

We already have multiple distributions of Python: CPython, IronPython,
and Jython (and there's at least one more). We even have multiple
distributions of CPython, what with Active State doing their own and
the MacPython distribution. I'm not proposing a fundamental change in
the world, I'm suggesting an addition that would satisify the OPs
needs.

The "standard" distributor is whichever one your organization settles
on when it comes time to choose a Python distribution.
In an international project I see othe problems as well -- cost, logistics,
S&H, customs, etc.

None of which has stopped linux from following this path.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Mike Meyer]

Paul Rubin <http://ph****@NOSPAM.invalid> writes:

The others are non-Pythonic because they're not included in the
standard distro and therefore the Pythonic "use the included
batteries" tenet says to use Tkinter despite its flaws.

When did "use the included batteries" become pythonic? "import this"
says nothing about batteries.

Nah, using Tkinter is pythonic because "practicality beats purity".

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Cliff Wells]

On Sun, 2005-07-31 at 10:07 -0700, Kay Schluehr wrote:

Some other people already abandoned Python not for the worst reasons:

http://www.kevin-walzer.com/pivot/entry.php?id=69
Being a developer requires not only a bit of brains, but quite a bit of
tenacity as well. Apparently Kevin lacks the second.
My objection with wrappers around wrappers around wrappers is that I
have no hope ever watching the ground. If some error occurs, which
layer has to be addressed? Which developing group is reponsible? My own
or that of team A, team B, team C ... ? The baroque concept is
repulsive to me and only acceptable in case of legacy code that gets
wrapped around old one and is dedicated to substitute it continously.

Of course, Tkinter is still a wrapper around a third party library (Tk)
borrowed from a different language (Tcl) and written again in a third
language (C), much the same as wxPython.

Your concerns are valid in a theoretical sense, but in practice make
little difference. If you are using Tkinter and it exposes a bug in Tk,
then you report to the Tkinter maintainers and they will get it fixed.
The same can be said for wxPython. Robin Dunn is a wxWidgets developer
and if wxPython exposes a bug in wxWidgets, then he will be responsible
for getting that bug fixed.

As an aside, at one time, Tkinter required that Tcl be installed (and
used) in order to interface with Tk. This is no longer the case. Tk
has been abstracted into a standalone library (quite some time ago,
actually) and Python uses it pretty much the same way Tk does.

Regards,
Cliff

--
cl***@develix.com
http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists ::

[Cliff Wells]

On Sun, 2005-07-31 at 14:58 -0400, Mike Meyer wrote:

And what do I use to bundle my application for Unix? Most of the
things I build get installed on Unix servers.

You install GUI apps on Unix *servers*?

Regardless, when you say "Unix", what do you mean? You may as well say
"OS" as this term has little meaning. Linux (which flavor)? BSD? SCO?
HPUX? OS/X? Minix? Whichever way, I suspect that a bit of distutils
hacking would solve your problem.

Regards,
Cliff

--
cl***@develix.com
http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists ::

[Kay Schluehr]

Cliff Wells wrote:

My objection with wrappers around wrappers around wrappers is that I
have no hope ever watching the ground. If some error occurs, which
layer has to be addressed? Which developing group is reponsible? My own
or that of team A, team B, team C ... ? The baroque concept is
repulsive to me and only acceptable in case of legacy code that gets
wrapped around old one and is dedicated to substitute it continously.
Of course, Tkinter is still a wrapper around a third party library (Tk)
borrowed from a different language (Tcl) and written again in a third
language (C), much the same as wxPython.

Yes, sorrowly. But the discussion was focussed around another layer
above wxPython, Tkinter etc. to make those toolkits more pythonic. Ed
promised to support many GUI toolkits as backend in future ( reviving
the failed AnyGUI approach ). That's o.k. as long as tedious
maintenance is a fun job for some people and they do it right. I don't
say that Ed produces crap, but I'll be carefull and wait a couple of
years before using such kind of stuff in production code.
Your concerns are valid in a theoretical sense, but in practice make
little difference.
It makes all difference in practice. A few levels of stacking does not
hurt in theory because it is easy to abstract them away by perfect
machinery.
If you are using Tkinter and it exposes a bug in Tk,
then you report to the Tkinter maintainers and they will get it fixed.

As long as the chain of layers does not break and the conveyor-belt
rolls efficiently it's like living in theory ;)

Kay