[Python-3000] Best Practices essays

[Adam DePrince]

On Fri, 2006-03-24 at 22:13 +1200, Greg Ewing wrote:
> Adam DePrince wrote:
> 
> > Now, as for your example m * [ n * [0]], I would exclude it from a best
> > practices document.
> 
> I'm assuming he meant the best-practices document would be
> documenting how to do that *right*!

> 
> BTW, something I had in mind for the list comprehension
> syntax back when it was being developed, but didn't
> get around to pursuing, was letting you say
> 
>    [0 times n]
> 
> or for multidimensional arrays
> 
>    [[0 times m] times n]
> 
> etc. Not sure if the use cases are frequent enough to
> justify it, though.

I think that when serious users start nesting rectangles into lists of
lists, they just reach for the right tools instead.  And in my own
experience, d=dict;d[(n,m)] makes a fine two dimensional array./

I'm curious, however, what do you envision the semantics of [x times i]
being?

[x,]*i

- or -

[copy.copy( x ) for _i in xrange( i )]

Part of me likes it, but IMHO this feature shines the best at those
times that you shouldn't be using it.

> I'm assuming he meant the best-practices document would be
> documenting how to do that *right*!

But m * [n * [0 ]] already does m * [n * [ 0 ]] alright, if that's what
you really want, right?  

I propose a reference that has on the left how to do it wrong, and on
the right what you really meant.  Perhaps even a adjunct to help()
called iMeant()

Forgive, I can't ... imagine the aggregate trauma to the careers of new
python users as they searched one person's idea of a common error,
superimposing their own misunderstandings, arriving at a ... no ...
please, think of the children.

First of all, the point of my earlier post is there are different ways
of doing the same thing.  Each is right for reasons removed from the
exact task at hand; right, or "best" cannot be handed down from above.
There are many factors used in picking a way of expressing something.

In general, I've grown cynical and opposed to the term "Best Practices."
Too many gilded handcuffs, too many egos wrapped in the faux
authenticity and subtle terror of the words "That's not best practices."
My own experiences have taught me that "best practices" is a synonym for
"my kids need braces, I'm going for a promotion!" 

You know, you can destroy a "Wall Street" programmer's career by
pronouncing that phrase just right during the middle of a meeting.  The
placement doesn't even have to make sense semantically, as long as its
pronounced correctly. 

Programmer: and that concludes our database migration strategy; now,
what do you propose we do for lunch?
Boss:       Yeah, that's a good idea.
Heckler:    <ahem> Mr Programmer, your latest proposal, lunch, has
components that are inconsistent with best practices.
Boss:       <nods>
Security:   This way sir ... 

Some of our brethren still follow best practices that require, using
papyrus, code to be punched as follows:

a = 1
b = 2
c = myfunc( a, b )

Yes, it matches the "best practices" of FORTRAN compilers in years past
that couldn't quite grasp how to pass a constant by reference.  In all
all fairness, their best practices generally keep up with the times, the
punch cards are paper now and few programmers still use their teeth.

I like the idea, but there is very little space between the mistakes
that are a necessary part of the user's learning experience, and the
already existing Python Cookbook.  

What we could do, and I'd enjoy this, is to take a slightly different
tack.  Index by what users intended to do, show what they tried to write
and explain why it is wrong.  Now that would be fun, as long as we don't
call it best practices.  The hubris of that term gives me chills.  

Cheers - Adam DePrince