Ten Essential Development Practices

[phil hunt]

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.

I would guess that 90%+ of Python developers develop to CPython.

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.

GUI applications are a large area; and langauge that doesn't do
them tolerably well is limiting its success.

 

[Cliff Wells]

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

<snip>
commentary about how Paul wants to both not install *anything* and if he
does have to install something he must compile it from source because he
shouldn't have had to do it in the first place therefore he needs to
make it as difficult as possible and if something doesn't fit this
bizarre pattern then it sucks and we should just use tkinter instead.
</snip>

I think you are one of a kind and that any suggestions you make about
what should or shouldn't be standard in Python (i.e what would be of the
most use to the largest number of people) are to be taken with an
extremely large grain of salt. Nothing wrong with being unique, but you
just need to realize that no one else in their right mind wants to do
things your way and any attempts you make to get them to do so are
doomed to failure at best and ridicule at worst.

Regards,
Cliff

 

[Cliff Wells]

I was under the impression -- from reading this ng -- that wx was
buggy on some platforms and less portable than Tkinter. Not true?

It depends on how you define "buggy" and "portable"... also "platform"
is up for grabs too

On the serious side, I expect that if you are simply counting bugs,
there are probably more in wxPython. But I'd also say that when it
comes to ratio of bugs to features, they are probably quite comparable,
even if Tk has one bug and wxPython a hundred

