Arithmetic sequences in Python

[Steven Bethard]

Re: Arithmetic sequences in Python

Alex Martelli wrote:[color=blue]
> Tom Anderson <twic@urchin.ea rth.li> wrote:[color=green]
>> Sounds good. More generally, i'd be more than happy to get rid of list
>> comprehensions, letting people use list(genexp) instead. That would
>> obviously be a Py3k thing, though.[/color]
>
> I fully agree, but the BDFL has already (tentatively, I hope) Pronounced
> that the [...] form will stay in Py3K as syntax sugar for list(...).[/color]

Do you have a link for that? I hadn't seen the pronouncement, and
http://wiki.python.org/moin/Python3%2e0 still lists that as an open issue.
[color=blue]
> I find that to be a truly hateful prospect[/color]

I'm not sure I find it truly hateful, but definitely unnecessary.
TOOWTDI and all...

STeVe

[Paul Rubin]

Re: Arithmetic sequences in Python

Steven Bethard <steven.bethard @gmail.com> writes:[color=blue][color=green]
> > I fully agree, but the BDFL has already (tentatively, I hope)
> > Pronounced
> > that the [...] form will stay in Py3K as syntax sugar for list(...).
> > I find that to be a truly hateful prospect[/color]
>
> I'm not sure I find it truly hateful, but definitely
> unnecessary. TOOWTDI and all...[/color]

Well, [...] notation for regular lists (as opposed to list
comprehensions) is also unnecessary since we could use "list((a,b,c))" .

Are we -really- after syntax minimalism? And if we are, shouldn't we
just all switch to using Scheme?

[Alex Martelli]

Re: Arithmetic sequences in Python

Paul Rubin <http://phr.cx@NOSPAM.i nvalid> wrote:
...[color=blue]
> Well, [...] notation for regular lists (as opposed to list
> comprehensions) is also unnecessary since we could use "list((a,b,c))" .[/color]

Indeed, there's no reason list couldn't accept multiple arguments as an
alternative to one sequence argument, just like min and max. This would
make list(a, b, c) work just perfectly.
[color=blue]
> Are we -really- after syntax minimalism? And if we are, shouldn't we
> just all switch to using Scheme?[/color]

No, we're not after syntax minimalism (which might justify moving to
Lisp or Scheme) but syntax that's simple and readable. I see no
credibly simple and readable alternative to {a:b, c:d} dictionary
display syntax, for example; dict(((a,b),(c, d))) just wouldn't cut it,
because of the "parenthese s overload" (double entendre intended). But
list has no such problem, and there's really no added value of clarity
and readability in [a,b,c] vs list(a,b,c). And don't tell me that the
added value is that brackets "suggest lists", since they're used to
index tuples and dicts just as well;-). So the only reason they may
"suggest lists" is that you're used to that display form in Python, but
there's no real reason to HAVE a display form for lists at all, IMHO.


Alex

[André]

Re: Arithmetic sequences in Python

Alex Martelli wrote:[color=blue]
> Paul Rubin <http://phr.cx@NOSPAM.i nvalid> wrote:
> ...[color=green]
> > Well, [...] notation for regular lists (as opposed to list
> > comprehensions) is also unnecessary since we could use "list((a,b,c))" .[/color]
>[/color]
[snip] ... or should that be list(snip)?[color=blue]
> But
> list has no such problem, and there's really no added value of clarity
> and readability in [a,b,c] vs list(a,b,c). And don't tell me that the
> added value is that brackets "suggest lists", since they're used to
> index tuples and dicts just as well;-). So the only reason they may
> "suggest lists" is that you're used to that display form in Python, but
> there's no real reason to HAVE a display form for lists at all, IMHO.
>
> Alex[/color]

I'm reading this and thinking "I disagree (?!) with Alex Martelli;
[a,b,c] is so much easier to read and understand than list(a,b,c)"...

And then it dawned on me that, the first time I learned about list
comprehension (a little over a year ago, in A.M.'s Python in a
Nutshell), I had all kinds of trouble getting used to seeing right away
that the square brackets were an indication that a list was created.
At the time, I would have totally agreed that list(a,b,c) is *much*
clearer...
{or expressions like a = list(x for x in range(1)) ...}

