On Thu, 5 Sep 2019 at 16:51, Andrew Barnert <abarn...@yahoo.com> wrote:
>
> You say here “the dict insertion code” does it. Would they mean
> d[key]=d.skip doesn’t insert anything?
Yes.
If so, then how could I put skip in a dict at all?
The intention is that you couldn't. This could raise some implementation
issues!
> If there’s already a d[key] does that get left alone, or deleted?
Left alone.
> Wouldn’t this even affect dict inserts that happen behind the scenes, like
> any time you tried to assign dict.skip to a global variable or a class or
> instance attribute, or pass it as a keyword argument? If an implementation
> doesn’t use dict.insert to build dict literals, does that mean it doesn’t
> work in dict literals on that implementation, even though that was the
> whole motivation for the feature?
>
> Maybe instead of starting with how it could be implemented, start with
> where you ideally do and don’t want it to take effect, and then we can try
> to work out how it could be implemented to do that, and how to specify it
> to require such an implementation.
>
>
This was what I was attempting to do. I wasn't suggesting the way I wrote
was the way it should be implemented, just a sketch of how it might look.
> * Obviously you want it in non-comprehension dict displays, because
> that’s your example.
> * What about comprehensions?
>
Yes.
> * Constructor calls with the keyword-arg API like dict(a=1, b=dict.skip,
> **d2}?
>
I'd expect the b value to not be assigned.
> * Constructor calls from iterables of pairs, like dict((1, 2), (3,
> dict.skip))?
>
I'd expect the 3 key to be unassigned (assuming an extra pair of brackets).
> * Subscription assignments?
>
I'm sorry, I'm not sure what you're referring to here. Do mean as in
x[dict.skip] = y or x[y] = dict.skip? If so, I'd expect both operations to
be, well, skipped.
> * Calls to insert?
> * Calls to update?
>
Yes. Inserts to remain unassigned, updates to keep the original value. The
idea is to skip the operation.
> * Capturing ** keyword args?
>
Yes.
> * Assignments to globals, attributes, etc. when those use a dict under
> the covers (as they usually do!?
>
I'm not sure... setting an attribute/global to "dict.skip" might not have
any effect. I don't think the user could complain about surprise for doing
something like this.
> * Assignments to such things when they don’t use a dict (as with a slots
> class instance)?
>
> Also, what should happen with this case:
>
> flag0, flag1 = True, False
> d = {'k': 0 if flag0 else dict.skip,
> 'k': 1 if flag1 else dict.skip}
>
> Do we keep the last value for 'k' as usual, and because that’s dict.skip,
> therefore d['k'] ends up as a KeyError? Or do we keep the last non-skip
> value and therefore d['k'] ends up as 0?
>
I'd expect the assignments to happen in order, so d['k'] would be set to 0
and then the second assignment to be ignored.
>
> What about this:
>
> class D(dict):
> skip = 0
> d = D()
> d.skip = 1
> d[0] = 0
> d[1] = 1
> d[dict.skip] = dict.skip
>
> Do we skip the one that uses d.skip, the one that uses type(d).skip (like
> a special method lookup), or the one that uses dict.skip?
>
>
This seems like a fairly pathological case, and I'm not sure it's really in
the spirit of your request to focus on the use rather than the
implementation! But I'd expect the key value of dict.skip to cause the
entry to be skipped.
Thanks for coming up with so many angles on this; it's interesting exercise
to consider how many things could be affected by this.
Writing a ConditionalDict type in a similar spirit would be a lot simpler,
though less convenient to use. I will experiment.
Thanks
Rich
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/2FH37WQVBYJCHTCLRGSTUPDSR77RV4WK/
Code of Conduct: http://python.org/psf/codeofconduct/
