BUG: raise on frozenset construction by Series

[cpcloud]

No description provided.

[ghost]

1. Argument from simplicity - Pandas data structures are ordered and the user is expected to provide an ordered (or keyed) data structure as input. It's simple and logical, I don't think there's a need to change it.
2. Argument from necessity - What's the problem this actually fixes? that the user has to pass in list(values) rather then values? meh.
3. Argument from consequence - Slippery slope, once you introduce set to the series ctor you break consistency (and an established pandas rule of thumb) with dataframe and panel. a small break in
   consistency can spread far and wide across a codebase when later attempts try to regain it. This may be FUD, but I just don't think it's worth it.

I'm -1 on this.

[cpcloud]

Your argument about consistency is the most convincing to me, but the original thought was: if list can take a set why can't Series? That would make Series more consistent with Python, but of course breaks it with pandas. I agree with you that we should keep consistency with the latter.

I agree with 1. and 2.

I don't feel strongly about this .... I've never actually run into the issue before....

At the very least this should raise on frozenset objects with the same error.

[cpcloud]

cc @hayd since he might have a stronger opinion than I about this.

[hayd]

Not really strong... the list argument is all I really have.

I think passing in any iterator should be ok... :s

In [11]: s = set([2])

In [12]: pd.Series(iter(s))
Out[12]: <setiterator at 0x104559280>

In [13]: pd.Series(iter(list(s)))
Out[13]: <listiterator at 0x104554b90>

In [14]: pd.Series(i for i in s)
Out[14]:
0    2
dtype: int64

so don't see why iterables should be so different, and why we should stop it (just cos we can't test it) but... meh.

Interested to see if/when dictionaries have different ordering for different python versions!

[ghost]

Good example. That's actually my 3rd point in action: a while ago generators were accepted
into the ctor (to save users the anguish of list(gen)) and now you're showing the inconsistency
it generated as an (reasonable) argument to support even more stuff.

I think it's fine to support iterators as you suggest (spilled generator milk, so to speak), but that means iter(set) not set,
so that's really a separate issue your example raises. iterat-or and an iter-able are
different beasts I believe, am I wrong?

re different ordering for different python versions, how about different ordering in the same
python version courtesy of hash randomization?

λ python3.3 -c 'print(dict(a=1,b=2))'
{'b': 2, 'a': 1}
λ python3.3 -c 'print(dict(a=1,b=2))'
{'a': 1, 'b': 2}

[cpcloud]

@y-p nice example.

yep iterables and iterators are different, iter(list('abc')) != list('abc')

@hayd also generators are yet another type of iterable which is why you get the output above

[hayd]

woah! that is a nice example :) I'm sold.

Maybe error could mention "first use list or sorted" ?

[jreback]

@cpcloud I guess will just leave this in here...and see what happens

[cpcloud]

@jreback good 2 go after passing?

[jreback]

thought u closed this? obviously not...ok