Re: Ten Essential Development Practices

[Kay Schluehr]

Dark Cowherd wrote:

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

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ten Essential Development Practices

[matt . schinckel]

Dark Cowherd wrote:
>> 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.

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.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ten Essential Development Practices

[Jorge Godoy]

Michael Hoffman wrote:

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

-- 
Jorge Godoy  <[EMAIL PROTECTED]>

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ten Essential Development Practices

[Michael Hoffman]

Jorge Godoy wrote:
> Michael Hoffman wrote:
> 
> 
>>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".

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."
-- 
Michael Hoffman
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ten Essential Development Practices

[Peter Hansen]

Dan Sommers wrote:
> [EMAIL PROTECTED] (Aahz) wrote:
>>Dan Sommers  <[EMAIL PROTECTED]> wrote:
>>>Was Tim writing about developing Python itself, or about developing
>>>other programs with Python?
> 
>>Yes.
> 
> It was a rhetorical question.  :-)

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

-Peter
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ten Essential Development Practices

[Jorge Godoy]

Michael Hoffman wrote:

> 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,
-- 
Jorge Godoy  <[EMAIL PROTECTED]>

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ten Essential Development Practices

[Michael Hoffman]

Jorge Godoy wrote:
> Michael Hoffman wrote:
> 
> 
>>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.

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.
-- 
Michael Hoffman
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Wheel-reinvention with Python (was: Ten Essential Development Practices)

[Jeremy Moles]

On Fri, 2005-07-29 at 14:19 -0300, Jorge Godoy wrote:
> Jeremy Moles wrote:
> 
> > Four?
> > 
> > 1. wx
> > 2. PyGTK
> > 3. Tk (Are you including this one even?)
> > 4. ???
> 
> PyQt / PyKDE.

Ah! Can't believe I forgot that one! :)

> > Of the few I can think of, only one would qualify as great. :)
> 
> 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. :)

> -- 
> Jorge Godoy  <[EMAIL PROTECTED]>
> 

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ten Essential Development Practices

[Dan Sommers]

On 29 Jul 2005 07:45:33 -0700,
[EMAIL PROTECTED] (Aahz) wrote:

> In article <[EMAIL PROTECTED]>,
> Dan Sommers  <[EMAIL PROTECTED]> wrote:
>> 
>> Was Tim writing about developing Python itself, or about developing
>> other programs with Python?

> Yes.

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

It was a rhetorical question.  :-)

Regards,
Dan

-- 
Dan Sommers

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Wheel-reinvention with Python (was: Ten Essential Development Practices)

[Jorge Godoy]

Jeremy Moles wrote:

> 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? ;-)

-- 
Jorge Godoy  <[EMAIL PROTECTED]>

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ten Essential Development Practices

[Jorge Godoy]

Michael Hoffman wrote:

> 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  <[EMAIL PROTECTED]>

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Wheel-reinvention with Python (was: Ten Essential Development Practices)

[Jeremy Moles]

On Fri, 2005-07-29 at 17:59 +0200, Torsten Bronger wrote:
> Hallöchen!
> 
> Michael Hoffman <[EMAIL PROTECTED]> writes:
> 
> > Dark Cowherd wrote:
> >
> >> 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.
> 
> 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. :)

>>wink<<

> 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.
> 
> >> Is there some place to discuss topics like this? Is this the right place?
> >
> > Sure, although you might want to start a new thread. ;)
> 
> At least a new subject ...
> 
> Tschö,
> Torsten.
> 
> -- 
> Torsten Bronger, aquisgrana, europa vetus
> -- 
> http://mail.python.org/mailman/listinfo/python-list

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ten Essential Development Practices

[Calvin Spealman]

On 7/29/05, Dark Cowherd <[EMAIL PROTECTED]> wrote:
> 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.

> 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?
> --
> DarkCowherd
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Wheel-reinvention with Python (was: Ten Essential Development Practices)

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

