Le 08/03/17 à 23:30, Chris Angelico a écrit :

On Thu, Mar 9, 2017 at 9:23 AM, Brice PARENT 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 3/8/2017 5:43 PM, 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. 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.

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

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()) type({}) type(dict)

The thing bound to the name 'dict' is not the same as the object returned by _calling_ 'dict'. E.

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 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/

On Mon, May 29, 2017 at 11:59 AM, Neil Girdhar 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 Tue, May 30, 2017 at 7:06 AM, Matt Gilson wrote:

On Mon, May 29, 2017 at 11:59 AM, Neil Girdhar 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

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