On Mon, May 29, 2017 at 5:06 PM Matt Gilson <m...@getpattern.com> wrote:
> On Mon, May 29, 2017 at 11:59 AM, Neil Girdhar <mistersh...@gmail.com> > wrote: > >> A long time ago, I proposed that the dict variants (sorteddict, >> defaultdict, weakkeydict, etc.) be made more discoverable by having them >> specified as keyword arguments and I got the same feedback that the poster >> here is getting. Now, instead of moving these classes into dict, why not >> have a factory like >> >> dict.factory(values=None, *, ordered=True, sorted=False, >> has_default=False, weak_keys=False, weak_values=False, …) >> > > Hmm ... I don't think that I like this. For one, it greatly increases the > amount of surface area that needs to be maintained in the standard > library. As far as I know, we don't currently have a > OrderedWeakKeyDictionary with defaultdict behavior. If this was to be > added, then each of the combinations of input keyword arguments would need > to be supported. Many of them probably don't have very compelling > use-cases or they might not have semantics that would be easy to agree upon > a "preferred behavior" (Assuming that a mythological SortedDict pops into > existence in the standard lib, what happens if you call > `dict.factory(sorted=True, ordered=True)`?). Of course, this sets a > precedence that future dict subclasses need to be added to the > `dict.factory` constructor as well which risks a very bloated signature > (or, someone has to make the decision about which subclasses should be > available and which should be left off ...). This last argument can > repurposed against providing easy access to builtin dict subclasses via > their own methods (`dict.defaultdict(...)`). > You can just raise NotImplementedError for the bad combinations and the reasonable combinations that aren't implemented yet. > > I don't find very cumbersome to import the dict subclasses that I need > from the locations where they live. I like that it forces me to be > explicit and I think that it generally makes reading the code easier in the > normal cases (`defaultdict(in)` vs. `dict.factory(default=int)`). Of > course, if someone finds this idea particularly interesting, they could > definitely explore the idea more by creating a package on pypi that > attempts to provide this factory function. If it got usage, that might go > a long way to convincing us nay-sayers that this idea has legs :-). > Fair enough. The reason I had proposed it was to make the various dict incantations more discoverable. Also, I was using a lot of weak-key dictionaries and it was odd to me that there was no ordered version of weak key dictionaries, etc. > > > > >> >> If prefers the keyword-argument as options to the keyword-argument as >> initializer magic, they can set: >> >> dict = dict.factory >> >> Best, >> >> Neil >> >> On Thursday, March 9, 2017 at 5:58:43 PM UTC-5, Chris Barker wrote: >>> >>> >>> >>> >If we really want to make defaultdict feel more "builtin" (and I don't >>>> see >>>> >any reason to do so), I'd suggest adding a factory function: >>>> > >>>> >dict.defaultdict(int) >>>> >>> >>> >>>> Nice. >>>> >>> >>> I agree -- what about: >>> >>> dict.sorteddict() ?? >>> >>> make easy access to various built-in dict variations... >>> >>> -CHB >>> >>> >>> -- >>> >>> Christopher Barker, Ph.D. >>> Oceanographer >>> >>> Emergency Response Division >>> NOAA/NOS/OR&R (206) 526-6959 voice >>> 7600 Sand Point Way NE (206) 526-6329 fax >>> Seattle, WA 98115 (206) 526-6317 main reception >>> >>> chris....@noaa.gov >>> >> >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas@python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> >> > > > -- > > Matt Gilson | Pattern > > Software Engineer > getpattern.com > <https://www.getpattern.com?utm_source=email&utm_medium=email&utm_campaign=signature-matt> >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
