On Monday, June 4, 2018 at 11:29:15 PM UTC-7, Ben Rudiak-Gould wrote:
>
> One example (or family of examples) is any situation where you would
> have a UNIQUE constraint on an indexed column in a database. If the
> values in a column should always be distinct, like the usernames in a
> table of
On Wed, Jun 6, 2018 at 4:18 PM, Chris Barker via Python-ideas
wrote:
>
> Also -- seems kind of odd to raise a KeyError when the key IS there?!?
class DuplicateKeyError(LookupError): pass
Problem solved :)
ChrisA
___
Python-ideas mailing list
Python-id
On Tue, Jun 5, 2018 at 4:10 PM, Steven D'Aprano wrote:
> I'm confused... first you say that Ben makes a good case for this
> functionality with the DB analogy, and then one sentence later, you say
> the DB case is very different. So not a good case? I don't understand.
>
I wasn't trying to make
On Tue, Jun 05, 2018 at 09:44:59AM -0700, Chris Barker via Python-ideas wrote:
> I think your proposal got a bit confused by the choice of names, and that
> you were proposing two things, one of which I think already exists
> (setdefault).
Ben's very first paragraph in this thread says:
I'd
I think your proposal got a bit confused by the choice of names, and that
you were proposing two things, one of which I think already exists
(setdefault).
So, I _think_ what you are proposing is that there be a method something
like:
def exclusive_add(self, key, value):
if key in self:
On Mon, Jun 4, 2018 at 4:02 PM, Yuval Greenfield wrote:
> The proposed meanings surprised me too. My initial instinct for
> `dict.append` was that it would always succeed, much like `list.append`
> always succeeds.
Many of the methods named `append` in the standard libraries fail if
adding the it
I don't think I'd ever guess the intended semantics from the names in a
million years. They seem like horribly misnamed methods, made worse by the
false suggestion of similarity to list operations.
In 20 years of using Python, moreover, I don't think I've ever wanted the
described behavior under a
> d.setdefault(key, value)
I though the OP wanted an error if the key already existed.
This is close, as it won’t change the dict if the key is already
there, but it will add it if it’s not.
@OP
Maybe post those five lines so we know exactly what you want — maybe
there is already a good solutio
On 2018-06-05 01:25, Steven D'Aprano wrote:
On Mon, Jun 04, 2018 at 02:22:29PM -0700, Ben Rudiak-Gould wrote:
I'd like to propose adding `append` and `extend` methods to dicts
which behave like `__setitem__` and `update` respectively, except that
they raise an exception (KeyError?) instead of ov
On Mon, Jun 04, 2018 at 02:22:29PM -0700, Ben Rudiak-Gould wrote:
> I'd like to propose adding `append` and `extend` methods to dicts
> which behave like `__setitem__` and `update` respectively, except that
> they raise an exception (KeyError?) instead of overwriting preexisting
> entries.
>
> Ver
On Mon, Jun 4, 2018 at 3:58 PM George Leslie-Waksman
wrote:
> Semantically, I'm not sure append and extend would be universally
> understood to mean don't overwrite.
>
>
The proposed meanings surprised me too. My initial instinct for
`dict.append` was that it would always succeed, much like `list
Semantically, I'm not sure append and extend would be universally
understood to mean don't overwrite.
This can be accomplished with a custom subclass for your use case:
```
import collections
class OverwriteGuardedDict(collections.UserDict):
def append(self, key, value):
if key in s
I'd like to propose adding `append` and `extend` methods to dicts
which behave like `__setitem__` and `update` respectively, except that
they raise an exception (KeyError?) instead of overwriting preexisting
entries.
Very often I expect that the key I'm adding to a dict isn't already in
it. If I w
13 matches
Mail list logo
