Arithmetic sequences in Python

[Gregory Petrosyan]

Please visit http://www.python.org/peps/pep-0204.html first.

As you can see, PEP 204 was rejected, mostly because of not-so-obvious
syntax. But IMO the idea behind this pep is very nice. So, maybe
there's a reason to adopt slightly modified Haskell's syntax? Something
like

[1,3..10] --> [1,3,5,7,9]
(1,3..10) --> same values as above, but return generator instead of
list
[1..10] --> [1,2,3,4,5,6,7,8 ,9,10]
(1 ..) --> 'infinite' generator that yield 1,2,3 and so on
(-3,-5 ..) --> 'infinite' generator that yield -3,-5,-7 and so on

So,
1) "[]" means list, "()" means generator
2) the "start" is required, "step" and "end" are optional.

Also, this can be nicely integrated with enumerations (if they will
appear in python). Haskell is also example of such integration.

[Paul Rubin]

al***@mail.comc ast.net (Alex Martelli) writes:

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... ?!

Ehh, ok. There could be some special marker to evaluate the lhs, but
the present method is fine too.

[Paul Rubin]

al***@mail.comc ast.net (Alex Martelli) writes:

How would you make a one-element list, which we'd currently write as [3]?
Would you have to say list((3,))?

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?),

If you really want to get rid of container literals, maybe the best
way is with constructor functions whose interfaces are slightly
different from the existing type-coercion functions:

listx(1,2,3) => [1, 2, 3]
listx(3) => [3]
listx(listx(3)) => [[3]]
dictx((a,b), (c,d)) => {a:b, c:d}
setx(a,b,c) => Set((a,b,c))

listx/dictx/setx would be the display forms as well as the constructor forms.

[Tom Anderson]

On Fri, 20 Jan 2006, it was written:

al***@mail.comc ast.net (Alex Martelli) writes:

How would you make a one-element list, which we'd currently write as
[3]? Would you have to say list((3,))?

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?),

If you really want to get rid of container literals, maybe the best way
is with constructor functions whose interfaces are slightly different
from the existing type-coercion functions:

listx(1,2,3) => [1, 2, 3]
listx(3) => [3]
listx(listx(3)) => [[3]]
dictx((a,b), (c,d)) => {a:b, c:d}
setx(a,b,c) => Set((a,b,c))

listx/dictx/setx would be the display forms as well as the constructor forms.

Could these even replace the current forms? If you want the equivalent of
list(sometuple) , write list(*sometuple ). With a bit of cleverness down in
the worky bits, this could be implemented to avoid the apparent overhead
of unpacking and then repacking the tuple. In fact, in general, it would
be nice if code like:

def f(*args):
fondle(args)

foo = (1, 2, 3)
f(*foo)

Would avoid the unpack/repack.

The problem is that you then can't easily do something like:

mytable = ((1, 2, 3), ("a", "b", "c"), (Tone.do, Tone.re, Tone.mi))
mysecondtable = map(list, mytable)

Although that's moderately easy to work around with possibly the most
abstract higher-order-function i've ever written:

def star(f):
def starred_f(args) :
return f(*args)
return starred_f

Which lets us write:

mysecondtable = map(star(list), mytable)

While we're here, we should also have the natural complement of star, its
evil mirror universe twin:

def bearded_star(f) :
def bearded_starred _f(*args):
return f(args)
return bearded_starred _f

Better names (eg "unpacking" and "packing") would obviously be needed.

tom

--
I might feel irresponsible if you couldn't go almost anywhere and see
naked, aggressive political maneuvers in iteration, marinating in your
ideology of choice. That's simply not the case. -- Tycho Brahae

[Paul Rubin]

Tom Anderson <tw**@urchin.ea rth.li> writes:

listx/dictx/setx would be the display forms as well as the constructor forms.

Could these even replace the current forms? If you want the equivalent
of list(sometuple) , write list(*sometuple ).

The current list function is supposed to be something like a typecast:

list() = []
xlist() = [] # ok

list(list()) = [] # casting a list to a list does nothing
xlist(xlist()) = [[]] # make a new list, not the same

list(xrange(4)) = [0,1,2,3]
xlist(xrange(4) ) = [xrange(4)] # not the same

list((1,2)) = [1,2]
xlist((1,2)) = [(1,2)]

etc.

[Tom Anderson]

On Sat, 21 Jan 2006, it was written:

Tom Anderson <tw**@urchin.ea rth.li> writes:

listx/dictx/setx would be the display forms as well as the constructor
forms.
Could these even replace the current forms? If you want the equivalent
of list(sometuple) , write list(*sometuple ).

The current list function is supposed to be something like a typecast:

A what?

;-|
list() = []
xlist() = [] # ok

