[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.python

functools possibilities

Aaron Brady

2/2/2008 5:00:00 AM

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 )
3 Answers

Steven Bethard

2/2/2008 6:14:00 PM

0

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

Aaron Brady

2/2/2008 8:04:00 PM

0

On Feb 2, 12:13 pm, Steven Bethard <steven.beth...@gmail.com> wrote:
> castiro...@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.

Steve Holden

2/3/2008 12:10:00 PM

0

castironpi@gmail.com wrote:
> On Feb 2, 12:13 pm, Steven Bethard <steven.beth...@gmail.com> wrote:
>> castiro...@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.hold...