Ten Essential Development Practices

[Mike Meyer]

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

 

[Cliff Wells]

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

 

[Cliff Wells]

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

 

[Kay Schluehr]

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

 

[Jorge Godoy]

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.

So we don't solve the problem with a "standard" distribution and that was
the point I was trying to show.

In fact this sounds more like a joke I've heard a while ago: standards, if
you don't like the ones out there, create your own.

None of which has stopped linux from following this path.

And solve a completely different problem while sharing the very same problem
you, on the post prior to mine, was trying to solve: what is the standard
GUI on a Linux distribution? QVWM? WindowMaker? Gnome? KDE? FVWM?

 

[Cliff Wells]

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.

Well, more users means more bug reports, more feedback, more helping
hands ultimately. The wait-and-see approach, while safer, is anathema
to open source. Try it on toy apps. If it works, it works. If it
doesn't submit bug reports and help out a bit.

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.

Having used wxPython for many years (although, admittedly not yet Dabo
[but I will next time I'm doing a GUI app]), I can say that the
machinery, while rarely perfect (and what in software is?), is entirely
serviceable. I've hit my share of bugs, reported them, worked around
them, etc. I've never yet been completely stymied by any issue I've hit
with this toolkit. Dabo, being pure Python, is probably even easier to
deal with since if I did hit an issue I could probably fix it myself.

I'd say my 6 or 7 years of wxPython experience trumps your theoretical
concerns

I'm not as certain I like the "multiple backend" approach however
(supporting both wx and tk, for instance). What seems to happen with
those sorts of things is you get the intersection of functionality of
the two underlying systems with the outstanding benefits of neither.
Not to mention it makes any progress take twice as long since any
existing functionality must be replicated for each system. I'd much
prefer to see Ed focus on one or the other [wxPython of course, since

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

That can be said of any software in existence. Nearly every bit of
software you use is layered many times over.

Cliff

 

[Cliff Wells]

So we don't solve the problem with a "standard" distribution and that was
the point I was trying to show.

In fact this sounds more like a joke I've heard a while ago: standards, if
you don't like the ones out there, create your own.


And solve a completely different problem while sharing the very same problem
you, on the post prior to mine, was trying to solve: what is the standard
GUI on a Linux distribution? QVWM? WindowMaker? Gnome? KDE? FVWM?

Well, I think this exposes one of the more interesting sides of open
source software in general. For better or worse, you get choices. If
you don't like choice, you won't like open source. Many choices is
sometimes great, sometimes annoying, but the bottom line is that very
little is spoon-fed to you, and choice and flexibility are the primary
reasons most people choose open source (this was the overwhelming
verdict of a survey SuSE took a while ago). You can't even *run* Linux
without making a few basic choices (Which distro? Which architecture?
Which GUI? etc). If you really expect this to change then I expect
there are many frustrating days ahead for you. I think most end users
of Linux wish that the GNOME and KDE teams would merge (and there would
be a great benefit, I expect, in reduced duplication of effort), but
quite frankly, it ain't gonna happen, and quite probably there would be
a lot of downsides to such an event as well.

Regards,
Cliff

 

[Torsten Bronger]

Hallöchen!

[...]

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?

Well, in a way, they aren't using Python indeed. For example, most
Python books tell only partly the truth in this case.

[...]

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.

You have to take into account not only the number of application
areas, but also their respective importance.

I'm interested in a language with a big community. This is my
definition of success. It has to do with the functionality I can
expect (more contributors can create more modules and documentation)
and with future-proofness.

GUI applications seem to be the most attractive application type.
This is not only true for commercial programming. When I look at
the most agile projects on Sourceforge, almost all of them have a
GUI.

Therefore, GUI-aware languages attract much larger user bases, and
so they cater my definition of being successful.

[...] 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.

Legacy code is not a sign of success IMO because it implies a
difficult future.

[...] I'd say Python has succeeded as a web development language,
and as a systems scripting language - and I've certainly missed
some.

I don't think that Python should rely on these old strongholds. In
the biggest bookstore of our region, there is one book about Zope
but a whole bookself about PHP. And I've never used consciously a
Python system script in contrast to dozens of Perl scripts.

In contrast to PHP or Perl, I consider Python a general-purpose
language. There is its future in my opinion. However, this area is
much tougher, and you need a good GUI approach there.

[...]

[...] 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?

I just didn't say that it couldn't work. But I don't think it'll
happen, that's all.

Tschö,
Torsten.

 

[Torsten Bronger]

Hallöchen!

[...]

Well, I think this exposes one of the more interesting sides of
open source software in general. For better or worse, you get
choices. If you don't like choice, you won't like open source.

On the other hand, the GUI package bundled with Python is a regular
decision of some sort of committee.

Tschö,
Torsten.

 

[Cliff Wells]

Hallöchen!

[...]

Well, I think this exposes one of the more interesting sides of
open source software in general. For better or worse, you get
choices. If you don't like choice, you won't like open source.

On the other hand, the GUI package bundled with Python is a regular
decision of some sort of committee.

No, it's a decision made by Guido some years ago that remains in place
because it's more pain to remove than to simple leave there.

Besides, define "bundled with". My python install doesn't have it.
Tkinter was separated out sometime ago as a separate download that just
happens to have a link next to the standard installer. Having a link on
python.org hardly qualifies as "bundled with" IMO. "Bundled near" would
be more accurate.

Cliff

 

[Jorge Godoy]

Cliff Wells wrote:

Well, I think this exposes one of the more interesting sides of open
source software in general. For better or worse, you get choices. If
you don't like choice, you won't like open source. Many choices is
sometimes great, sometimes annoying, but the bottom line is that very
little is spoon-fed to you, and choice and flexibility are the primary
reasons most people choose open source (this was the overwhelming
verdict of a survey SuSE took a while ago). You can't even *run* Linux
without making a few basic choices (Which distro? Which architecture?
Which GUI? etc). If you really expect this to change then I expect
there are many frustrating days ahead for you. I think most end users
of Linux wish that the GNOME and KDE teams would merge (and there would
be a great benefit, I expect, in reduced duplication of effort), but
quite frankly, it ain't gonna happen, and quite probably there would be
a lot of downsides to such an event as well.

I agree with you. And having choices is what is good, specially because
there is no single solution for all problems.

And I find it great to have this freedom to choose specially because not
everybody share the same aesthetics idea. What some people find beautiful
I don't like and vice-versa.

 

[Paul McNett]

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.

Dabo does indeed begin to manage a pythonic wrapper to wxPython. When we
originally began Dabo, we envisioned wrapping all the major UI toolkits,
such as Tkinter, PyQt, wxPython, curses, and even http. You would define
your subclasses of the Dabo base widgets, and then at app startup you'd
specify which UI library you wanted to use. As long as your own code was
clean of UI-library-specific references your UI could render on any
supported library.

I got some minimal proof-of-concept work done about a year ago, to show
that the same code could render on wxPython as well as on Tkinter. But,
unless we get a lot more help, developer or financial, I think it's safe
to say Dabo wraps wxPython, and that's it.

Now, that was only one part of the original Dabo vision, and the other
parts of the vision may actually add too much baggage and bloat for
people just interested in the UI aspect. Dabo also provides an
Application object, a database layer, and a business object layer. Ed
and I have discussed the possibility of ripping out the UI layer and
putting it into a completely separate project for the purpose of getting
more wxPython users interested. It wouldn't be all that hard to do,
because we've kept all the UI code separate from the the other stuff by
design.

If we ever get to the "critical mass", we can start adding wrappers for
other libraries, but this vision is always going to be limited by a
"lowest common denominator" factor. But one of the other things we've
done with Dabo is keep access to the base UI-library functionality if
needed. IOW, say you are developing an app that you know will always use
wxPython. For the most part, you will be able to use pure-Dabo
properties, events, and methods to implement your UI. But, perhaps there
is something more low-level that you need to do, such as using a DC to
draw something on top of a widget, and Dabo doesn't wrap that. Dabo's UI
classes are mixins to wxPython's, and you could just import wx manually
to get access to the wx namespace and do whatever you want. While this
goes against Dabo's vision on an idealistic level, it satisfies your
needs at a practical level. You can benefit from Dabo's ease of use 80%
of the time, and resort to doing lower-level stuff only when needed.

As far as anygui goes, we only became aware of it after significant work
had already gone into Dabo. I have looked at it and I think there may be
possibility for some mindshare between the projects, but it is, alas,
always easier to reinvent the wheel yourself than to try to design by
committee.

 

[Paul McNett]

Hallöchen!




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.

I'm at a loss too: on Debian, it is a simple:

sudo apt-get install wxpython

On Redhat, you download the RPM and:

rpm -i

On Windows and Mac, you download the package and run through the wizard.

Admittedly, installing from source is more difficult than any other
project I've found, but still doable.

Tkinter was a contender, but unfortunately while it is easy to use, it
doesn't provide a modern GUI look and feel. That was a showstopper, at
least for me.

 

[Paul Rubin]

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.

No it's not on Fedora, at least FC3. I had huge trouble trying to
build it and gave up. I had similar problems on RH9.

 

[Paul Rubin]

Admittedly, installing from source is more difficult than any other
project I've found,

I'm not interested in installing from non-source. If I wanted to do
that, I'd buy a Macintosh instead of dealing with Linux.

but still doable.

I'm sure I could have gotten it to work with sufficient time spent and
teeth gnashing, but I just didn't care enough, and had more important
things to do.

 

[Paul Rubin]

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.

I can put up a Tk gui in about 5 lines of code from a stock Python
distro without having to install anything additional. How do I do
that with wxPython?

 

[Jorge Godoy]

I can put up a Tk gui in about 5 lines of code from a stock Python
distro without having to install anything additional. How do I do
that with wxPython?

You can try it here, without installing the package python-tk. And since
you need to install python-tk, there's no problem at all installing package
wxPython to achieve the same. Or kdebindings-python and using pyQt. Or
installing another RPM package -- using Apt, so you don't have to worry
about dependencies -- with a different toolkit.

I've seen SuSE, Mandriva and Conectiva with separate packages for TKinter.
I believe there are more. Unless, of course, you're first installing a
personalized Python -- and loosing this "advantage".

 

[=?ISO-8859-1?Q?Andr=E9_Roberge?=]

Paul McNett wrote:
[snip]
Well, it appears to be more than stalled!
From http://anygui.sourceforge.net/:
Note: Anygui is no longer being actively developed or supported. These
pages are not up to date.

[snip]

Now, that was only one part of the original Dabo vision, and the other
parts of the vision may actually add too much baggage and bloat for
people just interested in the UI aspect. Dabo also provides an
Application object, a database layer, and a business object layer. Ed
and I have discussed the possibility of ripping out the UI layer and
putting it into a completely separate project for the purpose of getting
more wxPython users interested. It wouldn't be all that hard to do,
because we've kept all the UI code separate from the the other stuff by
design.

Please do!

On a somewhat unrelated note: is there any "overlap"/"possibility of
collaboration" between Dabo-UI and Wax? (I have use neither, sticking
to pure wxPython so far.)

André

 

[Cliff Wells]

No it's not on Fedora, at least FC3. I had huge trouble trying to
build it and gave up. I had similar problems on RH9.

I've been installing it from the RPM's on http://wxpython.org from
around Redhat 6.2 up through FC4. I've never had an issue, except in
cases where I had screwed my Linux install up to the point of no
recovery (and I recall only once this happened, when I had decided to
use Ximian desktop around 7.3). Also the Windows and Mac installers
there seem to work just fine as well.

Regards,
Cliff

 

[Paul Rubin]

You install GUI apps on Unix *servers*?

The usual way to do that is with a web GUI, but nothing stops you from
running Tkinter on a Unix server through a remote X connection.