list(list()) = [] # casting a list to a list does nothing
xlist(xlist()) = [[]] # make a new list, not the same

list(xrange(4)) = [0,1,2,3]
xlist(xrange(4) ) = [xrange(4)] # not the same

list((1,2)) = [1,2]
xlist((1,2)) = [(1,2)]

True, but so what? Is it that it has to be that way, or is it just that it
happens to be that way now?

tom

--
It's the 21st century, man - we rue _minutes_. -- Benjamin Rosenbaum

[Steve Holden]

Paul Rubin wrote:

Tom Anderson <tw**@urchin.ea rth.li> writes:

listx/dictx/setx would be the display forms as well as the constructor forms.
Could these even replace the current forms? If you want the equivalent
of list(sometuple) , write list(*sometuple ).

The current list function is supposed to be something like a typecast:

list() isn't a function, it's a type.

type(list)

<type 'type'>

I'm not happy about the way the documentation represents types as
functions, as this obscures the whole essence of Python's object
orientation.

list() = []
xlist() = [] # ok

list(list()) = [] # casting a list to a list does nothing
xlist(xlist()) = [[]] # make a new list, not the same

list(xrange(4)) = [0,1,2,3]
xlist(xrange(4) ) = [xrange(4)] # not the same

list((1,2)) = [1,2]
xlist((1,2)) = [(1,2)]

etc.

I presume that here "=" means "evaluates to"?

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

[Christoph Zwerschke]

Alex Martelli wrote:

print set([1,2,3])

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?

These are valid points, but they lead me to the opposite conclusion: Why
not let {a,b,c} stand for set([a,b,c])? That would be very intuitive
since it is the mathematical notation already and since it resembles the
notation of dictionaries which are similar to sets.

(This has been probably discussed already. One problem I'm already
seeing is that {} would be ambiguous.)

Anyway, I think the fact that the notation for a set is clumsy is no
good reason to make the notation for a list clumsy as well.

-- Christoph

[Paul Rubin]

Steve Holden <st***@holdenwe b.com> writes:

The current list function is supposed to be something like a
typecast:

list() isn't a function, it's a type.

I'm not sure what the distinction is supposed to be. "list" is anyway
callable, and lambda a:list(a) is certainly a function.

xlist((1,2)) = [(1,2)]
etc.

I presume that here "=" means "evaluates to"?

Yeah, although I meant something more informal, like mathematical
equivalence.

Maybe the preferred spellings for the constructors would use capital
letters: List, Dict, Set, instead of listx or xlist or whatever. That
would break the current meaning of Set but I hope not much depends on
that yet.

[Alex Martelli]

Paul Rubin <http://ph****@NOSPAM.i nvalid> wrote:

Steve Holden <st***@holdenwe b.com> writes:

The current list function is supposed to be something like a
typecast:

list() isn't a function, it's a type.

I'm not sure what the distinction is supposed to be. "list" is anyway

You can subclass a type, you can check for it with isinstance, etc, all
things you couldn't do if list was still a factory function as in 2.1
and back.
Alex

[Alex Martelli]

Christoph Zwerschke <ci**@online.de > wrote:
...

These are valid points, but they lead me to the opposite conclusion: Why
not let {a,b,c} stand for set([a,b,c])? That would be very intuitive
As syntax sugar goes, that would be on a par with the current "dict
display" notation, at least.
(This has been probably discussed already. One problem I'm already
seeing is that {} would be ambiguous.)
Yep, using {} for both sets and dicts wouldn't be a good idea. I
suspect most core Python developers think of dicts as more fundamental
than sets, so... (I may disagree, but I just don't care enough about
such syntax sugar to consider even starting a debate about it on
python-dev, particularly knowing it would fail anyway).
Anyway, I think the fact that the notation for a set is clumsy is no
good reason to make the notation for a list clumsy as well.

I don't agree that <typename>(<arg uments>) is a clumsy notation, in
general; rather, I consider "clumsy" much of the syntax sugar that is
traditional in Python. For example, making a shallow copy of a list L
with L[:] is what strikes me as clumsy -- list(L) is SO much better.
And I vastly prefer dict(a=1,b=2) over the clumsy {'a':1, 'b':2}.

I suspect I'm unusual in that being deeply familiar with some notation
and perfectly used to it does NOT necessarily make me LIKE that
notation, nor does it make me any less disposed to critical reappraisal
of it -- the brains of most people do appear to equate habit with
appreciation. In the light of my continuous and unceasing critical
reappraisal of Python's syntax choices, I am quite convinced that many
of them are really brilliant -- with the "display forms" of some
built-in types being one area where I find an unusually high density of
non-brilliance, AKA clumsiness. But, that's just me.
Alex