Guido van Rossum wrote:
> So here's a new proposal.
>
> Let's add a generic missing-key handling method to the dict class, as
> well as a default_factory slot initialized to None. The implementation
> is like this (but in C):
>
> def on_missing(self, key):
> if self.default_factory is not None:
Please submit your patch to SourceForge.
On 2/17/06, Chris AtLee <[EMAIL PROTECTED]> wrote:
> I'm writing a program in python that creates tar files of a certain
> maximum size (to fit onto CD/DVD). One of the problems I'm running
> into is that when using compression, it's pretty much impossib
[cc to py-dev again]
Guido van Rossum wrote:
> On 2/17/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>>> So here's a new proposal.
>>>
>>> Let's add a generic missing-key handling method to the dict class, as
>>> well as a default_factory slot initialized to None. The imp
On 2/17/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
> Ahem, I'm still looking for ways to 'overtake' the dict to implement
> weird and fancy things. Can on_missing be overridden in subclasses (writing
> the subclass in C would not be a problem)?
Why ahem?
The answer is yes.
--
--Guido van Ross
On Fri, Feb 17, 2006 at 03:03:06PM -0500, Fred L. Drake, Jr. wrote:
> On Friday 17 February 2006 14:51, Ian Bicking wrote:
> > and in the process breaking an important
> > quality of good Python code, that attribute and getitem access not have
> > noticeable side effects.
>
> I'm not sure that
Guido van Rossum wrote:
> On 2/17/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
>> Ahem, I'm still looking for ways to 'overtake' the dict to implement
>> weird and fancy things. Can on_missing be overridden in subclasses (writing
>> the subclass in C would not be a problem)?
>
> Why ahem?
>
> Th
M.-A. Lemburg wrote:
> Just because some codecs don't fit into the string.decode()
> or bytes.encode() scenario doesn't mean that these codecs are
> useless or that the methods should be banned.
No. The reason to ban string.decode and bytes.encode is that
it confuses users.
Regards,
Martin
__
Guido van Rossum wrote:
> On 2/17/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
>
>>I really don't like that defaultdict (or a dict extension) means that
>>x[not_found] will have noticeable side effects. This all seems to be a
>>roundabout way to address one important use case of a dictionary with
>
Guido van Rossum wrote:
> d = {}
> d.default_factory = set
> ...
> d[key].add(value)
Another option would be:
d = {}
d.default_factory = set
d.get_default(key).add(value)
Unlike .setdefault, this would use a factory associated with the
dictionary, and no default value would get passed
Walter Dörwald wrote:
I'd suggest we keep codecs.lookup() the way it is and
instead add new functions to the codecs module, e.g.
codecs.getencoderobject() and codecs.getdecoderobject().
Changing the codec registration is not much of a problem:
we could simply allow 6-t
On Fri, Feb 17, 2006, Guido van Rossum wrote:
>
> But the default implementation is designed so that we can write
>
> d = {}
> d.default_factory = list
+1
I actually like the fact that you're forced to use a separate statement
for setting the default_factory. From my POV, this can go into 2.5.
On 2/16/06, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> /usr/share often is on a different mount; that's the whole rationale
> for /usr/share.
I don't think I've worked at a place where something like that was
done for at least 10 years. Isn't this argument outdated?
--
--Guido van Rossum (h
On 2/17/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> - There's a fundamental difference between associating the default
> value with the dict object, and associating it with the call. So
> proposals to invent a better name/signature for setdefault() don't
> compete.
That's a feature, not a bu
Cut to the chase: how about being able to write
baz(bar(foo(x, y)),z)
serially as
foo(x, y) -> bar() -> baz(z)
via the above as sugar for
baz.__get__(bar.__get__(foo(x, y))())(z)
?
I.e., you'd have self-like args to receive results from upstream. E.g.,
>>> def foo(x, y): return
Fuzzyman wrote:
>>Also, I think has_key/in should return True if there is a default.
>>
>>
>>
> And exactly what use would it then be ?
Code that checks
if d.has_key(k):
print d[k]
would work correctly. IOW, you could use a dictionary with a default
key just as if it were a normal dictionary
On 2/17/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> It's also makes it harder to read code. You may expect d[key] to
> raise an exception, but it won't because of a single line up several
> pages (or in another file entierly!)
Such are the joys of writing polymorphic code. I don't really see how
Bengt Richter wrote:
> Cut to the chase: how about being able to write
>
> baz(bar(foo(x, y)),z)
>
> serially as
>
> foo(x, y) -> bar() -> baz(z)
>
> via the above as sugar for
>
> baz.__get__(bar.__get__(foo(x, y))())(z)
Reminds me of
http://dev.perl.org/perl6/doc/design/syn/S03.
Adam Olsen wrote:
> Still -1. It's better, but it violates the principle of encapsulation
> by mixing how-you-use-it state with what-it-stores state. In doing
> that it has the potential to break an API documented as accepting a
> dict. Code that expects d[key] to raise an exception (and catches
On 2/17/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > d = {}
> > d.default_factory = set
> > ...
> > d[key].add(value)
>
> Another option would be:
>
>d = {}
>d.default_factory = set
>d.get_default(key).add(value)
>
> Unlike .setdefault, this would use a facto
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> M.-A. Lemburg wrote:
> > Just because some codecs don't fit into the string.decode()
> > or bytes.encode() scenario doesn't mean that these codecs are
> > useless or that the methods should be banned.
>
> No. The reason to ban string.decode and bytes
Cut to the chase: -1000.
On 2/17/06, Bengt Richter <[EMAIL PROTECTED]> wrote:
> Cut to the chase: how about being able to write
>
> baz(bar(foo(x, y)),z)
>
> serially as
>
> foo(x, y) -> bar() -> baz(z)
>
> via the above as sugar for
>
> baz.__get__(bar.__get__(foo(x, y))())(z)
>
> ?
Guido van Rossum wrote:
> On 2/16/06, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
>
>>/usr/share often is on a different mount; that's the whole rationale
>>for /usr/share.
>
>
> I don't think I've worked at a place where something like that was
> done for at least 10 years. Isn't this argume
On Fri, 17 Feb 2006 21:35:25 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
<[EMAIL PROTECTED]> wrote:
>M.-A. Lemburg wrote:
>> Just because some codecs don't fit into the string.decode()
>> or bytes.encode() scenario doesn't mean that these codecs are
>> useless or that the methods should be
Guido van Rossum wrote:
> On 2/17/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
>
>>It's also makes it harder to read code. You may expect d[key] to
>>raise an exception, but it won't because of a single line up several
>>pages (or in another file entierly!)
>
>
> Such are the joys of writing polym
Guido van Rossum wrote:
> I'm torn. While trying to implement this I came across some ugliness
> in PyDict_GetItem() -- it would make sense if this also called
> on_missing(), but it must return a value without incrementing its
> refcount, and isn't supposed to raise exceptions -- so what to do if
Josiah Carlson wrote:
> How are users confused?
Users do
py> "Martin v. Löwis".encode("utf-8")
Traceback (most recent call last):
File "", line 1, in ?
UnicodeDecodeError: 'ascii' codec can't decode byte 0xf6 in position 11:
ordinal not in range(128)
because they want to convert the string "to
On 2/17/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 2/17/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > It's also makes it harder to read code. You may expect d[key] to
> > raise an exception, but it won't because of a single line up several
> > pages (or in another file entierly!)
>
> Suc
On 2/17/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > On 2/16/06, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> >>/usr/share often is on a different mount; that's the whole rationale
> >>for /usr/share.
> >
> > I don't think I've worked at a place where something
On 2/17/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > Such are the joys of writing polymorphic code. I don't really see how
> > you can avoid this kind of confusion -- I could have given you some
> > other mapping object that does weird stuff.
>
> You could pass a float in as well. But if the func
Ian Bicking wrote:
> I know *I* at least don't like code that mixes up access and
> modification. Maybe not everyone does (or maybe not everyone thinks of
> getitem as "access", but that's unlikely). I will assert that it is
> Pythonic to keep access and modification separate, which is why met
Adam Olsen wrote:
> You could pass a float in as well. But if the function is documented
> as taking a dict, and the programmer expects a dict.. that now has to
> be changed to "dict without a default". Or they have to code
> defensively since d[key] may or may not raise KeyError, so they must
>
On 2/17/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
> > Still -1. It's better, but it violates the principle of encapsulation
> > by mixing how-you-use-it state with what-it-stores state. In doing
> > that it has the potential to break an API documented as accepting a
> >
Martin v. Löwis wrote:
> Users do
>
> py> "Martin v. Löwis".encode("utf-8")
> Traceback (most recent call last):
> File "", line 1, in ?
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xf6 in position 11:
> ordinal not in range(128)
>
> because they want to convert the string "to Unicode
Martin v. Löwis wrote:
>>I know *I* at least don't like code that mixes up access and
>>modification. Maybe not everyone does (or maybe not everyone thinks of
>>getitem as "access", but that's unlikely). I will assert that it is
>>Pythonic to keep access and modification separate, which is why
Adam Olsen wrote:
> The latter is even the prefered form, since it only invokes a single
> dict lookup:
>
> On 2/16/06, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote:
>
>>try:
>>v = d[key]
>>except:
>>v = d[key] = value
>
>
> Obviously this example could be changed to
On Fri, 17 Feb 2006 14:58:34 -0800, "Guido van Rossum" <[EMAIL PROTECTED]>
wrote:
>On 2/17/06, "Martin v. L=F6wis" <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>> > On 2/16/06, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
>> >>/usr/share often is on a different mount; that's the whole
Thomas Wouters wrote:
> On Fri, Feb 17, 2006 at 05:29:32PM +0100, Armin Rigo wrote:
>
>>> Where obj must be either an int or a long or another object that has
>>> the
>>> __index__ special method (but not self).
>
>
>>The "anything but not self" rule is not consistent with any other
Martin v. Löwis writes:
> You are missing the rationale of the PEP process. The point is
> *not* documentation. The point of the PEP process is to channel
> and collect discussion, so that the BDFL can make a decision.
> The BDFL is not bound at all to the PEP process.
>
> To document things, we us
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
> > How are users confused?
>
> Users do
>
> py> "Martin v. Löwis".encode("utf-8")
> Traceback (most recent call last):
> File "", line 1, in ?
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xf6 in position 11:
> o
Martin v. Löwis wrote:
> Just in case you haven't noticed, I just merged
> the ssize_t branch (PEP 353).
>
> If you have any corrections to the code to make which
> you would consider bug fixes, just go ahead.
>
> If you are uncertain how specific problems should be resolved,
> feel free to ask.
Adam Olsen wrote:
> Consider these two pieces of code:
>
> if key in d:
> dosomething(d[key])
> else:
> dosomethingelse()
>
> try:
> dosomething(d[key])
> except KeyError:
> dosomethingelse()
>
> Before they were the same (assuming dosomething() won't raise
> KeyError). Now they would b
Ian Bicking wrote:
> That str.encode(unicode_encoding) implicitly decodes strings seems like
> a flaw in the unicode encodings, quite seperate from the existance of
> str.encode. I for one really like s.encode('zlib').encode('base64') --
> and if the zlib encoding raised an error when it was passe
Josiah Carlson wrote:
>>>If some users
>>>can't understand this (passing different arguments to a function may
>>>produce different output),
>>
>>It's worse than that. The return *type* depends on the *value* of
>>the argument. I think there is little precedence for that: normally,
>>the return val
Is that a record? ;-)
BTW, does python-dev have different expectations re top-posting?
I've seen more here than on c.l.p I think, so I'm wondering what to do.
When-in-Rome'ly,
Regards,
Bengt Richter
On Fri, 17 Feb 2006 14:17:41 -0800, "Guido van Rossum" <[EMAIL PROTECTED]>
wrote:
>Cut to the
On 2/17/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Ian Bicking wrote:
>
> >> Unfortunately, a @property decorator is impossible...
> >
> > It already works! But only if you want a read-only property. Which is
> > actually about 50%+ of the properties I create. So the status quo is
> > not rea
It's only me that's allowed to top-post. :-)
On 2/17/06, Bengt Richter <[EMAIL PROTECTED]> wrote:
> Is that a record? ;-)
>
> BTW, does python-dev have different expectations re top-posting?
> I've seen more here than on c.l.p I think, so I'm wondering what to do.
>
> When-in-Rome'ly,
>
> Regards,
Martin v. Löwis wrote:
> Ian Bicking wrote:
>
>>That str.encode(unicode_encoding) implicitly decodes strings seems like
>>a flaw in the unicode encodings, quite seperate from the existance of
>>str.encode. I for one really like s.encode('zlib').encode('base64') --
>>and if the zlib encoding raise
Alex Martelli wrote:
> Maybe we could fix that by having property(getfunc) use
> getfunc.__doc__ as the __doc__ of the resulting property object
> (easily overridable in more normal property usage by the doc=
> argument, which, I feel, should almost invariably be there).
+1
--
Ian Bicking / [E
Ian Bicking wrote:
> It is lazily incarnated for multidict, because there is no *noticeable*
> side effect -- if there is any internal side effects that is an
> implementation detail. However for default_factory=list, the result of
> .keys(), .has_key(), and .items() changes when you do d[some_key
Ian Bicking wrote:
> Maybe it isn't worse, but the real alternative is:
>
> import zlib
> import base64
>
> base64.b64encode(zlib.compress(s))
>
> Encodings cover up eclectic interfaces, where those interfaces fit a
> basic pattern -- data in, data out.
So should I write
3.1415.encode("s
On 2/17/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> That's why I think has_key and in should return True for any key.
> This leaves keys(), items(), and values(). From a pure point of
> view, they should return infinite sets. Practicality beats purity,
> so yes, d[k] could be considered a mo
WFM. Patch anyone?
On 2/17/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Alex Martelli wrote:
> > Maybe we could fix that by having property(getfunc) use
> > getfunc.__doc__ as the __doc__ of the resulting property object
> > (easily overridable in more normal property usage by the doc=
> > argumen
Martin v. Löwis wrote:
> Adam Olsen wrote:
>
>>Consider these two pieces of code:
>>
>>if key in d:
>> dosomething(d[key])
>>else:
>> dosomethingelse()
>>
>>try:
>> dosomething(d[key])
>>except KeyError:
>> dosomethingelse()
>>
>>Before they were the same (assuming dosomething() won't raise
>>
Martin v. Löwis wrote:
>>Maybe it isn't worse, but the real alternative is:
>>
>> import zlib
>> import base64
>>
>> base64.b64encode(zlib.compress(s))
>>
>>Encodings cover up eclectic interfaces, where those interfaces fit a
>>basic pattern -- data in, data out.
>
>
> So should I write
>
> 3
On Fri, Feb 17, 2006 at 04:40:08PM -0700, Travis Oliphant wrote:
> What is PY_SSIZE_T_MAX supposed to be? The definition in pyport.h
> doesn't compile.
Why not? Does it give an error for your particular platform? What platform
is that? What are HAVE_SSIZE_T, SIZEOF_VOID_P and SIZEOF_SIZE_T defi
On Feb 17, 2006, at 4:20 PM, Martin v. Löwis wrote:
> Ian Bicking wrote:
>> Maybe it isn't worse, but the real alternative is:
>>
>> import zlib
>> import base64
>>
>> base64.b64encode(zlib.compress(s))
>>
>> Encodings cover up eclectic interfaces, where those interfaces fit a
>> basic patt
On 2/17/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
> > You could pass a float in as well. But if the function is documented
> > as taking a dict, and the programmer expects a dict.. that now has to
> > be changed to "dict without a default". Or they have to code
> > defe
Thomas Wouters wrote:
> On Fri, Feb 17, 2006 at 04:40:08PM -0700, Travis Oliphant wrote:
>
>
>>What is PY_SSIZE_T_MAX supposed to be? The definition in pyport.h
>>doesn't compile.
>
Maybe I have the wrong version of code. In my pyport.h (checked out
from svn trunk) I have.
#define PY_SSIZE_
Martin v. Löwis wrote:
>>Another thought -- what is going to happen to os.open?
>>Will it change to return bytes, or will there be a new
>>os.openbytes?
>
> Nit-pickingly: os.open will continue to return integers.
Sorry, what I meant was will os.read return bytes.
Greg
_
Adam Olsen wrote:
> And the pièce de résistance..
> Doc/tools/anno-api.py:51
>
> It has this:
> try:
> info = rcdict[s]
> except KeyError:
> sys.stderr.write("No refcount data for %s\n" % s)
> else:
> ...
> rcdict is loaded from refcounts.load(). refcounts.load
[Travis Oliphant]
> Maybe I have the wrong version of code. In my pyport.h (checked out
> from svn trunk) I have.
>
> #define PY_SSIZE_T_MAX ((Py_ssize_t)(((size_t)-1)>>1))
>
> What is size_t?
size_t is an unsigned integral type defined by, required by, and used
all over the place in standard C.
Stephen J. Turnbull wrote:
>>"Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes:
> Guido> - b = bytes(t, enc); t = text(b, enc)
>
> +1 The coding conversion operation has always felt like a constructor
> to me, and in this particular usage that's exactly what it is. I
> prefer the n
Guido van Rossum wrote:
> But there were
> several suggestions that this would be fine functionality to add to
> the standard dict type -- and then I really don't see any other way to
> do this.
Given the constructor problem, and the issue with "this function expects a
plain dictionary", I think
At 11:58 AM 02/17/2006 -0800, Guido van Rossum wrote:
>I forgot to mention in my revised proposal that the API for setting
>the default_factory is slightly odd:
>
> d = {} # or dict()
> d.default_factory = list
>
>rather than
>
> d = dict(default_factory=list)
>
>This is of course because w
On 2/17/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> And this is where the question of whether has_key/__having__ return True or
> False when default_factory is set is important. If they return False, then the
> LBYL (if key in d:) and EAFTP (try/except) approaches give *different
> answers*.
>
>
Tim Peters wrote:
> [Travis Oliphant]
>
>>Maybe I have the wrong version of code. In my pyport.h (checked out
>>from svn trunk) I have.
>>
>>#define PY_SSIZE_T_MAX ((Py_ssize_t)(((size_t)-1)>>1))
>>
>>What is size_t?
>
>
> size_t is an unsigned integral type defined by, required by, and used
>
Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> Stephen J. Turnbull wrote:
> >>"Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes:
>
> > Guido> - b = bytes(t, enc); t = text(b, enc)
> >
> > +1 The coding conversion operation has always felt like a constructor
> > to me, and in this parti
On Sat, 18 Feb 2006 00:52:51 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
<[EMAIL PROTECTED]> wrote:
>Adam Olsen wrote:
>> Consider these two pieces of code:
>>
>> if key in d:
>> dosomething(d[key])
>> else:
>> dosomethingelse()
>>
>> try:
>> dosomething(d[key])
>> except KeyError:
On Feb 17, 2006, at 8:33 PM, Josiah Carlson wrote:
>
> Greg Ewing <[EMAIL PROTECTED]> wrote:
>>
>> Stephen J. Turnbull wrote:
"Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes:
>>
>>> Guido> - b = bytes(t, enc); t = text(b, enc)
>>>
>>> +1 The coding conversion operation has al
On Fri, Feb 17, 2006, "Martin v. L?wis" wrote:
> Josiah Carlson wrote:
>>
>> How are users confused?
>
> Users do
>
> py> "Martin v. L?wis".encode("utf-8")
> Traceback (most recent call last):
> File "", line 1, in ?
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xf6 in position 11:
> o
On 2/17/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> if key in d:
> dosomething(d[key])
> else:
> dosomethingelse()
>
> try:
> dosomething(d[key])
> except KeyError:
> dosomethingelse()
I agree with the gut feeling that these should still do the same
thing. Could we modify d.get() instead?
All right, the patch is up on SF. Sorry for the delay, I accidentally
left my powerbook about an hour's drive away from home, and had to drive
to go get it this morning :)
To those who were asking what advantage the new syntax has - well, from
a technical perspective there are none, since the u
On 2/17/06, Armin Rigo <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Tue, Feb 14, 2006 at 09:24:57PM -0800, Neal Norwitz wrote:
> > http://www.python.org/peps/pep-0356.html
>
> There is at least one SF bug, namely "#1333982 Bugs of the new AST
> compiler", that in my humble opinion absolutely needs to be
On 2/17/06, Travis E. Oliphant <[EMAIL PROTECTED]> wrote:
>
> I'm very sorry for my silliness. I do see the problem I was having now.
>Thank you for helping me out. I was assuming that PY_SSIZE_T_MAX
> could be used in a pre-processor statement like LONG_MAX and INT_MAX.
>
> In other words
>
Bob Ippolito <[EMAIL PROTECTED]> wrote:
>
>
> On Feb 17, 2006, at 8:33 PM, Josiah Carlson wrote:
>
> >
> > Greg Ewing <[EMAIL PROTECTED]> wrote:
> >>
> >> Stephen J. Turnbull wrote:
> "Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes:
> >>
> >>> Guido> - b = bytes(t, enc); t =
On Fri, 17 Feb 2006, Phillip J. Eby wrote:
> > d = {} # or dict()
> > d.default_factory = list
>
> Why not a classmethod constructor:
>
> d = dict.with_factory(list)
>
> But I'd rather set the default and create the
> dictionary in one operation, since when reading it as two, you first
Guido van Rossum wrote:
> I'd much rather be able to write "if key in d" and get the result I want...
Somewhere else in this byzantine thread, I realised that what was really
bothering me was the conditional semantics that dict ended up with (i.e., it's
behaviour changed significantly if the def
On Fri, 17 Feb 2006 20:33:16 -0800, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
>Greg Ewing <[EMAIL PROTECTED]> wrote:
>>
>> Stephen J. Turnbull wrote:
>> >>"Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes:
>>
>> > Guido> - b = bytes(t, enc); t = text(b, enc)
>> >
>> > +1 The cod
Ian Bicking wrote:
> Well, here's a kind of an example: WSGI specifies that the environment
> must be a dictionary, and nothing but a dictionary. I think it would
> have to be updated to say that it must be a dictionary with
> default_factory not set, as default_factory would break the
> predictab
101 - 179 of 179 matches
Mail list logo