On 7/29/05, Torsten Bronger <[EMAIL PROTECTED]> wrote:
> Hallöchen!
> 
> Michael Hoffman <[EMAIL PROTECTED]> writes:
> 
> > Dark Cowherd wrote:
> >
> >> 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.
> 
> 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.
> 
> >> Is there some place to discuss topics like this? Is this the right place?
> >
> > Sure, although you might want to start a new thread. ;)
> 
> At least a new subject ...
> 
> Tschö,
> Torsten.
> 
> --
> Torsten Bronger, aquisgrana, europa vetus
> --
> http://mail.python.org/mailman/listinfo/python-list
-- 
http://mail.python.org/mailman/listinfo/python-list

Wheel-reinvention with Python (was: Ten Essential Development Practices)

[Torsten Bronger]

Hallöchen!

Michael Hoffman <[EMAIL PROTECTED]> writes:

> Dark Cowherd wrote:
>
>> 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.

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.

>> Is there some place to discuss topics like this? Is this the right place?
>
> Sure, although you might want to start a new thread. ;)

At least a new subject ...

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ten Essential Development Practices

[Daniel Dittmar]

Dark Cowherd wrote:
> 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ten Essential Development Practices

[Michael Hoffman]

Dark Cowherd wrote:

> 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. ;)
-- 
Michael Hoffman
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: 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?
-- 
DarkCowherd
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ten Essential Development Practices

[Bill Mill]

> although, as some argue, it's
> possible [GvR] thinks in base 9.5, that just doesn't seem Pythonic to me.

+1 QOTW

Peace
Bill Mill
[EMAIL PROTECTED]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ten Essential Development Practices

[Aahz]

In article <[EMAIL PROTECTED]>,
Dan Sommers  <[EMAIL PROTECTED]> wrote:
>
>Was Tim writing about developing Python itself, or about developing
>other programs with Python?

Yes.