*Now*, I prefer [], as I have been "trained" that way... but, thinking
back, and thinking about teaching Python, I'd have to agree with Alex's
point (not that anyone would care about *my* opinion ;-)

André

[Steven D'Aprano]

Re: Arithmetic sequences in Python

Steven Bethard wrote:
[color=blue]
> I'm not sure I find it truly hateful, but definitely unnecessary.
> TOOWTDI and all...[/color]

TOOWTDI Considered Harmful.

There is confusion between "There's Only One Way To Do
It" and "There's One Obvious Way To Do It". The first
is pejorative, harmful if it were true but stupid since
it is never true. There is never only one way to do
anything but the most trivial things. Perhaps there is
only one way to do a null-op, (pass), but that's about it.

Even when people mean One Obvious and not Only One, it
is still harmful because the emphasis is wrong. The
emphasis is on the *restrictive nature* of a language
which merely gives one obvious way of doing things.

The motto from the Zen of Python is far more nuanced
and sensible, although not as snappy:

"There should be one-- and preferably only one
--obvious way to do it."

The emphasis in the Zen is about *enabling* Python to
have at least one (and preferably only one) obvious
ways to do things. The Zen is about making sure that
solutions are obvious in Python; TOOWTDI is about the
paucity of solutions in the language, and I cringe
every time I see it. See the difference?


--
Steven.

[Paul Rubin]

Re: Arithmetic sequences in Python

aleax@mail.comc ast.net (Alex Martelli) writes:[color=blue][color=green]
> > Well, [...] notation for regular lists (as opposed to list
> > comprehensions) is also unnecessary since we could use "list((a,b,c))" .[/color]
>
> Indeed, there's no reason list couldn't accept multiple arguments as an
> alternative to one sequence argument, just like min and max. This would
> make list(a, b, c) work just perfectly.[/color]

What should the output of "print list(1,2,3)" be? Is there a really
good reason to make it different from the input syntax?

What should list(list(1,2,3 )) be? Should "list" really work
completely differently depending on whether it has a single arg or
multiple args?

How would you make a one-element list, which we'd currently write as [3]?
Would you have to say list((3,))?
[color=blue]
> I see no credibly simple and readable alternative to {a:b, c:d}
> dictionary display syntax, for example; dict(((a,b),(c, d))) just
> wouldn't cut it, because of the "parenthese s overload" (double
> entendre intended).[/color]

dict(a=b,c=d)

I don't really see why keyword arg names have to be identifiers
either. foo(3=4) can pass a **kwargs containing {3:4}.
[color=blue]
> But list has no such problem, and there's really no added value of
> clarity and readability in [a,b,c] vs list(a,b,c).[/color]

That's subjective at best. Even Scheme doesn't make you use
extra keywords to write something as fundamental as a list. ;-)
[color=blue]
> So the only reason they may "suggest lists" is that you're used to
> that display form in Python, but there's no real reason to HAVE a
> display form for lists at all, IMHO.[/color]

Well, what's supposed to happen when you print a list then?

[Alex Martelli]

Re: Arithmetic sequences in Python

Paul Rubin <http://phr.cx@NOSPAM.i nvalid> wrote:
...[color=blue]
> What should the output of "print list(1,2,3)" be? Is there a really
> good reason to make it different from the input syntax?[/color]

If we assume that str and repr must keep coinciding for lists (and why
not), no reason -- just like, say, today:
[color=blue][color=green][color=darkred]
>>> print set([1,2,3])[/color][/color][/color]
set([1, 2, 3])

input and output could be identical. Do YOU have any good reason why
sets should print out as set(...) and lists should NOT print out as
list(...)? Is 'list' somehow "deeper" than 'set', to deserve a special
display-form syntax which 'set' doesn't get? Or are you enshrining a
historical accident to the level of an erroneously assumed principle?
[color=blue]
> What should list(list(1,2,3 )) be? Should "list" really work
> completely differently depending on whether it has a single arg or
> multiple args?[/color]

It works just fine for max and min, why should list be different?
[color=blue]
> How would you make a one-element list, which we'd currently write as [3]?
> Would you have to say list((3,))?[/color]

Yep. I don't particularly like the "mandatory trailing comma" in the
tuple's display form, mind you, but, if it's good enough for tuples, and
good enough for sets (how else would you make a one-element set?), it's
good enough for lists too. If we can find a nicer singleton-form, let's
apply it uniformly to all genexps, and list(<niceform> ) will be fine!-)

