Ten Essential Development Practices

[Paul Rubin]

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!

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.

 

[Paul Rubin]

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.

 

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

 

[Ed Leafe]

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

 

[Terry Hancock]

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.

 

[Torsten Bronger]

Hallöchen!

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.

 

[Ed Leafe]

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.

 

[Paul Rubin]

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!

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.

 

[Andrea Griffini]

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]

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]

Hallöchen!

[...]

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

 

[Cliff Wells]

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

 

[Cliff Wells]

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

 

[Cliff Wells]

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

 

[Mike Meyer]

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

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.

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.

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]

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]

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]

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