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
Steve Holden wrote:
> Now, see, that's the thing. The more ways there are to write the same
> program, the harder any given program will be to understand.
>
> This is indeed a fairly deliberate approach in the Python world, and
> contrasts with languages where readability is low because of the
> m
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:
...
> > >>> d=deque([1,2,3])
> > >>> d[:]
> > Traceback (most recent call last):
> > File "", line 1, in ?
> > TypeError: sequence index must be integer
> > >>> deque(d)
> > deque([1, 2, 3])
> > >>>
> >
> > I.e., NOT all sequences implement the unreadable x[:] form.
Alex Martelli wrote:
> <[EMAIL PROTECTED]> wrote:
>...
> > cookbook recipies of which there are already several good
> > collections, but shorter things like, copy(sequence) is spelled
> > "sequence[:]".
>
> No way:
>
> >>> from collections import deque
> >>> d=deque([1,2,3])
> >>> d[:]
> Trac
[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
On Wed, 23 Nov 2005 17:55:35 +0100, "Fredrik Lundh" <[EMAIL PROTECTED]> wrote:
>
>so how equivalent must something be to be equivalent?
>
quack, quack? ;-)
Regards,
Bengt Richter
--
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
<[EMAIL PROTECTED]> wrote:
...
> cookbook recipies of which there are already several good
> collections, but shorter things like, copy(sequence) is spelled
> "sequence[:]".
No way:
>>> from collections import deque
>>> d=deque([1,2,3])
>>> d[:]
Traceback (most recent call last):
File "", li
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
yet another :-)
Fredrik Lundh wrote:
> Steven Bethard wrote:
>
> > 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
> > u
Steven Bethard wrote:
> 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?
depends on whether
[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
38 matches
Mail list logo
