On Fri, Sep 13, 2013 at 04:26:06AM +, Steve Dower wrote:
Last I checked, looking up in the instance dict us exactly what it
does. Even the example you posted is doing that.
The example from the PEP shows:
return cls.__dict__[name]
not self.__dict__[name]. It is true that the
Perhaps __getdescriptor__ would work as the method name? Yes, it can
technically return a non-descriptor, but the *primary* purpose is to
customise the retrieval of objects that will be checked to see if they're
descriptors. It *won't* be invoked when looking for ordinary attributes in
an instance
On Fri, Sep 13, 2013 at 08:42:46PM +1000, Nick Coghlan wrote:
Perhaps __getdescriptor__ would work as the method name? Yes, it can
technically return a non-descriptor,
So technically that name is, um, what's the term... oh yes, a lie.
:-)
but the *primary* purpose is to
customise the
On 9/13/2013 3:22 AM, senthil.kumaran wrote:
http://hg.python.org/cpython/rev/b85c9d2a5227
changeset: 85672:b85c9d2a5227
parent: 85668:66ec8431032d
parent: 85671:1fcccbbe15e2
user:Senthil Kumaran sent...@uthcode.com
date:Fri Sep 13 00:22:45 2013 -0700
summary:
From: Steven D'Aprano
On Fri, Sep 13, 2013 at 04:26:06AM +, Steve Dower wrote:
Last I checked, looking up in the instance dict us exactly what it
does. Even the example you posted is doing that.
The example from the PEP shows:
return cls.__dict__[name]
not self.__dict__[name]. It
ACTIVITY SUMMARY (2013-09-06 - 2013-09-13)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open4212 (+17)
closed 26571 (+48)
total 30783 (+65)
Open issues
Hello,
Following the python-dev discussion, I've written a PEP to recap the
proposal and the various arguments. It's inlined below, and it will
probably appear soon at http://www.python.org/dev/peps/pep-0455/, too.
Regards
Antoine.
PEP: 455
Title: Adding a key-transforming dictionary to
13.09.13 21:40, Antoine Pitrou написав(ла):
Both are instances of a more general pattern, where a given
transformation function is applied to keys when looking them up: that
function being ``str.lower`` in the former example and the built-in
``id`` function in the latter.
Please use
+1 :)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Fri, 13 Sep 2013 22:31:02 +0300
Serhiy Storchaka storch...@gmail.com wrote:
13.09.13 21:40, Antoine Pitrou написав(ла):
Both are instances of a more general pattern, where a given
transformation function is applied to keys when looking them up: that
function being ``str.lower`` in the
I see the PEP does not contemplate a way to retrieve the original key
- like we've talked about somewhere along the thread.
On 13 September 2013 16:37, Antoine Pitrou solip...@pitrou.net wrote:
On Fri, 13 Sep 2013 22:31:02 +0300
Serhiy Storchaka storch...@gmail.com wrote:
13.09.13 21:40,
On Fri, 13 Sep 2013 16:54:01 -0300
Joao S. O. Bueno jsbu...@python.org.br wrote:
I see the PEP does not contemplate a way to retrieve the original key
- like we've talked about somewhere along the thread.
Indeed. If that's important I can add it. I was hoping to keep very
close to the
13.09.13 21:40, Antoine Pitrou написав(ла):
Alternative proposals and questions
===
Yet one alternative proposal is to add the dict.__transform__() method.
Actually this not contradict TransformDict, but generalize it.
TransformDict will be just handly
On Fri, 13 Sep 2013 23:16:10 +0300
Serhiy Storchaka storch...@gmail.com wrote:
13.09.13 21:40, Antoine Pitrou написав(ла):
Alternative proposals and questions
===
Yet one alternative proposal is to add the dict.__transform__() method.
Actually this not
On Fri, 13 Sep 2013 16:09:10 -0400
R. David Murray rdmur...@bitdance.com wrote:
On Fri, 13 Sep 2013 20:40:58 +0200, Antoine Pitrou solip...@pitrou.net
wrote:
Rationale
=
Numerous specialized versions of this pattern exist. The most common
is a case-insensitive
13.09.13 23:02, Antoine Pitrou написав(ла):
On Fri, 13 Sep 2013 16:54:01 -0300
Joao S. O. Bueno jsbu...@python.org.br wrote:
I see the PEP does not contemplate a way to retrieve the original key
- like we've talked about somewhere along the thread.
Indeed. If that's important I can add it. I
13.09.13 22:37, Antoine Pitrou написав(ла):
That's true. But it's only important if TransformDict is the
bottleneck. I doubt the memoizing dictionary is a bottleneck in
e.g. the pure Python implementation of pickle or json.
It can be used in the C implementation.
On Fri, 13 Sep 2013 20:40:58 +0200, Antoine Pitrou solip...@pitrou.net wrote:
Rationale
=
Numerous specialized versions of this pattern exist. The most common
is a case-insensitive case-preserving dict, i.e. a dict-like container
which matches keys in a case-insensitive fashion but
13.09.13 23:21, Antoine Pitrou написав(ла):
On Fri, 13 Sep 2013 23:16:10 +0300
Serhiy Storchaka storch...@gmail.com wrote:
13.09.13 21:40, Antoine Pitrou написав(ла):
Alternative proposals and questions
===
Yet one alternative proposal is to add the
On Sat, 14 Sep 2013 00:05:27 +0300
Serhiy Storchaka storch...@gmail.com wrote:
13.09.13 23:21, Antoine Pitrou написав(ла):
On Fri, 13 Sep 2013 23:16:10 +0300
Serhiy Storchaka storch...@gmail.com wrote:
13.09.13 21:40, Antoine Pitrou написав(ла):
Alternative proposals and questions
You know, I can think up several use cases for the case-insensitive idea.
Not sure if I missed something, but there should be a function to retrieve
the original key from the modified. i.e.:
mydict['SomeStr'] = 5
mydict.get_key('somestr')
'SomeStr'
On Fri, Sep 13, 2013 at 1:40 PM, Antoine
On Fri, 13 Sep 2013 23:18:39 +0300
Serhiy Storchaka storch...@gmail.com wrote:
13.09.13 23:02, Antoine Pitrou написав(ла):
On Fri, 13 Sep 2013 16:54:01 -0300
Joao S. O. Bueno jsbu...@python.org.br wrote:
I see the PEP does not contemplate a way to retrieve the original key
- like we've
On 09/13/2013 02:45 PM, Antoine Pitrou wrote:
Serhiy Storchaka wrote:
I think that's important. As OrderectDict has additional methods besides
the MutableMapping API, so TransformDict should provide useful
specialized methods.
Ok, I have a better (IMO) proposal:
d =
On Fri, Sep 13, 2013 at 11:45:16PM +0200, Antoine Pitrou wrote:
Ok, I have a better (IMO) proposal:
d = TransformDict(str.casefold, {'Foo': 1})
d.getitem('foo')
('Foo', 1)
d.getitem('bar')
Traceback (most recent call last):
File stdin, line 1, in module
On Sun, Sep 08, 2013 at 10:51:57AM -0700, Guido van Rossum wrote:
Never mind, I found the patch and the issue. I really think that the
*PEP* is ready for inclusion after the open issues are changed into
something like Discussion or Future Work, and after adding a more
prominent link to the
On Sat, 14 Sep 2013 10:49:52 +1000
Steven D'Aprano st...@pearwood.info wrote:
Is it more common to want both the canonical key and value at the same
time, or to just want the canonical key? My gut feeling is that I'm
likely to have code like this:
d = TransformDict(...)
for key in data:
On Fri, 13 Sep 2013 15:32:55 -0700
Ethan Furman et...@stoneleaf.us wrote:
On 09/13/2013 02:45 PM, Antoine Pitrou wrote:
Serhiy Storchaka wrote:
I think that's important. As OrderectDict has additional methods besides
the MutableMapping API, so TransformDict should provide useful
On 14/09/2013 01:49, Steven D'Aprano wrote:
On Fri, Sep 13, 2013 at 11:45:16PM +0200, Antoine Pitrou wrote:
Ok, I have a better (IMO) proposal:
d = TransformDict(str.casefold, {'Foo': 1})
d.getitem('foo')
('Foo', 1)
d.getitem('bar')
Traceback (most recent call last):
On 09/13/2013 05:49 PM, Steven D'Aprano wrote:
+1 on __transform__ method on dicts.
What would __transform__ do? Just canonicalize the key, or also save the original key? How much front-end work will
each user have to do to actually use this new magic method to good effect?
Personally,
On 09/13/2013 06:25 PM, MRAB wrote:
On 14/09/2013 01:49, Steven D'Aprano wrote:
Is it more common to want both the canonical key and value at the same
time, or to just want the canonical key? My gut feeling is that I'm
likely to have code like this:
d = TransformDict(...)
for key in data:
On 14/09/2013 02:40, Ethan Furman wrote:
On 09/13/2013 06:25 PM, MRAB wrote:
On 14/09/2013 01:49, Steven D'Aprano wrote:
Is it more common to want both the canonical key and value at the same
time, or to just want the canonical key? My gut feeling is that I'm
likely to have code like this:
On Fri, Sep 13, 2013 at 06:00:18PM -0700, Ethan Furman wrote:
Personally, if there's a bunch of push-back against just adding
TransformDict directly, why don't we make it provisional? I thought that
was what provisional was for (meaning: we're going to add it, PyPI is not
really
On Sat, Sep 14, 2013 at 02:25:42AM +0100, MRAB wrote:
On 14/09/2013 01:49, Steven D'Aprano wrote:
d = TransformDict(...)
for key in data:
key = d.get_canonical(key)
value = d[key]
print({}: {}.format(key, value))
I think must be missing something. I thought that iterating
On Fri, Sep 13, 2013 at 06:00:18PM -0700, Ethan Furman wrote:
On 09/13/2013 05:49 PM, Steven D'Aprano wrote:
+1 on __transform__ method on dicts.
What would __transform__ do? Just canonicalize the key, or also save the
original key? How much front-end work will each user have to do to
On Fri, Sep 13, 2013 at 06:40:06PM -0700, Ethan Furman wrote:
and if you wanted the transformed key you would apply the transform
function to the key.
Indeed. The question is: how? It is entirely possible that your function
has a TransformDict alone, and no memory of the transform
On 09/13/2013 08:33 PM, Steven D'Aprano wrote:
Likewise, the point of transformdict is to avoid needing to care
about the transformation function 99% of the time.
No one's arguing against that point. It's the 1% of the time that being able to get the canonical name back is a Good
Thing, and
On 13 September 2013 22:40, Ethan Furman et...@stoneleaf.us wrote:
On 09/13/2013 06:25 PM, MRAB wrote:
On 14/09/2013 01:49, Steven D'Aprano wrote:
Is it more common to want both the canonical key and value at the same
time, or to just want the canonical key? My gut feeling is that I'm
On 09/13/2013 11:45 PM, Antoine Pitrou wrote:
On Fri, 13 Sep 2013 23:18:39 +0300
Serhiy Storchaka storch...@gmail.com wrote:
13.09.13 23:02, Antoine Pitrou написав(ла):
On Fri, 13 Sep 2013 16:54:01 -0300
Joao S. O. Bueno jsbu...@python.org.br wrote:
I see the PEP does not contemplate a
On 09/13/2013 10:09 PM, R. David Murray wrote:
On Fri, 13 Sep 2013 20:40:58 +0200, Antoine Pitrou solip...@pitrou.net
wrote:
Rationale
=
Numerous specialized versions of this pattern exist. The most common
is a case-insensitive case-preserving dict, i.e. a dict-like container
On 09/13/2013 08:40 PM, Antoine Pitrou wrote:
Hello,
Following the python-dev discussion, I've written a PEP to recap the
proposal and the various arguments. It's inlined below, and it will
probably appear soon at http://www.python.org/dev/peps/pep-0455/, too.
Looks good to me.
Georg
On 09/14/2013 03:40 AM, Antoine Pitrou wrote:
Hello,
Following the python-dev discussion, I've written a PEP to recap the
proposal and the various arguments. It's inlined below, and it will
probably appear soon at http://www.python.org/dev/peps/pep-0455/, too.
Whenever I read a discussion
On 09/13/2013 08:18 PM, Steven D'Aprano wrote:
You're missing that I'm not iterating over the entire dict, just some
subset (data) that I got from elsewhere.
Ah, okay. Between you and Antoine I am convinced that .getitem() is a good thing. So have that and .transform_key and
we're golden!
42 matches
Mail list logo
