Ten Essential Development Practices

[phil hunt]

Hallöchen!



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

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

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

Tkinter is hardly brilliantly documented, IMO.

Probably I'll use it nevertheless. PyGTK
and PyQt may have their own advantages and disadvantages.

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

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

 

[Peter Decker]

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

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

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

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

# p.d.

 

[Torsten Bronger]

Hallöchen!

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

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

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

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

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

Tschö,
Torsten.

 

[Torsten Bronger]

Hallöchen!

[...]

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

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

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

Tschö,
Torsten.

 

[Peter Decker]

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

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

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

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

 

[Torsten Bronger]

Hallöchen!

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

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

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

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

Tschö,
Torsten.

 

[Kay Schluehr]

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

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

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

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

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



Kay

 

[Peter Decker]

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

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

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

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

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

 

[Ed Leafe]

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

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

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

 

[Peter Hansen]

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

 

[Torsten Bronger]

Hallöchen!

[...]

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

Perhaps, but I see it differently, since Dabo doesn't attempt to
add a new toolkit.

Well, effectively, it does so because from the human point of view,
the programming interface is what you have to deal with.

[...] Dabo is giving me the best of both worlds: a Pythonic
language, and great-looking GUI apps. So I feel that it is
improving the situation with GUI toolkits for Python in that it is
allowing me to use the best toolkit without having to write
un-Pythonic code.

You found a solution for you, which is a good thing. I don't want
to rule out to use Dabo myself. But in my institute I'd like to
present Python as a viable alternative to Delphi. In order to
convince people who are used to a homogeneous rock-solid system, you
must present something equivalent. Of course an open-source project
can never be as homogeneous, but I can't make the whole team switch
to a niche project, ignoring all other GUI alternatives about which
you can even buy books in German! They'll think "strange, that
Python" (or maybe "strange that Torsten" .

It would be great if the wxPython folks would adopt Dabo, and
eventually integrate it so that there is but a single, Pythonic
way of working with wxPython,

Yes indeed.

Tschö,
Torsten.

 

[Ed Leafe]

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]

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!

 

[Dennis Lee Bieber]

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

--

 

[Paul Rubin]

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]

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.

 

[Jorge Godoy]

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.

 

[Ed Leafe]

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]

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

 

[Jorge Godoy]

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.