Kevin Wampler <wam### [at] uwashingtonedu> wrote:
> Darren New wrote:
> > Actually, python dictionaries are pretty lame compared to dictionaries
> > in some other languages, like PHP.
>
> I don't know PHP, so I'm curious if you could elaborate a bit, since I'm
> used to viewing "dictionary" as more of less a synonym for "hashtable"
> in this context.

Yeah, me too.  What is it lacking exactly?  Specially compared to an aberration
like PHP?


Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> d = {}
>>> type( d )
<type 'dict'>
>>> d['foo'] ="bar"
>>> d
{'foo': 'bar'}
>>> dir( d )
['__class__', '__cmp__', '__contains__', '__delattr__', '__delitem__',
'__doc__', '__eq__', '__ge__', '__getattribute__', '__getitem__', '__gt__',
'__hash__', '__init__', '__iter__', '__le__', '__len__', '__lt__', '__ne__',
'__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__',
'__setitem__', '__str__', 'clear', 'copy', 'fromkeys', 'get', 'has_key',
'items', 'iteritems', 'iterkeys', 'itervalues', 'keys', 'pop', 'popitem',
'setdefault', 'update', 'values']
>>> d.items()
[('foo', 'bar')]
>>> d[1] = 2
>>> d[1]
2
>>> d[2]=lambda x:x+1
>>> d
{1: 2, 2: <function <lambda> at 0x8198fb4>, 'foo': 'bar'}
>>> d[2](3)
4
>>> for k,v in d.items():
....     print k, " => ", v
....
1  =>  2
2  =>  <function <lambda> at 0x8198fb4>
foo  =>  bar
>>>

It can take arbitrary objects as keys and has a wealth of good methods to choose
from.  Perhaps it's time for some friday night troll? ;)

Post a reply to this message

Kevin Wampler wrote:
> I don't know PHP, so I'm curious if you could elaborate a bit, since I'm 
> used to viewing "dictionary" as more of less a synonym for "hashtable" 
> in this context.

Hmmm... A dictionary in PHP is more like an array of key/value pairs. So 
they preserve the order in which you inserted elements, they have integer 
indecies, but they also act as hash tables. Plus, you can say things like
    x[] = 27
to append 27 to the end of the array, whatever size it is. So they work as 
both dictionaries, arrays, and ordered maps.
http://us3.php.net/manual/en/language.types.array.php

Honestly, I don't think I've ever *used* the fact that the keys maintain an 
order even when they're not integers.

Lua dictionaries (called "tables") are also kind of odd, in that they are 
apparently hashtables with special rules for entries with integer keys as 
well as an independent "size", but I didn't follow it far enough to 
understand what was going on exactly there. It was kind of funky mixing 
integer and non-integer indecies, in the tutorials I was reading.

-- 
   Darren New, San Diego CA, USA (PST)
   There's no CD like OCD, there's no CD I knoooow!

Post a reply to this message

Darren New wrote:
> Kevin Wampler wrote:
>> I don't know PHP, so I'm curious if you could elaborate a bit, since 
>> I'm used to viewing "dictionary" as more of less a synonym for 
>> "hashtable" in this context.
> 
> Hmmm... A dictionary in PHP is more like an array of key/value pairs. So 
> they preserve the order in which you inserted elements

Interesting.  So, to make sure I understand correctly if dicts in python 
were to operate like this then:

D = dict()
d["a"] = "foo"
d["b"] = "bar"
d["c"] = "baz"

would give me {"a":"foo", "b":"bar", "c":"baz"} where the order matters 
  so D[1] gives "bar"?

If so, then what happens in the following case:

D = dict()
d[3] = "foo"
d[2] = "bar"
d[1] = "baz"

or:

D = dict()
D[2000000000] = "foo"

I think any implementation which tries to behave both like a list and a 
hashtable is going to have some inconsistencies when using ints as keys, 
so I actually prefer the approach of keeping the two separate.  That 
said I do sometimes like the C++ stl approach of maintaining an ordering 
in a map based on the natural order of its elements.


> Honestly, I don't think I've ever *used* the fact that the keys maintain 
> an order even when they're not integers.

I actually have used this in python a few times, using a custom class 
rather than a straight dict of course.  Unfortunately I can't remember 
why I needed it.  I suspect it was so that I could pack the dict into a 
vector, perform some computations on it, and then put the results back 
into the dict.

Post a reply to this message

Kevin Wampler <wam### [at] uwashingtonedu> wrote:
> I think any implementation which tries to behave both like a list and a
> hashtable is going to have some inconsistencies when using ints as keys,
> so I actually prefer the approach of keeping the two separate.

Exactly, order shouldn't matter in a dictionary:  it's a set.  There are lists
if one needs order or you can always base a class on dict and replace
__setitem__ and __getitem__.

What matters in Python though is case and D is not the same as d. :P

PHP and Perl are full of inconsistencies.

Post a reply to this message

Kevin Wampler wrote:
> would give me {"a":"foo", "b":"bar", "c":"baz"} where the order matters 
>  so D[1] gives "bar"?

It has been a while, but I think so, yes.

> If so, then what happens in the following case:

IIRC, if you use integer keys, you get what you'd expect.

Note that you can iterate over a list without giving specific indexes, so it 
might work that you say
   foreach key, value in D {print key,value}
