'for every' and 'for any'

[M.-A. Lemburg]

James T. Dennis wrote:
> 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?"

You might want to check out mxTools which has quite a few
of these gimmicks implemented in C.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                   http://www.egenix.com/files/python/
Meet us at EuroPython 2002:                 http://www.europython.org/