As far as more portable, Tk probably wins hands-down. OTOH, in
practice, very few people care about the platforms wxPython doesn't run
on (think: GTK doesn't run there either). wxWidgets is working on a
wxUniversal port which takes a similar tack that Tk does in most cases,
that is, providing all of its own widgets based on drawing primitives,
but I have no idea how far along that is nor how long until wxPython
supports it as another target.

Regards,
Cliff

 

[Reinhold Birkenfeld]

In practise any Python GUI is going to contain code from otyher
languages since if it was coded all the way down in python it would
be too slow.

Oh, I could imagine that a MFC-like wrapper around win32gui, or another
one around Xlib wouldn't be slower that wxWidgets is today.

Reinhold

 

[Ed Leafe]

import dabo
app = dabo.dApp()
dApp.start()

 Sorry, I couldn't do it in 5.  ;-) Oh, and that includes a full menu,
too.

I get an ImportError exception when I try that.  Any suggestions?  Note
that I don't get that exception from Tkinter.
    bash-3.00$ python
    Python 2.3.4 (#1, Oct 26 2004, 16:42:40)
    [GCC 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import dabo
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
    ImportError: No module named dabo
    >>> import Tkinter
    >>>

Oh, c'mon now Paul, now you're trolling. You know exactly what the problem
is, and try to make it look like a bug.

Fine: you don't want to use anything that doesn't come standard with Python.
You've made your point. We get it. There is no need to repeat yourself
constantly.

The only point of my post was that for those without your aversion to
installing useful tools, Dabo provides a ton of functionality. Also, as my
partner Paul McNett pointed out, I could have done it in *two* lines:

import dabo
dabo.dApp().start()

;-)

 

[Marek Kubica]

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.

I cannot speak for Mac OS X, but I like GTK on Windows, it's better than
Tkinter

GTK unter Windows has been discussed not so long ago:
http://groups.google.de/group/comp....b9794/7ca38c3d89933ce9?tvc=1#7ca38c3d89933ce9

If you already tried GIMP on Windows, better try Inkscape on Windows.. that
piece of GTK software is really good.

greets,
Marek

 

[Marek Kubica]

Hello!

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

Yes, it does. I hadn't done this a long time, but it is possible. In fact,
afaik there are less problems with py2exe and wxPython than with PyGTK
(writing the setup.py was easier).

greets,
Marek

 

[Marek Kubica]

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?

It is very easy under Debian Sarge to do it.
Well after installing python-tk which needs python2.3-tk which needs blt,
tcl8.4, tk8.4 and likes to have tix8.1.

So, for a Tkinter programm you just need to install at least five packages
for a GUI toolkit which may be great for you if you like to study the
history of computing.

Not that wxPython, PyGTK, PyQt have no dependencies Bug you still can't
forget the dependency on Tcl/Tk.

greets,
Marek

 

[Cliff Wells]

If you already tried GIMP on Windows, better try Inkscape on Windows.. that
piece of GTK software is really good.

I don't do any actual work under Windows any more. My Windows VMware
session is purely for testing Windows apps and websites under Exploder.

However my girlfriend, while hating the Gimp (she prefers Photoshop, to
put it mildly), loves Inkscape and claims it is better in many ways than
Illustrator.

Regards,
Cliff

 

[Fuzzyman]

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.

Wax is small enough to distribute *with* large apps. It now has several
developers and part of the two 'google summer of code' projects working
on it will be to generate full documentation.

I find it makes writing GUI apps easier than with Tkinter and there is
no speed bottleneck form the GUI code !

All the best,

Fuzzy
http://www.voidspace.org.uk/python

 

[Christopher Subich]

I think my approach is in some sense completely typical: I don't want
to install ANYTHING, EVER. I've described this before. I want to buy
a new computer and have all the software I'll ever need already on the
hard drive, and use it from that day forward. By the time the

With all due respect, if you're allergic to installing software then why
are you a developer? To me, your view is somewhat akin to that of a
woodworker who doesn't want to buy tools, or a painter who doesn't want
to buy brushes.

Computers can be merely appliances, sure, but that's wasting the general
purpose part of computation. Software as separate packaging exists
because we (collectively) don't always know what we want the first (or
second, or third, or...) time around. And when we do know what we want,
we often muck it up when we try it.

 

[Peter Decker]

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.

Geez, can you whine some more? Most people are running wxPython just
fine, and since you "don't care enough" to bother to follow
instructions, and have some oddball religious rule about installing
binaries, it's everyone else's fault that you experience "enormous
pain".

Gimme a break.

 

[Terry Reedy]

This sort of intentional obtuseness grates on me too. Just to let you
know, this discussion has convinced me to try Dabo, which I knew nothing
about before. So your participation has not been useless. In fact, I
think I will start with your two-liner below so I can see what I get by
default and then build from there.

Terry J. Reedy

import dabo
app = dabo.dApp()
dApp.start()

Sorry, I couldn't do it in 5. ;-) Oh, and that includes a full menu,
too.

I get an ImportError exception when I try that. Any suggestions? Note
that I don't get that exception from Tkinter.
bash-3.00$ python
Python 2.3.4 (#1, Oct 26 2004, 16:42:40)
[GCC 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.Traceback (most recent call last):

Oh, c'mon now Paul, now you're trolling. You know exactly what the problem
is, and try to make it look like a bug.

Fine: you don't want to use anything that doesn't come standard with
Python.
You've made your point. We get it. There is no need to repeat yourself
constantly.

The only point of my post was that for those without your aversion to
installing useful tools, Dabo provides a ton of functionality. Also, as my
partner Paul McNett pointed out, I could have done it in *two* lines:

import dabo
dabo.dApp().start()

;-)

 

[Ed Leafe]

This sort of intentional obtuseness grates on me too.  Just to let you
know, this discussion has convinced me to try Dabo, which I knew nothing
about before.  So your participation has not been useless.  In fact, I
think I will start with your two-liner below so I can see what I get by
default and then build from there.

We have two Dabo-specific email lists: Dabo-dev is for following the latest
and greatest developments in Dabo, including notifications of all commits to
the repository; Dabo-users is for developers using the framework who have
questions/problems/comments about Dabo.

http://leafe.com/mailman/listinfo/dabo-dev
http://leafe.com/mailman/listinfo/dabo-users

 

[Devan L]

import dabo
app = dabo.dApp()
dApp.start()

Sorry, I couldn't do it in 5. ;-) Oh, and that includes a full menu,
too.

I get an ImportError exception when I try that. Any suggestions? Note
that I don't get that exception from Tkinter.
bash-3.00$ python
Python 2.3.4 (#1, Oct 26 2004, 16:42:40)
[GCC 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

import dabo

Traceback (most recent call last):

import Tkinter

Oh, c'mon now Paul, now you're trolling. You know exactly what the problem
is, and try to make it look like a bug.

Fine: you don't want to use anything that doesn't come standard with Python.
You've made your point. We get it. There is no need to repeat yourself
constantly.

The only point of my post was that for those without your aversion to
installing useful tools, Dabo provides a ton of functionality. Also, as my
partner Paul McNett pointed out, I could have done it in *two* lines:

import dabo
dabo.dApp().start()

;-)

--

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

If you're creating a new instance of your dApp(I assume its a class)
with no arguments, then effectively your just creating a default
program which is already defined in the dabo module. If you could write
it in a few, short lines of code by defining a new class, then you
might have something there.

 

[Paul McNett]

If you're creating a new instance of your dApp(I assume its a class)
with no arguments, then effectively your just creating a default
program which is already defined in the dabo module. If you could write
it in a few, short lines of code by defining a new class, then you
might have something there.

import dabo
app = dabo.dApp()
app.UI = "wx"

class MyTextBox(dabo.ui.dTextBox):
def initProperties(self):
self.Width = 200
self.Value = "Planet Earth is blue"

class MyForm(dabo.ui.dForm):
def afterInit(self):
self.addObject(MyTextBox)
def initProperties(self):
self.Caption = "Ground Control To Major Tom"

app.MainFormClass = MyForm
app.start()

 

[Kay Schluehr]

Oh, I could imagine that a MFC-like wrapper around win32gui, or another
one around Xlib wouldn't be slower that wxWidgets is today.

Reinhold

Hi Reinhold,

did You have a look at 'venster'?

http://venster.sourceforge.net/htdocs/index.html

They even dropped win32gui and worked with ctypes and the Win32API
reducing the C-footprint. For frameworks like Dabo, AnyGUI, PyGUI etc.
this would be the right level to create an abstraction layer IMO. By
the way the demo applications of venster run stable and fast on WinXP.

Kay

 

[Mark Roseman]

Because Tkinter looked like crap on OS X. Sorry, but it's hard to sell an
application that looks bad. Our target for the framework is to build
cross-platform apps that look native on each platform. Tkinter didn't measure
up in that regard.

FWIW, some people may find this page interesting, which gives you an
idea what "standard" Tk looks like on OS X, and then with adopting the
"tile" extension to Tk and a few other tweaks, which is on its way to
becoming a standard part of Tk:
http://wiki.tcl.tk/14522

There's other info and various screenshots at:
http://tktable.sourceforge.net/tile/index.html

I think the message is, Tk has been moving forward in a coherent and
focused way (finally) in terms of look and feel, which will certainly be
of great benefit to Tkinter.

Mark

 

[Mark Roseman]

How can I embed a browser in Tk (I mean a real browser, like Mozilla,

Safari, or even Exploder)? At all? On any platform? This has always
been the tradeoff for Tk.

Try this as one example:
http://wiki.tcl.tk/4094

Tk is great for learning, easy to write small, basic interfaces, less
great for deploying real world apps with sophisticated interfaces. I've
often felt that Tk was the VB of GUI toolkits: terrific for knocking out
simple stuff, but starts to bite you in the *** when you try to do the
hard stuff. wxPython is the opposite: it has a steeper learning curve,
but once you know it, you can do amazing things. For me, the long term
benefits are far more important to me than how low the startup costs
are.

I'd respectfully disagree (having done large, real-world Tk apps).
You're right that Tk has a slow learning curve, which makes it easy to
knock out simple interfaces really quickly - and generally ones that are
not too impressive looking. You can do more sophisticated ones, and
ones that blend properly into the platforms you're working on - however,
the amount of effort and learning curve increase substantially. This is
because you end up needing to do a lot more fiddling, looking at or
using any of a large number of add-on packages, etc.).

Mark

 

[Paul Rubin]

Geez, can you whine some more? Most people are running wxPython just
fine,

Most people? What percentage of actual Python users do you think have
wxPython installed? If you're really claiming it's over 50%, you're
out of your mind.