[issue23372] defaultdict.fromkeys should accept a callable factory

2016-09-19 Thread Raymond Hettinger
Raymond Hettinger added the comment: [Serhiy] I'm inclined to reject this proposition. It serves very special use case. [Silent Ghost] Correct me if I'm wrong but this seem as a very unlikely use case [Alec Nikolas Reiter] Implicitly assigning the factory is a pretty good compromise, like I

[issue23372] defaultdict.fromkeys should accept a callable factory

2016-09-19 Thread Vedran Čačić
Vedran Čačić added the comment: That's usual behavior for any class method. You can call them on an instance, but they don't have the access to it, only to its class. So transferring of factory would in fact not be possible. Of course,it's possible to make fromkeys an instance method, but

[issue23372] defaultdict.fromkeys should accept a callable factory

2016-09-19 Thread Gavin Panella
Gavin Panella added the comment: It's inconsistent that defaultdict([]) should be rejected: >>> defaultdict([]) Traceback (most recent call last): File "", line 1, in TypeError: first argument must be callable or None but defaultdict.fromkeys([]) is okay: >>>

[issue23372] defaultdict.fromkeys should accept a callable factory

2015-02-01 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: It may be written simpler: d = defaultdict(factory) for i in constants: d[i] or d = defaultdict(factory, {i: factory() for i in constants}) I'm inclined to reject this proposition. It serves very special use case. -- nosy:

[issue23372] defaultdict.fromkeys should accept a callable factory

2015-02-01 Thread SilentGhost
SilentGhost added the comment: Correct me if I'm wrong but this seem as a very unlikely use case. Why would you need to ensure content of the defaultdict (i.e., why would you ever use its fromkeys method)? And, perhaps, having to implicitly assign default factory is not such a bad tradeoff,

[issue23372] defaultdict.fromkeys should accept a callable factory

2015-02-01 Thread Raymond Hettinger
Raymond Hettinger added the comment: -0 I could see some use cases for this, dict.fromkeys(contestants, factory=list), but it adds complexity to a core container API and it starts to overlap the use cases for collections.defaultdict(). Perhaps set comprehensions should remain the

[issue23372] defaultdict.fromkeys should accept a callable factory

2015-02-01 Thread Alec Nikolas Reiter
New submission from Alec Nikolas Reiter: Not something I've noticed until today, but defaultdict.fromkeys only accepts an iterable of keys and an initial value. To set the default_factory for the newly created collection, you need to prod at the attribute itself. This isn't a huge issue for

[issue23372] defaultdict.fromkeys should accept a callable factory

2015-02-01 Thread SilentGhost
SilentGhost added the comment: Raymond, but Alec talks about defaultdict.fromkeys(constants, factory=list) as opposed to current solution d = defaultdict.fromkeys(constants) d.default_factory = list for i in d: d[i] = [] I wouldn't think that the dict.fromkeys should be

[issue23372] defaultdict.fromkeys should accept a callable factory

2015-02-01 Thread Alec Nikolas Reiter
Alec Nikolas Reiter added the comment: @SilentGhost I was playing with a voting algorithm (Instant Runoff, rather than traditional majority). Ultimately, I ended up using Counter in place of a defaultdict, but that's how I ended up noticing it. Not so much ensuring the content so much as

[issue23372] defaultdict.fromkeys should accept a callable factory

2015-02-01 Thread Serhiy Storchaka
Changes by Serhiy Storchaka storch...@gmail.com: -- nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23372 ___ ___ Python-bugs-list