[Python-Dev] quick poll: could int, str, tuple etc. become type objects?

Greg Ward gward@python.net
Tue, 5 Jun 2001 21:03:33 -0400


On 06 June 2001, Fredrik Lundh said:
> given that Jython already gives a meaning to dict with more
> than one argument, I suggest:
> 
>     dict(d) # consistency
>     dict(k, v, k, v, ...) # jython compatibility
>     dict(*[k, v, k, v, ...]) # convenience
>     dict(k=v, k=v, ...) # common pydiom

Yikes.  I still think that #2 is the "essential" spelling.  I think Tim
was speaking of #1 when he said we don't need another way to spell
copy() -- I'm inclined to agree.  I think the fact that you can say
int(3) or str("foo") are not strong arguments in favour of dict({...}),
because of mutability, because of the overhead of dicts, because we
already have the copy module, maybe other factors as well.

> and maybe:
> 
>     dict(d.items()) # symmetry

I think this is massive overloading.  Two interfaces to a single
function ought to be enough.  I for one have long wished for syntactic
sugar like Perl's => operator, which lets you do this:

  %band = { geddy => "bass",
            alex  => "guitar",
            neil  => "drums" }

...and keyword arg syntax is really the natural thing here.  Being able
to say

  band = dict(geddy="bass",
              alex="guitar",
              neil="drums")

would be good enough for me.  And it's less mysterious than Perl's =>,
which is just a magic comma that forces its LHS to be interpreted as a
string.  Weird.

        Greg
-- 
Greg Ward - Linux geek                                  gward@python.net
http://starship.python.net/~gward/
If you and a friend are being chased by a lion, it is not necessary to
outrun the lion.  It is only necessary to outrun your friend.