'for every' and 'for any'

[James T. Dennis]

Oren Tirosh <oren-py-l at hishome.net> wrote:

>> Then drop those functions into your personal utility library and use 'em
>> as often as you want :)

> I don't have a personal utility library. It's on purpose. I don't have
> personalized key bindings. I try to avoid customization.  Customization is
> a big part of what makes one programmer's code difficult to maintain by
> another programmer, what makes on programmers's workstation unusable by 
> another and makes combining code from several sources difficult.

 ...

> One of the things I like about Python is that it comes with everything in
> the box. 

> 	Oren

 Yet, this very discussion proves that "everything" is not already in
 the box.  I'll grant that Python includes a very large set of batteries
 --- but I'd still say that there are many useful functions and classes
 that can still be added.

 Those should start as personal "utility" libraries, be discussed here
 and in PEPs, and (when their general utility is established) added to
 appropriate (standard or optional) libraries.

 Obviously you don't re-invent the wheel for each project that you join;
 you are re-using some code that you've used before, even if it's from 
 "finger macros."   I can see the argument in favor of adapting your
 functions to conform to local conventions and every programming team has
 to collaborate to find compatible conventions and standards for their
 projects.  Any non-trivial project (non-trivial, in this case meaning
 "requires a *team* of programmers (> 3)) is going to find some elements
 of their project that go beyond established coding conventions.  The
 alternative to "building a (domain/application specific) library" is
 to eschew code re-use.

 In this particular case the all() and every() functions that were
 presented are elegant and seem useful.  As others have pointed out the
 implementations are trivial; so the questions become: "does it 'pollute
 the namespace' to add them to the core library?" and (if so) "where would 
 we put them?"

 Personally I think that a language that support containers as first order
 data types should also include a reasonably comprehensive set of 
 functions to operate on and/or support them.  The in operator is good,
 the iteration protocol is great, the map(),zip(), and filter() functions
 are good.  Notably zip() and filter() can be done with map() (trivially
 in most cases).  I'd say that the inclusion of zip() and filter()
 argue *for* the (eventual/future) inclusion of (every() or all()) and 
 (any() or some()).