hash multithreading and cross language issue

[Sam Ruby]

I note that the perlscalar code is careful about multithreading issues
(example: "if we morph to a string, first clear str_val so that after
changing the vtable a parallel reader doesn't get a gargabe pointer"),
but reuses a static PMC* intret.

The current PerlHash PMC coerces keys to strings, so the following will
print bar:

my %hash;
$hash{1} = 'foo';
$hash{"1"} = 'bar';
print $hash{1};

Whereas the nearest equivalent in Python will print foo:

dict = {}
dict[1] = 'foo'
dict["1"] = 'bar'
print dict[1]

For Python support, it would be ideal if there would be a hash method
entry in the VTABLE for each object.

- Sam Ruby

[Leopold Toetsch]

Sam Ruby <ru...@intertwingly.net> wrote:
> I note that the perlscalar code is careful about multithreading issues
> (example: "if we morph to a string, first clear str_val so that after
> changing the vtable a parallel reader doesn't get a gargabe pointer"),
> but reuses a static PMC* intret.

Lets postpone multi-threading issues for a while.

> dict = {}
> dict[1] = 'foo'
> dict["1"] = 'bar'
> print dict[1]

> For Python support, it would be ideal if there would be a hash method
> entry in the VTABLE for each object.

Not only ideal but necessary. The stringification of hash keys is a
perlism that just isn't usable for Python.

> - Sam Ruby

leo