[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.