Ten Essential Development Practices

[Dark Cowherd]

I am new to Python. I tried it out and think it is fantastic.

I really loved this from import this statements:

There should be one-- and preferably only one --obvious way to do it.

But this not true of Python.
GUI, Web development, Application Framework - it is shambles. It is so
frustrating for a person who comes from a well designed environment /
framework like Delphi.


-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

My organisation writes products for Small and Medium Enterprises. We
are using Delphi, we want to do more web based and Linux solutions, so
I was evaluating Python, but even though I love the language and will
probably do hobby programming using the language, I wouldnt really
recommend our organisation to plan and execute a tranisition.

We have been around a while and we have planned and done transitions
from Clipper to FoxproW to VB to Delphi.

From what I understand Database access was in similar shambles in

Python but a SIG took up the task and made some decisions which has
now streamlined database access in Python.

I really would love to have a Python where TOOWTDI

Is there some place to discuss topics like this? Is this the right place?

 

[Michael Hoffman]

GUI, Web development, Application Framework - it is shambles.

Yeah, I agree. When I finally make that GUI application I still don't
know whether I am going to use wx or PyGTK.

Is there some place to discuss topics like this? Is this the right place?

Sure, although you might want to start a new thread.

 

[Daniel Dittmar]

There should be one-- and preferably only one --obvious way to do it.

But this not true of Python.
GUI, Web development, Application Framework - it is shambles. It is so

That's because there is no *obvious* way to do these.

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

In stark contrast to Java, where everybody uses standard components like
JSP, Struts, Tapestry, JSF, Spring, ...

Daniel

 

[Torsten Bronger]

Hallöchen!

Yeah, I agree. When I finally make that GUI application I still
don't know whether I am going to use wx or PyGTK.

I agree, too, although I can only talk about GUI toolkits. At first
one thinks "well, perfect, I have the choice between four great GUI
systems". However, except for very special demands, there is no
clear winner. You start learning one, and immediately wonder
whether the other might be better. Although it sounds paradoxical,
this can be quite frustrating. After all, most of us don't have the
energy or motivation to test all candidates thoroughly.

Besides, development resources are shared between all projects.
This is especially sad with regard to IDEs. There are even more
IDEs/dialog editors/widget builders than Toolkits, none of them
being mature.

Sure, although you might want to start a new thread.

At least a new subject ...

Tschö,
Torsten.

 

[Michael Hoffman]

Hallöchen!



I agree, too, although I can only talk about GUI toolkits. At first
one thinks "well, perfect, I have the choice between four great GUI
systems". However, except for very special demands, there is no
clear winner. You start learning one, and immediately wonder
whether the other might be better. Although it sounds paradoxical,
this can be quite frustrating. After all, most of us don't have the
energy or motivation to test all candidates thoroughly.

The PEP process can be quite good for whittling this down and getting
the best of all worlds. For example, the current stdlib csv module was
based on three previous modules[1]. We only really need one.

However, since GUI toolkits are so complicated, I wonder if they will
ever be subject to this process.

[1] http://www.python.org/peps/pep-0305.html#existing-modules

 

[Calvin Spealman]

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. Unless, of course, you're VB or Java..

 

[Calvin Spealman]

I am new to Python. I tried it out and think it is fantastic.

Congrats and have fun learning all there is to learn.

I really loved this from import this statements:

There should be one-- and preferably only one --obvious way to do it.

But this not true of Python.
GUI, Web development, Application Framework - it is shambles. It is so
frustrating for a person who comes from a well designed environment /
framework like Delphi.

Well, consider also that all these frameworks and similar such
projects are not Python the Language, and as such are allowed to have
a few more ways to do it. There is movement toward convergence on many
fronts, with efforts such as WSGI and the anygui package. I don't
believe there should be only one way to do a thing at the beginning,
and in many ways we are still at the beginning of many areas, but we
need to spread our collective tentacles into many ideas and try what
works.

What is great about Python is that after some time with works being
quite seperate, such as the many implementations of interfaces and
adaptation systems, we are able to converge them, as is currently
proposed and likely to occure soon. We need to test out many things
and get a feel for the use of something before we can decide what the
one way to do it should be. Python makes it easy to test all the
different waters, and then to combine them into the best solution,
when the community is ready to do so.

