Although ENUMs are already complicated enough, this proposals frees up
messing with the EnumMeta metaclass in some cases -
it makes sense.
I've subclassed EnumMeta once for adding some feature in a project, and it
never feels the "quite right" thing to do.
On Tue, Apr 26, 2022 at 6:12 PM Stefan
*Background*
It is frequently desirable to delete a dictionary entry if the key exists. It
is necessary to check that the key exists or, alternatively, handle a KeyError:
for, where `d` is a `dict`, and `k` is a valid hashable key, `del d[k]` raises
KeyError if `k` does not exist.
Example:
You could use the pop method on dictionary (with a default value of None
for example) to remove the key only if it exists.
The method returns the value associated with this key but you can ignore it.
I'm not sure the __isub__ implementation would be easy to understand as
it's weird to make a
Good points, Antoine!
The intent is to mutate the dictionary with no side effects if a key exists —
and without the extra code that comes along with a control structure, a try
except, or positing a None to throw away.
For me, pop() says "give me something." Since the intent is to mutate the
On Fri, 29 Apr 2022 at 04:03, Zach Victor wrote:
> Where does this land with PEP 20? I think the use of pop() as you suggest
> lands on the implicit side of things and is not as readable: the reader has
> to ask, "what are we doing with the default value? Oh. Nothing. It's to
> delete a dict
On Fri, 29 Apr 2022 at 07:15, Zach Victor wrote:
>
> I agree that "implicit" does not mean "code that one dislikes." The intent is
> "delete entry if key exists." Is that implicit or explicit?
>
"[R]emove specified key and return the corresponding value", with a
default if there isn't one. Is
Using `dct -= key` is WAAAYY too cryptic. A method would be okay, but since
that is just `dct.pop(key, None)` without the second argument, it's not
worth the trouble.
-1
On Thu, Apr 28, 2022, 12:03 PM Zach Victor wrote:
> Good points, Antoine!
>
> The intent is to mutate the dictionary with no
I agree that "implicit" does not mean "code that one dislikes." The intent is
"delete entry if key exists." Is that implicit or explicit?
Positing a default value to discard it as a return value is, arguably, what
makes the intent of that construction implicit. I say "arguably," because that
The original idea was actually not to write function, but thank you for telling
me that I am welcome to do so—that is very kind of you and, indeed, welcoming.
I don't know whether to consider it an improvement. It is a nice function.
___
Python-ideas
On Thu, Apr 28, 2022 at 01:18:09AM -, zmvic...@gmail.com wrote:
> *Background*
> It is frequently desirable to delete a dictionary entry if the key
> exists.
Frequently?
I don't think I've ever needed to do that. Can you give an example of
real code that does this?
> It is necessary to
On Fri, 29 Apr 2022 at 07:44, Steven D'Aprano wrote:
>
> Especially not when that solution is easily mistaken for something else:
>
> d -= 1 # Are we subtracting 1, or deleting key 1?
>
IMO it would make more sense to spell it as subtraction of two similar types:
d -= {1} # supporting sets
On 4/21/22 10:29, Joao S. O. Bueno wrote:
> I take the freedom to interpret 'no news == good news' on this thread -
> nominally that there are no major disagreements that a decorator
> to auto-commit `__init__` atributes to the instance could be a nice addition
> to the stdlib.
I am strongly
> Can you give an example of real code that does this?
In general, parsing JSON data and normalizing it. The existing architecture has
microservices consuming PubSub messages for which the data-payload is JSON. In
some cases, deleting dictionary keys is convenient (as opposed to, say,
building
Agree — it is perhaps a bit strange to use an operator for something other than
dictionary-to-dictionary operations.
And, yes, benchmarking is the only way to know—but I think your hypothesis is a
good one.
___
Python-ideas mailing list --
On 4/23/22 12:11, Christopher Barker wrote:
> NOTE: another key question for this proposal is how you would handle mutable
defaults -- anything
> special, or "don't do that"?
Why should they be handled at all? If the programmer writes
def __init__(a, @b, @c=[]):
pass
then all
On 4/21/22 15:12, Joao S. O. Bueno wrote:
> On Thu, Apr 21, 2022 at 5:17 PM Pablo Alcain wrote:
>> I think that discussion can probably belong to a specific thread with the
proposal with
>> your questions summary there so everyone can contribute to the
implementation that, clearly,
>> has some
On Thu, Apr 28, 2022 at 4:15 PM Ethan Furman wrote:
> > NOTE: another key question for this proposal is how you would handle
> mutable defaults -- anything
> > special, or "don't do that"?
>
> Why should they be handled at all? If the programmer writes
>
> def __init__(a, @b, @c=[]):
>
On 4/28/22 21:46, Christopher Barker wrote:
> One thing you can say about dataclasses is that they provide a way to handle
all parameters, mutable and immutable.
Really? I did not know that. Interesting.
Definitely an issue of dataclasses being special, though, and not attributable
to the
18 matches
Mail list logo