[color=blue][color=green]
> > I see no credibly simple and readable alternative to {a:b, c:d}
> > dictionary display syntax, for example; dict(((a,b),(c, d))) just
> > wouldn't cut it, because of the "parenthese s overload" (double
> > entendre intended).[/color]
>
> dict(a=b,c=d)
>
> I don't really see why keyword arg names have to be identifiers
> either. foo(3=4) can pass a **kwargs containing {3:4}.[/color]

I much prefer the current arrangement where dict(a=b,c=d) means {'a':b,
'c':d} -- it's much more congruent to how named arguments work for every
other case. Would you force us to quote argument names in EVERY
functioncall... ?!

[color=blue][color=green]
> > But list has no such problem, and there's really no added value of
> > clarity and readability in [a,b,c] vs list(a,b,c).[/color]
>
> That's subjective at best. Even Scheme doesn't make you use
> extra keywords to write something as fundamental as a list. ;-)[/color]

In Python, a list is no more fundamental than a dict or a set (in maths,
I guess a set IS more fundamental, of course, but Python's not
necessarily congruent to maths). Only tuples deserve special treatment
on semantical grounds (as they're used to pass multiple arguments to
functions or return multiple values for function). Of course "it's
subjective" -- obviously, some people prize conciseness above everything
else (otherwise APL and its successors would have been stillborn),
others prize verbosity (or else Cobol would never have been coinceived);
but Python's "Middle Way" tends to strike a good balance. IMHO, the
balance would be better served by spelling list(1,2,3) rather than
[1,2,3] (but the BDFL disagrees, so my opinion doesn't matter much).

[color=blue][color=green]
> > So the only reason they may "suggest lists" is that you're used to
> > that display form in Python, but there's no real reason to HAVE a
> > display form for lists at all, IMHO.[/color]
>
> Well, what's supposed to happen when you print a list then?[/color]

Just the same as when you print a set: <typename>(<arg s>).


Alex

[Antoon Pardon]

Re: Arithmetic sequences in Python

Op 2006-01-19, Alex Martelli schreef <aleax@mail.com cast.net>:
[color=blue][color=green]
>> What should list(list(1,2,3 )) be? Should "list" really work
>> completely differently depending on whether it has a single arg or
>> multiple args?[/color]
>
> It works just fine for max and min, why should list be different?[/color]

Well IMO it works fine for max and min because people rarely want
the minimum or maximum over a sequence of tuples or lists.

But how would you make the following list: [(1,3)]

As far as I understand that would have to become:

list(((1,3),))

And [[3]] would have to become:

list((list((3,) ),))


In my opinion the bracket notation wins the clarity contest
handsdown in this case and IMO these cases occure frequently
enough.

--
Antoon Pardon

[Paul Rubin]

Re: Arithmetic sequences in Python

Antoon Pardon <apardon@forel. vub.ac.be> writes:[color=blue]
> And [[3]] would have to become:
> list((list((3,) ),))
> In my opinion the bracket notation wins the clarity contest
> handsdown in this case and IMO these cases occure frequently
> enough.[/color]

I'm convinced now. Until that, I could have gone either way.

[Steven D'Aprano]

Re: Arithmetic sequences in Python

Alex Martelli wrote:
[color=blue]
> I much prefer the current arrangement where dict(a=b,c=d) means {'a':b,
> 'c':d} -- it's much more congruent to how named arguments work for every
> other case. Would you force us to quote argument names in EVERY
> functioncall... ?![/color]


Hmmm... should these two forms give different results?
[color=blue][color=green][color=darkred]
>>> a = 0
>>> b = 1
>>> A = {a: b}
>>> B = dict(a=b)
>>> A, B[/color][/color][/color]
({0: 1}, {'a': 1})

I feel very uncomfortable about that. Am I alone?


--
Steven.

[Fredrik Lundh]

Re: Arithmetic sequences in Python

Steven D'Aprano wrote:
[color=blue][color=green]
> > I much prefer the current arrangement where dict(a=b,c=d) means {'a':b,
> > 'c':d} -- it's much more congruent to how named arguments work for every
> > other case. Would you force us to quote argument names in EVERY
> > functioncall... ?![/color]
>
> Hmmm... should these two forms give different results?
>[color=green][color=darkred]
> >>> a = 0
> >>> b = 1
> >>> A = {a: b}
> >>> B = dict(a=b)
> >>> A, B[/color][/color]
> ({0: 1}, {'a': 1})
>
> I feel very uncomfortable about that. Am I alone?[/color]

yes.

</F>

[Kent Johnson]

Re: Arithmetic sequences in Python

Paul Rubin wrote:[color=blue]
> aleax@mail.comc ast.net (Alex Martelli) writes:[color=green]
>>I see no credibly simple and readable alternative to {a:b, c:d}
>>dictionary display syntax, for example; dict(((a,b),(c, d))) just
>>wouldn't cut it, because of the "parenthese s overload" (double
>>entendre intended).[/color]
>
>
> dict(a=b,c=d)
>
> I don't really see why keyword arg names have to be identifiers
> either. foo(3=4) can pass a **kwargs containing {3:4}.[/color]

The keywords need to be parseable; what would be the keyword form of
{ '3=4, 5=' : 6 }
or
{ '3=4); print "gotcha"; dict(6=' : 7 }
?

Kent

[Hans Nowak]

Re: Arithmetic sequences in Python

Alex Martelli wrote:
[color=blue]
> Do YOU have any good reason why
> sets should print out as set(...) and lists should NOT print out as
> list(...)? Is 'list' somehow "deeper" than 'set', to deserve a special
> display-form syntax which 'set' doesn't get? Or are you enshrining a
> historical accident to the level of an erroneously assumed principle?[/color]

(I haven't been following this thread much, so I can't tell if you're
actually arguing for this change, or that you are just playing devil's
advocate...)

I would have liked to say that lists are a fundamental data type, much
more so than a set... but in reality that seems to be a matter of taste
and priorities. Pascal, for example, has a set literal, but no list
literal; in fact, it doesn't even have a built-in list type.

--
Hans Nowak

http://zephyrfalcon.org/

[Steven Bethard]

Re: Arithmetic sequences in Python

Steven D'Aprano wrote:[color=blue]
> Steven Bethard wrote:
>[color=green]
>> I'm not sure I find it truly hateful, but definitely unnecessary.
>> TOOWTDI and all...[/color]
>[/color]
[snip][color=blue]
>
> Even when people mean One Obvious and not Only One, it is still harmful
> because the emphasis is wrong. The emphasis is on the *restrictive
> nature* of a language which merely gives one obvious way of doing things.[/color]

Perhaps just the *perceived* emphasis is wrong? Let me elaborate...

My intent was only to indicate that I don't think we *gain* anything by
having two forms that are quite similar both syntactically and
semantically. Both [...] and list(...) use exactly the same syntax for
the inner expression[1]. Both use parentheses/brackets, so the inner
expression can be broken across multiple lines in the same ways. Both
produce the same result, a list created in the appropriate manner.

So why have both? That's all I meant by TOOWTDI.

FWIW, I've posted my arguments for removing the redundant [...]
expression in Python 3.0 at:

http://wiki.python.org/moin/Python3%2e0Suggestions#preview

STeVe

[1] Reminder: I'm *not* arguing for list literals to look like
list(...), only for list comprehensions to look that way.

[Roberto De Almeida]

Re: Arithmetic sequences in Python

How about this hack:
[color=blue][color=green][color=darkred]
>>> import types
>>> class lazy_range(obje ct):[/color][/color][/color]
.... def __getitem__(sel f, l):
.... start = l[0]
....
.... if isinstance(l[1], types.EllipsisT ype):
.... step = 1
.... if len(l) > 2:
.... stop = l[2]
.... else:
.... stop = None
.... else:
.... step = l[1] - l[0]
.... if len(l) > 3:
.... stop = l[3]
.... else:
.... stop = None
....
.... for i in xrange(start, stop+1, step):
.... yield i[color=blue][color=green][color=darkred]
>>>
>>> l = lazy_range()
>>> print [i for i in l[1,3,...,10]][/color][/color][/color]
[1, 3, 5, 7, 9][color=blue][color=green][color=darkred]
>>> print [i for i in l[1,...,10]][/color][/color][/color]
[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]