Hi All, I find importing defaultdict from collections to be clunky and it seems like having a default should just be an optional keyword to dict. Thus, something like, d = dict(default=int) would be the same as from collections import defaultdict d = defaultdict(int) Any thoughts? Thanks, ++Steve
Le 08/03/17 à 23:09, Steven Piantadosi a écrit :
Hi All,
I find importing defaultdict from collections to be clunky and it seems like having a default should just be an optional keyword to dict. Thus, something like,
d = dict(default=int)
would be the same as
from collections import defaultdict d = defaultdict(int)
Any thoughts?
I have never really used it, so I might say something stupid, but doesn't it prevent the use of "default" as a key in the generated dict? Would those 2 dicts be equal ? d1 = dict(default=5) d2 = {'default': 5} Brice
Le 08/03/17 à 23:30, Chris Angelico a écrit :
On Thu, Mar 9, 2017 at 9:23 AM, Brice PARENT <contact@brice.xyz> wrote:
Would those 2 dicts be equal ? d1 = dict(default=5) d2 = {'default': 5} Easy to find out:
d1 = dict(default=5) d2 = {'default': 5} d1 == d2 True
ChrisA That's my point... If they are equal, it clearly means that the declaration of d1 is *not* declaring a defaultdict right now, and is a valid syntax. So the behaviour would have to be changed, which would make legacy code erroneous in such a case.
But a possible workaround, is if we used the first positional argument of dict() as the default value. As right now it doesn't accept positional arguments (or at least if they are not iterable, which complicates a bit the thing), we could allow a syntax like : d = dict([default, ][*args, ]**kwargs) where default is a callable, *args made of iterables, and kwargs any kwargs.
On Thu, Mar 9, 2017 at 9:39 AM, Brice PARENT <contact@brice.xyz> wrote:
But a possible workaround, is if we used the first positional argument of dict() as the default value. As right now it doesn't accept positional arguments (or at least if they are not iterable, which complicates a bit the thing), we could allow a syntax like : d = dict([default, ][*args, ]**kwargs) where default is a callable, *args made of iterables, and kwargs any kwargs.
There'd still be a pile of special cases. Granted, there aren't going to be very many objects that are both callable and iterable, but there certainly _can be_, and if one were passed as the first argument, it would be ambiguous. Safer to keep this out of the signature of dict itself. ChrisA
On 3/8/2017 5:43 PM, Chris Angelico wrote:
On Thu, Mar 9, 2017 at 9:39 AM, Brice PARENT <contact@brice.xyz> wrote:
But a possible workaround, is if we used the first positional argument of dict() as the default value. As right now it doesn't accept positional arguments (or at least if they are not iterable, which complicates a bit the thing), we could allow a syntax like : d = dict([default, ][*args, ]**kwargs) where default is a callable, *args made of iterables, and kwargs any kwargs.
There'd still be a pile of special cases. Granted, there aren't going to be very many objects that are both callable and iterable, but there certainly _can be_, and if one were passed as the first argument, it would be ambiguous.
Safer to keep this out of the signature of dict itself.
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) Similar in spirit to dict.fromkeys(), except of course returning a defauldict, not a dict. Eric.
On Mar 08, 2017, at 05:49 PM, Eric V. Smith 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)
Similar in spirit to dict.fromkeys(), except of course returning a defauldict, not a dict.
Nice. -Barry
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.Barker@noaa.gov
Might make more sense to be dict.default(int), that way it doesn't have redundant dict names. Only problem is then it might be a bit confusing, since you could do {1:2, 3:4}.default(int) and not get the values back. Maybe 'withdefault', and return a copy if called on the instance?
On 09/03/17 23:04, Spencer Brown wrote:
Might make more sense to be dict.default(int), that way it doesn't have redundant dict names.
I thought that, too.
since you could do {1:2, 3:4}.default(int)
Could you? Python 3.6.0 (default, Mar 9 2017, 00:43:06) [GCC 5.4.0 20160609] on linux Type "help", "copyright", "credits" or "license" for more information.
type(dict()) <class 'dict'> type({}) <class 'dict'> type(dict) <class 'type'>
The thing bound to the name 'dict' is not the same as the object returned by _calling_ 'dict'. E.
On Fri, Mar 10, 2017 at 11:29 AM, Erik <python@lucidity.plus.com> wrote:
On 09/03/17 23:04, Spencer Brown wrote:
Might make more sense to be dict.default(int), that way it doesn't have redundant dict names.
I thought that, too.
since you could do {1:2, 3:4}.default(int)
Could you?
Python 3.6.0 (default, Mar 9 2017, 00:43:06) [GCC 5.4.0 20160609] on linux Type "help", "copyright", "credits" or "license" for more information.
type(dict()) <class 'dict'> type({}) <class 'dict'> type(dict) <class 'type'>
The thing bound to the name 'dict' is not the same as the object returned by _calling_ 'dict'.
Yes, you could; it'd be a classmethod, like dict.fromkeys. IMO it should just ignore any instance argument - same as you see here:
dict.fromkeys(range(3)) {0: None, 1: None, 2: None} {1:2,3:4}.fromkeys(range(3)) {0: None, 1: None, 2: None}
ChrisA
class OrderedDefaultDict, __missing__(), kwargs.pop('default_factory') - Src: https://gist.github.com/westurner/be22dba8110be099a35e#file-ordereddefaultdi...
From https://groups.google.com/d/msg/python-ideas/9bpR8-bNC6o/tQ92g7wLGAAJ :
On Fri, Oct 16, 2015 at 9:08 PM, Andrew Barnert via Python-ideas < python-ideas@python.org> wrote:
Actually, forget all that; it's even simpler.
At least in recent 3.x, the only thing wrong with inheriting from both types, assuming you put OrderedDict first, is the __init__ signature. So:
class OrderedDefaultDict(OrderedDict, defaultdict): def __init__(self, default_factory=None, *a, **kw): OrderedDict.__init__(self, *a, **kw) self.default_factory = default_factory
More importantly, because __missing__ support is built into dict, despite the confusing docs for defaultdict, you don't really need defaultdict at all here:
class OrderedDefaultDict(OrderedDict): def __init__(self, default_factory=None, *a, **kw): OrderedDict.__init__(self, *a, **kw) self.default_factory = default_factory def __missing__(self, key): self[key] = value = default_factory() return value
And either of these should work with 2.5+ (according to https://docs.python.org/2/library/stdtypes.html#dict that's when dict.__missing__ was added).
... This seems to keep a consistent __init__ signature with OrderedDict (by
.pop()-ing 'default_factory' from kwargs instead of specifying as a positionalkwarg):
class OrderedDefaultDict(OrderedDict): def __init__(self, *a, **kw): default_factory = kw.pop('default_factory', self.__class__) OrderedDict.__init__(self, *a, **kw) self.default_factory = default_factory def __missing__(self, key): self[key] = value = self.default_factory() return value
I've added a few tests (as well as to_json, and _repr_json_ https://gist.github.com/westurner/be22dba8110be099a35e/ c1a3a7394e401d4742df0617900bde6ab2643300#file-ordereddefaultdict-py-L120- L122 <https://www.google.com/url?q=https%3A%2F%2Fgist.github.com%2Fwesturner%2Fbe22dba8110be099a35e%2Fc1a3a7394e401d4742df0617900bde6ab2643300%23file-ordereddefaultdict-py-L120-L122&sa=D&sntz=1&usg=AFQjCNF8jH3Y4oHTVBCxhy0K2OPsRhj26g> (Without this fix, json.loads(output_json, object_pairs_hook=OrderedDefaultDict) doesn't seem to work).
On Thu, Mar 9, 2017 at 4:57 PM, Chris Barker <chris.barker@noaa.gov> 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.Barker@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/
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, …) 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 <javascript:>
On Mon, May 29, 2017 at 11:59 AM, Neil Girdhar <mistersheik@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(...)`). 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 :-).
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>
On Mon, May 29, 2017 at 5:06 PM Matt Gilson <matt@getpattern.com> wrote:
On Mon, May 29, 2017 at 11:59 AM, Neil Girdhar <mistersheik@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>
On Tue, May 30, 2017 at 7:06 AM, Matt Gilson <matt@getpattern.com> wrote:
On Mon, May 29, 2017 at 11:59 AM, Neil Girdhar <mistersheik@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.
"defaultdict behavior" can be tacked onto anything:
class OrderedDefaultDict(collections.OrderedDict): ... def __missing__(self, key): ... self[key] = [] ... return self[key]
The core functionality of defaultdict is part of dict (the fact that __missing__ gets called). The core functionality of weak references could easily be added to dict too, if something like this were wanted. So a lot of these would indeed be orthogonal. That said, though, I don't know of many situations in which you would need an OrderedWeakKeyDictionary, so if you have to write some custom code to make that happen, so be it. ChrisA
Sometimes I feel that it would be neat of dict constructors (like proposed previously in the thread) could also be chained, e.g.: dict.ordered.default(int)(a=1, b=2) -- Ryan (ライアン) Yoko Shimomura > ryo (supercell/EGOIST) > Hiroyuki Sawano >> everyone else http://refi64.com On May 29, 2017 2:06 PM, "Neil Girdhar" <mistersheik@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, …)
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/
On Thu, 09 Mar 2017 09:43:48 +1100, Chris Angelico wrote:
On Thu, Mar 9, 2017 at 9:39 AM, Brice PARENT wrote:
But a possible workaround, is if we used the first positional argument of dict() as the default value [...]
... Granted, there aren't going to be very many objects that are both callable and iterable ...
Many stream-like objects are both callable (get the next element of the stream) and iterable (iterate through the remainder of the stream). Or at least that's the way I make mine. Sometimes.
Safer to keep this out of the signature of dict itself.
Agreed. Dan
That's already valid dict syntax.
dict(default=int) {'default': <type 'int'>}
Generally that in itself makes this a no go. Mahmoud On Wed, Mar 8, 2017 at 2:09 PM, Steven Piantadosi <spiantado@gmail.com> wrote:
Hi All,
I find importing defaultdict from collections to be clunky and it seems like having a default should just be an optional keyword to dict. Thus, something like,
d = dict(default=int)
would be the same as
from collections import defaultdict d = defaultdict(int)
Any thoughts?
Thanks,
++Steve _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Hi All, I find importing defaultdict from collections to be clunky I don't. And if this really turns out to be an issue, why not expose defaultdict to built-ins instead of messing with dict class?
participants (15)
-
Barry Warsaw -
Brice PARENT -
Chris Angelico -
Chris Barker -
Dan Sommers -
Eric V. Smith -
Erik -
Mahmoud Hashemi -
Markus Meskanen -
Matt Gilson -
Neil Girdhar -
Ryan Gonzalez -
Spencer Brown -
Steven Piantadosi -
Wes Turner