functools possibilities

[Steve Holden]

castironpi at gmail.com wrote:
> On Feb 2, 12:13 pm, Steven Bethard <steven.beth... at gmail.com> wrote:
>> castiro... at gmail.com wrote:
>>> 1. functools.partialpre: partialpre( f, x, y )( z )-> f( z, x, y )
>>> 2. functools.pare: pare( f, 1 )( x, y )-> f( y )
>>> 3. functools.parepre: parepre( f, 1 )( x, y )-> f( x )
>>> 4. functools.calling_default: calling_default( f, a, DefaultA, b )->
>>> f( a, <default 2rd arg, even if not None>, b )
>> There are lots of possibilities for functools.  If you actually want
>> anything added, you'll need to back up your suggestions with use cases.
>>   Unless something is currently in widespread use in existing Python
>> code, it's unlikely to be included in the standard library.
>>
>> STeVe
> 
> Feel, hunch, affinity, and instinct are acceptable criteria for
> judging.  Otherwise, you're someone, and you have statistics on what
> constitutes widespread use; I can tell what's good as well as you.
> 
> Guido says, "Programmer time is important."  If it saves time, on the
> whole, writing plus learning plus reading, it's likely to be included.
> 
> urllib was not "in widespread use" prior to inclusion, but they did,
> was it?
> 
> "> There are lots of possibilities for functools."
> 
> So many, in fact, they're thinking of adding a separate "wrappertools"
> module.
> 
> Monarchies are effective on small scales.  Is Python destined for the
> small-time?
> 
> I've seen these suggestions before; they did not receive impartial
> address.
> 
> Functools and the candidate "wrappertools" should be populated fairly
> liberally.

Ultimately you either have to do the work or persuade someone else to do 
it. urllib was, as far as I know, distilled from code that had been 
written to solve real-world problems.

Who knows whether Python is "destined for the small-time"? This kind of 
comment ignores the political and developmental realities: open source 
projects whose leaders don't communicate effectively with the rest of 
the developers tend to do worse. Guido is actually in pretty good touch 
with the developers, and still manages to take an interest in end-users 
of the language.

It's all very well to talk about what "should" be included, but such 
ideas need an effective champion to promote them in the user community 
and collect valid use cases to present to the developers. Without such 
work, advocacy is likely to ineffective.

This may not be ideal, but this is open source and that's by and large 
the way the process works. It does tend to reduce the kind of code bloat 
seen in proprietary products, where features are added to capture small 
individual market segments, and you end up with a monster whose users 
typically only utilize 5% of the feature set.

So roll your sleeves up and make your case! There's work to be done ...

regards
  Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/