My organisation writes products for Small and Medium Enterprises. We
are using Delphi, we want to do more web based and Linux solutions, so
I was evaluating Python, but even though I love the language and will
probably do hobby programming using the language, I wouldnt really
recommend our organisation to plan and execute a tranisition.

Thats a shame, really.

 

[Jeremy Moles]

Hallöchen!



I agree, too, although I can only talk about GUI toolkits. At first
one thinks "well, perfect, I have the choice between four

Four?

1. wx
2. PyGTK
3. Tk (Are you including this one even?)
4. ???

Of the few I can think of, only one would qualify as great.

 

[Jorge Godoy]

He spends so much space on "Create Consistent Command-Line Interfaces,"
a section that, in Python, could be replaced with a simple "Use optparse."

In Perl there's also the equivalent of optparse, but where does it guarantee
that you'll use consistent name options and design a good interface? I
think he's point is much broader than parsing input from the command line.

 

[Jorge Godoy]

Four?

1. wx
2. PyGTK
3. Tk (Are you including this one even?)
4. ???

PyQt / PyKDE.

Of the few I can think of, only one would qualify as great.

The fourth one? ;-)

 

[Dan Sommers]

On 29 Jul 2005 07:45:33 -0700,

(C'mon, didja really expect any other answer?)

It was a rhetorical question.

Regards,
Dan

 

[Guest]

Four?

1. wx
2. PyGTK
3. Tk (Are you including this one even?)
4. ???

Well, QT at least. And sure there is Tk.

 

[Jeremy Moles]

PyQt / PyKDE.

Ah! Can't believe I forgot that one!

The fourth one? ;-)

Hehe. I was going to say PyGTK... but in all honesty I'm just a GTK
fanboy who hasn't really even TRIED anything else. I remember
experimenting a few years back with compiled Qt apps in C/C++, but the
whole notion of a MOC just scared me--not that I knew enough back then
to really label it as "a bad thing", nor do I now.

 

[Michael Hoffman]

Michael Hoffman wrote:




In Perl there's also the equivalent of optparse, but where does it guarantee
that you'll use consistent name options and design a good interface? I
think he's point is much broader than parsing input from the command line.

True, but a lot of his point *is* parsing input from the command line.
Consider the following points paraphrased from his article:

* Don't mix multiple ways of specifying options. (Solved by optparse)
* If a flag expects an associated value, allow an optional = between the
flag and the value. (Solved by optparse)
* Allow single-letter options to be "bundled" after a single dash.
(Solved by optparse)
* Always allow -- as a file list marker. (Solved by optparse)

And a lot of the other points are things that are made much, much,
simpler by optparse, to the point that they become somewhat obvious.

 

[Jorge Godoy]

True, but a lot of his point *is* parsing input from the command line.
Consider the following points paraphrased from his article:

* Don't mix multiple ways of specifying options. (Solved by optparse)
* If a flag expects an associated value, allow an optional = between the
flag and the value. (Solved by optparse)
* Allow single-letter options to be "bundled" after a single dash.
(Solved by optparse)
* Always allow -- as a file list marker. (Solved by optparse)

And a lot of the other points are things that are made much, much,
simpler by optparse, to the point that they become somewhat obvious.

Take a look at the Perl module, then. You'll see that all of these are also
solved there "automagically". I've stoped coding Perl almost 3 years ago,
and even then I never had to write anything to parse command line input by
hand.

I suggest you take a look at Getopt::Long, at CPAN.

http://search.cpan.org/~jv/Getopt-Long-2.34/
http://search.cpan.org/src/JV/Getopt-Long-2.34/README


Be seeing you,

 

[Peter Hansen]

It was a rhetorical question.

That's all right... Aahz gave a rhetorical answer. ;-)

-Peter

 

[Michael Hoffman]

Michael Hoffman wrote:



Take a look at the Perl module, then. You'll see that all of these are also
solved there "automagically".

In that case, I think he just wasted a lot of time in the article, and
would have been better off saying "use Getopt::Long."

 

[Jorge Godoy]

In that case, I think he just wasted a lot of time in the article, and
would have been better off saying "use Getopt::Long."

This is why I think he was more concerned with design than implementation.

 

[Torsten Bronger]

Hallöchen!

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

Tschö,
Torsten.

 

[matt.schinckel]

Yeah, I agree. When I finally make that GUI application I still don't
know whether I am going to use wx or PyGTK.

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.