and you get
   3 foo / 2 bar / 1 baz
or something like that. It has been too long for me to remember.

> said I do sometimes like the C++ stl approach of maintaining an ordering 
> in a map based on the natural order of its elements.

That's another way to do it. Or at least make hashes with equal contents 
iterate in identical order.

> I actually have used this in python a few times, using a custom class 
> rather than a straight dict of course.  Unfortunately I can't remember 
> why I needed it.

If you're making a dict (in particular a class namespace) that you're going 
to translate into (for example) SOAP or a COM interface or something, I can 
see where it would be helpful.  That's what some of the Python 3.0 
extensions were about.

-- 
   Darren New, San Diego CA, USA (PST)
   There's no CD like OCD, there's no CD I knoooow!

Post a reply to this message

nemesis wrote:
> Exactly, order shouldn't matter in a dictionary:  it's a set.

But that's kind of the point. Why do you think that?  Saying "order 
shouldn't matter because it's a set" is begging the question.

Why does order matter in argument lists, if the arguments all need distinct 
names anyway? :-)

> PHP and Perl are full of inconsistencies.

No argument there.

-- 
   Darren New, San Diego CA, USA (PST)
   There's no CD like OCD, there's no CD I knoooow!

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> But that's kind of the point. Why do you think that?  Saying "order
> shouldn't matter because it's a set" is begging the question.

A set in the mathematical sense has no order.  If the guy wants order, he goes
for a list.  PHP only got array, so it has to play many roles.

> Why does order matter in argument lists, if the arguments all need distinct
> names anyway? :-)

I think it has to do with pragmatism:  it's just simpler to go with a list than
a hash.

In math, you have a function over domains and you have to make sure each
argument belongs to each domain and the simplest way to notate this is to give
the order of the domains and pass the arguments to the function in that order.
Had they opted for a named argument notation, you'd not need order, but on the
other hand you'd need a lot more typing.  Programming language designers were
conscious of that and just stacking them as they come is much easier than
unwrapping hash values.

Named arguments is a thing of a hip generation used to lots of cheap computing
power and general resources.  It's not as costly anymore to be verbose when
your tools happily churn it out for you.

Post a reply to this message

Darren New wrote:
> Why does order matter in argument lists, if the arguments all need 
> distinct names anyway? :-)

So you can call the function without explicitly naming the parameters, 
thus reducing the amount of typing required.

Personally, I like the style where arguments can be passed in order (in 
which case the names don't matter) or by name (in which case the order 
doesn't matter).  Python sort does this, with a few restrictions, and 
it's seemed pretty intuitive and useful to me.

Thinking back, didn't objective-C use named parameters only for calling 
object methods?  Did the order matter there?  I can't really remember.

Post a reply to this message

Darren New wrote:
> IIRC, if you use integer keys, you get what you'd expect.

I'm actually not sure what to expect here.  For instance:

D = dict()
D[1] = "foo"
try:
	if D[0] == D[1]:
		print "maybe this makes sense?"
	else:
		print "ok, this is odd"
except:
	print "maybe this also makes sense?"


I think the issue is that this sort of structure has two types of 
indices, and when both are ints there's no way to properly distinguish 
them, so I can't think of what behavior would be appropriate.

On the other hand, it's probably not a very big issue in practice, since 
at worst the behavior (whatever it is) would be just another one of 
those language quirks that you have to memorize, and there's certainly 
no shortage of those in most languages.

> Note that you can iterate over a list without giving specific indexes, 

This is a different matter, and I don't think it has any of the problems 
  that using integers as direct indices does.  I might imagine that such 
a structure tightly integrated into a language might have uses which 
outweighed it's somewhat higher inefficiency, although I can't think of 
just what those uses might be.  As a matter of taste, however, I tend to 
prefer have the basic structures at my disposal be closely related to 
basic classes of algorithms and to build more complicated assemblages as 
I need from those parts.  Hence my preference for hashtable or 
ordered-tree backed dicts types.

Post a reply to this message

On 3-4-2009 23:08, nemesis wrote:
> andrel escreveu:
>> On 3-4-2009 18:40, Darren New wrote:
>>> Please, this is not a troll. It's a serious question that isn't meant 
>>> to imply the answer is "no."
>>
>> 'No' would be a strange answer to your question anyway.
>>
>>> What are some other cool open-source projects that didn't take their 
>>> design from existing products?  I.e., ones where the open source 
>>> software was the first thing to do things that way?
>>
>> POV and Blender?
> 
> Blender started life as an in-house, proprietary tool.  When the company 
> was closing doors, they realized the tool was quite complete and good 
> enough perhaps not for going commercial, but at least to serve as the 
> basis for an open-source project.  And so they realized an online 
> auction and when a certain ammount was gathered, they did release the 
> source under the GPL.
> 
> The community literally bought a former proprietary product and 
> open-sourced it.  Even Stallman gone hurrah. :)

What I remember is that it started as a research project (at which stage 
it may have been available for others, so that is why I though it might 
qualify as an answer), was then tried commercially and when that did not 
work converted to open source by the main developer.
The reason that it did not work may be related to being forced to do 
(more than) full time 'maintenance' and 'support' because people were 
paying.
That danger is why our software is available to fellow researchers for 
free. We would like to do some research ourselves too.

Post a reply to this message