On 13 juin, 14:15, Steven D'Aprano
wrote:
> Boris Borcic wrote:
> > This reminds me of an early programming experience that left me with a
> > fascination. At a time where code had to fit in a couple dozens kilobytes,
> > I once had to make significant room in what was already very tight and
> > t
Boris Borcic wrote:
> This reminds me of an early programming experience that left me with a
> fascination. At a time where code had to fit in a couple dozens kilobytes,
> I once had to make significant room in what was already very tight and
> terse code. Code factoring *did* provide the room in
Raymond Hettinger wrote:
There is a natural inclination to do the opposite. We factor code
to eliminate redundancy, but that is not always a good idea with
an API. The goal for code factoring is to minimize redundancy.
The goal for API design is having simple parts that are easily
learned and c
Steven D'Aprano wrote:
> e.g. the Wright Brothers weren't lone inventors working at a time when
> everyone knew powered flight was impossible, they were experienced
> engineers and glider-pilots who paid a lot of attention to research done
> by their many competitors.
Be careful, the idea that hum
> Possibly a *factoring*, without the "re-", just like Raymond said.
>
> Also, keep in mind that when creating a new API, you have no existing API
> to re-factor.
Exactly.
I think this has come up before, but I can't remember the answers; any
suggestions for pointer to examples of very well-desi
On Mon, 08 Jun 2009 18:30:37 +1000, Ben Finney wrote:
> Steven D'Aprano writes:
>
>> On Sun, 07 Jun 2009 16:46:23 -0700, Raymond Hettinger wrote:
>>
>> > We factor code to eliminate redundancy, but that is not always a good
>> > idea with an API. The goal for code factoring is to minimize
>> >
On Jun 8, 9:30 am, Ben Finney wrote:
[...]
>
> As originally defined by Martin Fowler, re-factoring always means the
> external behaviour is unchanged http://refactoring.com/>.
>
> So, there's no such thing as a re-factoring that changes the API.
> Anything that changes an external attribute of t
Steven D'Aprano writes:
> On Sun, 07 Jun 2009 16:46:23 -0700, Raymond Hettinger wrote:
>
> > We factor code to eliminate redundancy, but that is not always a
> > good idea with an API. The goal for code factoring is to minimize
> > redundancy. The goal for API design is having simple parts that
On Sun, 07 Jun 2009 16:46:23 -0700, Raymond Hettinger wrote:
> We factor code
> to eliminate redundancy, but that is not always a good idea with an API.
> The goal for code factoring is to minimize redundancy. The goal for API
> design is having simple parts that are easily learned and can be rea
[pataphor]
> So here is my proposed suggestion for a once and for all reconciliation
> of various functions in itertools that can not stand on their own and
> keep a straight face.
Interesting phraseology ;-) Enticing and yet fallacious in its
presumption of known and accepted usability problems.
pataphor:
> The problem is posting *this*
> function would kill my earlier repeat for sure. And it already had a
> problem with parameters < 0 (Hint: that last bug has now become a
> feature in the unpostable repeat implementation)
Be bold, kill your precedent ideas, and post the Unpostable :-)
De
On Sat, 06 Jun 2009 19:32:31 -0700, Tim Roberts wrote:
> Steven D'Aprano wrote:
>>
>>Why is it that it's (almost) always newbies with about five minutes'
>>worth of experience with Python that come up with these grandiose plans
>>to replace entire modules with a single function?
>
> Well, many g
Tim Roberts wrote:
Steven D'Aprano wrote:
Why is it that it's (almost) always newbies with about five minutes'
worth of experience with Python that come up with these grandiose plans
to replace entire modules with a single function?
Well, many great innovations in history have come from peop
Steven D'Aprano wrote:
>
>Why is it that it's (almost) always newbies with about five minutes'
>worth of experience with Python that come up with these grandiose plans
>to replace entire modules with a single function?
Well, many great innovations in history have come from people who did not
ha
On Jun 4, 6:44 pm, "Gabriel Genellina" wrote:
> En Thu, 04 Jun 2009 10:37:45 -0300, pataphor escribió:
>
> > So here is my proposed suggestion for a once and for all reconciliation
> > of various functions in itertools that can not stand on their own and
> > keep a straight face. Because of backw
On Fri, 05 Jun 2009 23:21:40 -0300, Gabriel Genellina wrote:
> En Fri, 05 Jun 2009 08:04:37 -0300, pataphor
> escribió:
>
>> But what is simple? I am currently working on a universal feature
>> creeper that could replace itertools.cycle, itertools.repeat,
>> itertools.chain and reverse and also
En Fri, 05 Jun 2009 08:04:37 -0300, pataphor escribió:
But what is simple? I am currently working on a universal feature
creeper that could replace itertools.cycle, itertools.repeat,
itertools.chain and reverse and also helps to severely cut down on
itertools.islice usage. All within virtually
Gabriel Genellina wrote:
> Ok, you're proposing a "bidimensional" repeat. I prefer to keep things
> simple, and I'd implement it in two steps.
But what is simple? I am currently working on a universal feature
creeper that could replace itertools.cycle, itertools.repeat,
itertools.chain and rever
En Thu, 04 Jun 2009 10:37:45 -0300, pataphor escribió:
So here is my proposed suggestion for a once and for all reconciliation
of various functions in itertools that can not stand on their own and
keep a straight face. Because of backwards compatibility issues we
cannot remove them but we can b
Steven D'Aprano wrote:
> I've run your test code, and I don't know what I'm supposed to be
> impressed by.
Thank you for trying out the code. That you're unimpressed actually is a
huge encouragement because code should just run the way people expect,
without unnecessary surprises.
P.
--
http:/
On Thu, 04 Jun 2009 13:37:45 +, pataphor wrote:
> This probably has a snowballs change in hell of ending up in builtins or
> even some in some module, but such things should not prevent one to try
> and present the arguments for what one thinks is right. Else one would
> end up with consequent
):
yield x
def test():
#making the case for repeat
from itertools import islice, cycle
times = 2
n = 3
cycles = 2
L = range(n)
#look ma, no islice!
print list(repeat(L, cycles))
print list(repeat(L, cycles, times))
#repeat without extra
22 matches
Mail list logo