(C'mon, didja really expect any other answer?)
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

The way to build large Python applications is to componentize and
loosely-couple the hell out of everything.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ten Essential Development Practices

[Tim Peters]

[Dan Sommers]
> Ok, not universal.  But as usual, Zen is not easily nailed to a tree.
> 
> Was Tim writing about developing Python itself, or about developing
> other programs with Python?

Tim was channeling Guido, and that's as far as our certain knowledge
can go.  It _seems_ reasonable to believe that since Guido's mind is,
by definition, perfectly Pythonic, any truth channeled from it
necessarily applies to all things Pythonic.

nevertheless-we-interpret-the-gods-at-our-peril-ly y'rs  - tim
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ten Essential Development Practices

[Tim Peters]

[Steve Holden]
>> If I canpoint out the obvious, the output from "import this" *is*
>> headed "The Zen of Python", so clearly it isn;t intended to be
>> universal in its applicability.

[Michael Hudson]
> It's also mistitled there, given that it was originally posted as '19
> Pythonic Theses' and nailed to, erm, something.

'Twas actually posted as "20 Pythonic Theses", although most times I
count them I find19.  Nevertheless, that there are in fact 20 was
channeled directly from Guido's perfectly Pythonic mind, so 20 there
must be.  I suspect he withheld one -- although, as some argue, it's
possible he thinks in base 9.5, that just doesn't seem Pythonic to me.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ten Essential Development Practices

[Paolino]

[EMAIL PROTECTED] wrote:
> The following url points to an article written by Damian Conway
> entitled "Ten Essential Development Practices":
> http://www.perl.com/pub/a/2005/07/14/bestpractices.html
> 
> Althought the article has Perl as a focus, I thought that some of the
> general points made might be of interest to the Python community. It
> would certainly be interesting to put together an analogous version of
> this article that centers on Python.
> 
Hmm, Perl is called a write once language, but it has thousands of 
libraries.Any comment appreciated.

That said,those points are mixing different responsabilities in writing 
code.I keep on mixing for fun:

-Writing libraries is not writing scripts.
-Writing readable,well structured,non redundant code is somewhat 
perpendicular to tests.
-Writing tests is a must for more people to work on the same code.
-Deciding the interface and writing docs before coding can be bad for 
experimental coding.
-Logic optimization can influence interfaces.
-Time optimization is a leverage to get paid in open source 
software.Never think about that for free.

Paolino





___ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ten Essential Development Practices

[Dan Sommers]

On Fri, 29 Jul 2005 10:08:15 +0100,
Steve Holden <[EMAIL PROTECTED]> wrote:

> If I canpoint out the obvious, the output from "import this" *is*
> headed "The Zen of Python", so clearly it isn;t intended to be
> universal in its applicability.

Ok, not universal.  But as usual, Zen is not easily nailed to a tree.

Was Tim writing about developing Python itself, or about developing
other programs with Python?

Regards,
Dan

-- 
Dan Sommers

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ten Essential Development Practices

[Michael Hudson]

Steve Holden <[EMAIL PROTECTED]> writes:

> If I canpoint out the obvious, the output from "import this" *is*
> headed "The Zen of Python", so clearly it isn;t intended to be
> universal in its applicability.

It's also mistitled there, given that it was originally posted as '19
Pythonic Theses' and nailed to, erm, something.

Cheers,
mwh

-- 
  Remember - if all you have is an axe, every problem looks
  like hours of fun.-- Frossie
   -- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ten Essential Development Practices

[Steve Holden]

Dan Sommers wrote:
> On Thu, 28 Jul 2005 15:35:54 -0700,
> Robert Kern <[EMAIL PROTECTED]> wrote:
> 
> 
>>That said, I made a boo-boo. The Zen of Python is really a set of
>>design principles (and some of them, like this one, are more
>>specifically *language* design principles), not Essential Development
>>Practices. That'll teach me to not RTFA.
> 
> 
> May I respectfully disagree?  The Zen applies to all aspects of software
> (and other things, too, but they're off topic here), from human readable
> reports and requirements and documentation, to GUI's, to test cases, to
> code, to database schemta, as well as the development methodology and
> practices themselves.
> 
> Sometimes you have to look at the Zen sideways, so that "implementation"
> appears to be replaced by the particular aspect or aspects (or the
> software, or just software, as a whole, for the true Masters out there)
> you happen to be working on at the time, but such is the nature of Zen.
> 
> Regards,
> Dan
> 
If I canpoint out the obvious, the output from "import this" *is* headed 
"The Zen of Python", so clearly it isn;t intended to be universal in its 
applicability.

regards
  Steve
-- 
Steve Holden   +44 150 684 7255  +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/

-- 
http://mail.python.org/mailman/listinfo/python-list

RE: Ten Essential Development Practices

[Tony Meyer]

[Robert Kern]
> Sure, and I can find programming advice in the Old Testament, 
> too, if I try hard enough
[...]
> Proverbs 28:14 JPS "Happy is the man that feareth alway; 
> but he that hardeneth his heart shall fall into evil."
> Obviously an exhortation to not ignore raised exceptions with
> "except: pass".

+1 QOTW.

=Tony.Meyer

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ten Essential Development Practices

[Robert Kern]

Dan Sommers wrote:
> On Thu, 28 Jul 2005 15:35:54 -0700,
> Robert Kern <[EMAIL PROTECTED]> wrote:
> 
>>That said, I made a boo-boo. The Zen of Python is really a set of
>>design principles (and some of them, like this one, are more
>>specifically *language* design principles), not Essential Development
>>Practices. That'll teach me to not RTFA.
> 
> May I respectfully disagree? 

No, I'm afraid that you may only disrespectfully disagree with me. I 
will not tolerate politeness. Why? Uh, my .sig quote justifies rudeness! 
Yes, that's it![1]

> The Zen applies to all aspects of software
> (and other things, too, but they're off topic here), from human readable
> reports and requirements and documentation, to GUI's, to test cases, to
> code, to database schemta, as well as the development methodology and
> practices themselves.

Sure, and I can find programming advice in the Old Testament, too, if I 
try hard enough[2]. But that doesn't change the fact that the "Essential 
Development Practices" (e.g. "Use a source control system") are in a 
different category than the Zen of Python (e.g. "Namespaces are one 
honking great idea -- let's do more of those!"). Hence Michael Hoffman's 
very good question about how he might embody that particular bit of Zen: 
it's just not applicable to the things he's doing because it's a design 
principle for Python the language, not about development (or even 
design!) in general.

Of course other pieces of the Zen are more generally applicable 
("Readability counts.") as a "development practice," but that's 
something of an accident. Usually, they're about design, sometimes 
specifically about the design of Python the language.

> Sometimes you have to look at the Zen sideways, so that "implementation"
> appears to be replaced by the particular aspect or aspects (or the
> software, or just software, as a whole, for the true Masters out there)
> you happen to be working on at the time, but such is the nature of Zen.

That's a bit too much navel-gazing for me. With enough effort, you make 
anything a symbol of anything else. But that doesn't get any code written.

[1] 
http://groups-beta.google.com/group/comp.lang.python/msg/72f205c9b6709163

[2] Proverbs 28:14 JPS "Happy is the man that feareth alway; but he that 
hardeneth his heart shall fall into evil." Obviously an exhortation to 
not ignore raised exceptions with "except: pass".

-- 
Robert Kern
[EMAIL PROTECTED]

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ten Essential Development Practices

[Peter Hansen]

Dan Sommers wrote:
> The Zen applies to all aspects of software
> (and other things, too, but they're off topic here), from human readable
> reports and requirements and documentation, to GUI's, to test cases, to
> code, to database schemta, as well as the development methodology and
> practices themselves.
> 
> Sometimes you have to look at the Zen sideways, so that "implementation"
> appears to be replaced by the particular aspect or aspects (or the
> software, or just software, as a whole, for the true Masters out there)
> you happen to be working on at the time, but such is the nature of Zen.

It also applies to Motorcycle Maintenance, of course... (as in "Zen and 
the Art of").

-Peter
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ten Essential Development Practices

[Dan Sommers]

On Thu, 28 Jul 2005 15:35:54 -0700,
Robert Kern <[EMAIL PROTECTED]> wrote:

> That said, I made a boo-boo. The Zen of Python is really a set of
> design principles (and some of them, like this one, are more
> specifically *language* design principles), not Essential Development
> Practices. That'll teach me to not RTFA.

May I respectfully disagree?  The Zen applies to all aspects of software
(and other things, too, but they're off topic here), from human readable
reports and requirements and documentation, to GUI's, to test cases, to
code, to database schemta, as well as the development methodology and
practices themselves.

Sometimes you have to look at the Zen sideways, so that "implementation"
appears to be replaced by the particular aspect or aspects (or the
software, or just software, as a whole, for the true Masters out there)
you happen to be working on at the time, but such is the nature of Zen.

Regards,
Dan

-- 
Dan Sommers

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ten Essential Development Practices

[Robert Kern]

Michael Hoffman wrote:
> Aahz wrote:
> 
>>>One of these days I'm going to figure out how to embody "Namespaces are 
>>>one honking great idea -- let's do more of those!" Then I shall be 
>>>enlightened.
>>
>>What don't you understand about it?  (This is a serious question -- I
>>can think of several answers to give you, but want to know what focus is
>>needed first.)
> 
> I wasn't expecting a serious answer to this, but here goes.
> 
> First, I wasn't a Python user when namespaces were introduced. It's hard 
> for me to even imagine Python without namespaces. Did imported modules 
> just go into the same namespace as everything else? Yuck. It's too bad 
> this happened before there were PEPs so I could understand the design 
> and what came before.

I'm pretty sure that namespaces are fundamental to the design of Python. 
I don't think there was any "before namespaces."

> Is it the fact that Python is unimaginable without namespaces that makes 
> them such a honking great idea? Aren't they somewhat of an obvious idea? 
> Several other languages have them.
> 
> Was the implementation of namespaces easy or hard to explain?

It isn't just that Python has namespaces, but that they are the 
implementation for quite a lot of things. Modules: namespaces. Classes: 
namespaces. Instances: namespaces. Scope: namespaces. It's a very 
elegant way to handle a broad class of language features very consistently.

That said, I made a boo-boo. The Zen of Python is really a set of design 
principles (and some of them, like this one, are more specifically 
*language* design principles), not Essential Development Practices. 
That'll teach me to not RTFA.

-- 
Robert Kern
[EMAIL PROTECTED]

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ten Essential Development Practices

[Michael Hoffman]

Aahz wrote:

>>One of these days I'm going to figure out how to embody "Namespaces are 
>>one honking great idea -- let's do more of those!" Then I shall be 
>>enlightened.
> 
> What don't you understand about it?  (This is a serious question -- I
> can think of several answers to give you, but want to know what focus is
> needed first.)

I wasn't expecting a serious answer to this, but here goes.

First, I wasn't a Python user when namespaces were introduced. It's hard 
for me to even imagine Python without namespaces. Did imported modules 
just go into the same namespace as everything else? Yuck. It's too bad 
this happened before there were PEPs so I could understand the design 
and what came before.

Is it the fact that Python is unimaginable without namespaces that makes 
them such a honking great idea? Aren't they somewhat of an obvious idea? 
Several other languages have them.

Was the implementation of namespaces easy or hard to explain?

I'd love to do more honking great ideas, but I'm not even sure what the 
Dutch ideal of a honking great idea is in the first place.
-- 
Michael Hoffman
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ten Essential Development Practices

[Aahz]

In article <[EMAIL PROTECTED]>,
Michael Hoffman  <[EMAIL PROTECTED]> wrote:
>Robert Kern wrote:
>>
>> import this
>> 
>> And you get 9 bonus Essential Development Practices, too! What a bargain!
>
>One of these days I'm going to figure out how to embody "Namespaces are 
>one honking great idea -- let's do more of those!" Then I shall be 
>enlightened.

What don't you understand about it?  (This is a serious question -- I
can think of several answers to give you, but want to know what focus is
needed first.)
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

The way to build large Python applications is to componentize and
loosely-couple the hell out of everything.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ten Essential Development Practices

[Dan Sommers]

On Thu, 28 Jul 2005 21:19:53 +0100,
Michael Hoffman <[EMAIL PROTECTED]> wrote:

> Robert Kern wrote:
>> import this
>> And you get 9 bonus Essential Development Practices, too! What a
>> bargain!

> One of these days I'm going to figure out how to embody "Namespaces are
> one honking great idea -- let's do more of those!" Then I shall be
> enlightened.

And when the one obvious way to do something *is* be obvious at first,
then I shall be Dutch!  

Regards,
Dan

-- 
Dan Sommers

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ten Essential Development Practices

[Michael Hoffman]

Robert Kern wrote:

> import this
> 
> And you get 9 bonus Essential Development Practices, too! What a bargain!

One of these days I'm going to figure out how to embody "Namespaces are 
one honking great idea -- let's do more of those!" Then I shall be 
enlightened.
-- 
Michael Hoffman
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ten Essential Development Practices

[Robert Kern]

[EMAIL PROTECTED] wrote:
> The following url points to an article written by Damian Conway
> entitled "Ten Essential Development Practices":
> http://www.perl.com/pub/a/2005/07/14/bestpractices.html
> 
> Althought the article has Perl as a focus, I thought that some of the
> general points made might be of interest to the Python community. It
> would certainly be interesting to put together an analogous version of
> this article that centers on Python.

import this

And you get 9 bonus Essential Development Practices, too! What a bargain!

-- 
Robert Kern
[EMAIL PROTECTED]

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ten Essential Development Practices

[Jeremy Moles]

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

Haha... I don't know why but that really made me laugh. :) Might even
use it as a sig or something... :)


> -- 
> Michael Hoffman

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ten Essential Development Practices

[Michael Hoffman]

[EMAIL PROTECTED] wrote:
> The following url points to an article written by Damian Conway
> entitled "Ten Essential Development Practices":
> http://www.perl.com/pub/a/2005/07/14/bestpractices.html
> 
> Althought the article has Perl as a focus, I thought that some of the
> general points made might be of interest to the Python community. It
> would certainly be interesting to put together an analogous version of
> this article that centers on Python.

He spends so much space on "Create Consistent Command-Line Interfaces," 
a section that, in Python, could be replaced with a simple "Use optparse."
-- 
Michael Hoffman
-- 
http://mail.python.org/mailman/listinfo/python-list

Ten Essential Development Practices

[gyromagnetic]

The following url points to an article written by Damian Conway
entitled "Ten Essential Development Practices":
http://www.perl.com/pub/a/2005/07/14/bestpractices.html

Althought the article has Perl as a focus, I thought that some of the
general points made might be of interest to the Python community. It
would certainly be interesting to put together an analogous version of
this article that centers on Python.

Best Regards,
g

-- 
http://mail.python.org/mailman/listinfo/python-list