Steve Holden wrote:
> Magnus Lycka wrote:
> > [EMAIL PROTECTED] wrote:
> >
> >>Oh, find a need to shut other up ?
> >>
> >
> > Oh, find a need to get the last word?
> >
> > /Magnus
> >
> > P.S. Yes, this *is* a test.
>
> Looks like you hooked him, Magnus ;-)
and he is permenantly hooked
--
http
Magnus Lycka wrote:
> [EMAIL PROTECTED] wrote:
>
>>Oh, find a need to shut other up ?
>>
>
> Oh, find a need to get the last word?
>
> /Magnus
>
> P.S. Yes, this *is* a test.
Looks like you hooked him, Magnus ;-)
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC
Magnus Lycka wrote:
> [EMAIL PROTECTED] wrote:
> > Oh, find a need to shut other up ?
> >
> Oh, find a need to get the last word?
>
like you ?
--
http://mail.python.org/mailman/listinfo/python-list
[EMAIL PROTECTED] wrote:
> "Fredrik Lundh" <[EMAIL PROTECTED]> wrote:
>
>>[EMAIL PROTECTED] wrote:
>>
>>
the thing that's in favour is "then-if-else", not "if-then-else".
>>>
>>>Sorry if I confused you, I though it was clear that I meant the
>>>concept, not a specific syntactical implementatio
"Fredrik Lundh" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>
> > > the thing that's in favour is "then-if-else", not "if-then-else".
> >
> > Sorry if I confused you, I though it was clear that I meant the
> > concept, not a specific syntactical implementation.
>
> yup, but if you care r
[EMAIL PROTECTED] wrote:
> Oh, find a need to shut other up ?
>
Oh, find a need to get the last word?
/Magnus
P.S. Yes, this *is* a test.
--
http://mail.python.org/mailman/listinfo/python-list
Antoon Pardon wrote:
> What does this mean?
It means that the hammer works better if you learn how to hold
and swing it, instead of trying to modify it so that it's more
comfortable to use it in a non-optimal way.
--
http://mail.python.org/mailman/listinfo/python-list
Fredrik Lundh wrote:
> [EMAIL PROTECTED] wrote:
>
> > > the thing that's in favour is "then-if-else", not "if-then-else".
> >
> > Sorry if I confused you, I though it was clear that I meant the
> > concept, not a specific syntactical implementation.
>
> yup, but if you care readability about, the
Op 2005-11-24, Fredrik Lundh schreef <[EMAIL PROTECTED]>:
> [EMAIL PROTECTED] wrote:
>
>> > the thing that's in favour is "then-if-else", not "if-then-else".
>>
>> Sorry if I confused you, I though it was clear that I meant the
>> concept, not a specific syntactical implementation.
>
> yup, but if
[EMAIL PROTECTED] wrote:
> > the thing that's in favour is "then-if-else", not "if-then-else".
>
> Sorry if I confused you, I though it was clear that I meant the
> concept, not a specific syntactical implementation.
yup, but if you care readability about, the words order appear in
would to seem
Fredrik Lundh wrote:
> [EMAIL PROTECTED] wrote:
>
> > > maybe it's time to change "equivalent to" to "similar to", to avoid
> > > messing things up for people who reads the mostly informal library
> > > reference as if it were an ISO specification.
> >
> > That is their fault as the library refere
Fredrik Lundh wrote:
> [EMAIL PROTECTED] wrote:
>
> > led to more serious flaws like the missing if-then-else expression,
> > something I use in virtually every piece of code I write, and which
> > increases readability.
>
> you obviously need to learn more Python idioms. Python works better
> i
[EMAIL PROTECTED] wrote:
> > maybe it's time to change "equivalent to" to "similar to", to avoid
> > messing things up for people who reads the mostly informal library
> > reference as if it were an ISO specification.
>
> That is their fault as the library reference is supposed to be "(keep
> this
Fredrik Lundh wrote:
> maybe it's time to change "equivalent to" to "similar to", to avoid
> messing things up for people who reads the mostly informal library
> reference as if it were an ISO specification.
That is their fault as the library reference is supposed to be "(keep
this under your pill
> > FWIW, the itertools documentation style was intended more as a learning
> > device than as a specification. I combined regular documentation,
> > approximately equivalent generator code, examples, and recipes.
> > Hopefully, reading the module docs creates an understanding of what the
> > tool
[EMAIL PROTECTED] wrote:
> [Dave Hansen]
> > In any case, the solution seems obvious: if you want the guarantee,
> > use the tool that provides it.
>
> True enough :-)
>
> FWIW, the itertools documentation style was intended more as a learning
> device than as a specification. I combined regular
[EMAIL PROTECTED] wrote:
> Steven Bethard wrote:
>
>>[EMAIL PROTECTED] wrote:
>>
>ii. The other problem is easier to explain by example.
>Let it=iter([1,2,3,4]).
>What is the result of zip(*[it]*2)?
>The current answer is: [(1,2),(3,4)],
>but it is impossible to determine this
[Steven Bethard]
> >Then why document itertools.izip() as it is? The documentation there is
> >explicit enough to know that izip(it, it) will work as intended. Should
> >we make the documentation there less explicit to discourage people from
> >using the izip(it, it) idiom?
[Dave Hansen]
> In an
On Tue, 22 Nov 2005 23:17:31 -0700 in comp.lang.python, Steven Bethard
<[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] wrote:
[...]
>> IIRC, this was discussednd rejected in an SF bug report. It should not
>> be a defined behavior for severals reasons:
>[snip arguments about how confusing zip(it, i
Fredrik Lundh wrote:
> > (Well, ok that is not the end of the world either but it's lack is
> > irritating
> > as hell, and yes, I know that it is now back in favor.)
>
> the thing that's in favour is "then-if-else", not "if-then-else".
>
there it comes :-)
--
http://mail.python.org/mailman/li
Op 2005-11-23, Fredrik Lundh schreef <[EMAIL PROTECTED]>:
> [EMAIL PROTECTED] wrote:
>
>> led to more serious flaws like the missing if-then-else expression,
>> something I use in virtually every piece of code I write, and which
>> increases readability.
>
> you obviously need to learn more Python
[EMAIL PROTECTED] wrote:
> led to more serious flaws like the missing if-then-else expression,
> something I use in virtually every piece of code I write, and which
> increases readability.
you obviously need to learn more Python idioms. Python works better
if you use it to write Python code; n
Steven Bethard wrote:
> [EMAIL PROTECTED] wrote:
> >> > ii. The other problem is easier to explain by example.
> >> > Let it=iter([1,2,3,4]).
> >> > What is the result of zip(*[it]*2)?
> >> > The current answer is: [(1,2),(3,4)],
> >> > but it is impossible to determine this from the docs,
> >> >
[EMAIL PROTECTED] wrote:
>> > ii. The other problem is easier to explain by example.
>> > Let it=iter([1,2,3,4]).
>> > What is the result of zip(*[it]*2)?
>> > The current answer is: [(1,2),(3,4)],
>> > but it is impossible to determine this from the docs,
>> > which would allow [(1,3),(2,4)] inste
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote:
> > Well, I do too mostly. On rereading my post, it seems I overreacted
> > a bit. But the attitude I complained about I think is real, and has
> > led to more serious flaws like the missing if-then-else expression,
> > something I use in virtu
[EMAIL PROTECTED] wrote:
> Well, I do too mostly. On rereading my post, it seems I overreacted
> a bit. But the attitude I complained about I think is real, and has
> led to more serious flaws like the missing if-then-else expression,
> something I use in virtually every piece of code I write, a
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote:
> > > * It is bug-prone -- zip(x,x) behaves differently when x is a sequence
> > > and when x is an iterator (because of restartability). Don't leave
> > > landmines for your code maintainers.
> >
> > Err thanks for the advice, but they are *my*
[EMAIL PROTECTED] wrote:
> > * It is bug-prone -- zip(x,x) behaves differently when x is a sequence
> > and when x is an iterator (because of restartability). Don't leave
> > landmines for your code maintainers.
>
> Err thanks for the advice, but they are *my* code maintainers and
> I am the best
[EMAIL PROTECTED] wrote:
> > > ii. The other problem is easier to explain by example.
> > > Let it=iter([1,2,3,4]).
> > > What is the result of zip(*[it]*2)?
> > > The current answer is: [(1,2),(3,4)],
> > > but it is impossible to determine this from the docs,
> > > which would allow [(1,3)
[EMAIL PROTECTED] wrote:
> IIRC, this was discussednd rejected in an SF bug report. It should not
> be a defined behavior for severals reasons:
>
> * It is not communicative to anyone reading the code that zip(it, it)
> is creating a sequence of the form (it0, it1), (it2, it3), . . . IOW,
> it
> > ii. The other problem is easier to explain by example.
> > Let it=iter([1,2,3,4]).
> > What is the result of zip(*[it]*2)?
> > The current answer is: [(1,2),(3,4)],
> > but it is impossible to determine this from the docs,
> > which would allow [(1,3),(2,4)] instead (or indeed
> > other
[Duncan Booth]
> >>> aList = ['a', 1, 'b', 2, 'c', 3]
> >>> it = iter(aList)
> >>> zip(it, it)
>[('a', 1), ('b', 2), ('c', 3)]
[Alan Isaac]
> That behavior is currently an accident.
>http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=1121416
[Bengt Richter]
> That sa
32 matches
Mail list logo
