Thanks for this thorough review, Raymond! Especially the user research is
amazing.
And thanks for Antoine for writing the PEP -- you never know how an idea
pans out until you've tried it.
--Guido
On Thu, May 14, 2015 at 7:29 AM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
Before
On 15 May 2015 at 00:41, Guido van Rossum gu...@python.org wrote:
Thanks for this thorough review, Raymond! Especially the user research is
amazing.
And thanks for Antoine for writing the PEP -- you never know how an idea
pans out until you've tried it.
Hear, hear! I thought the
On Oct 28, 2013, at 1:16 PM, Victor Stinner victor.stin...@gmail.com wrote:
so what is the
status of the PEP 455 (TransformDict)?
I'm giving a thorough evaluation of the proposal
and am devoting chunks of time each weekend
to reviewing the email threads, the links provided
in the PEPs,
On Wed, 30 Oct 2013 01:12:03 -0600, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
If I had to choose right now, a safe choice would be to focus on
the primary use case and implement a clean CaseInsensitiveDict
without the double-dict first-saved case-preserving feature.
That said, I
On Wed, 30 Oct 2013 01:12:03 -0600, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
I'm giving a thorough evaluation of the proposal
and am devoting chunks of time each weekend
to reviewing the email threads, the links provided
in the PEPs, looking at how well the TD fits in existing
On 10/30/2013 12:12 AM, Raymond Hettinger wrote:
Hopefully, this post will make the thought process more transparent.
Thanks, Raymond. Your time is appreciated.
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
It strikes me that there could be an alternative approach to some of the
use cases discussed here. Instead of a new type of dictionary, the
case-insensitivity problem could be solved with something akin to a *
CaseInsensitiveString* class used for keys within a standard dictionary.
This would be
On 10/30/2013 09:34 AM, Nigel Small wrote:
It strikes me that there could be an alternative approach to some of the use
cases discussed here. Instead of a new type
of dictionary, the case-insensitivity problem could be solved with something
akin to a *CaseInsensitiveString* class [...]
The
True, but I could similarly argue that the nice thing about
CaseInsensitiveString is it is usable for much more than dictionary keys -
it just depends on your point of view.
There would be nothing stopping other types of dictionary key
transformation being covered by other key data types in a
On Wed, 30 Oct 2013 16:34:33 +
Nigel Small ni...@nigelsmall.com wrote:
It strikes me that there could be an alternative approach to some of the
use cases discussed here. Instead of a new type of dictionary, the
case-insensitivity problem could be solved with something akin to a *
And how does a case-insensitive string compare with a normal
(case-sensitive) string? This is a can of worms.
I was wondering this myself. I suspect it would depend which string is
on the left hand side of the comparison operator, yes? Can of worms,
indeed.
implicit-insensitve-i-n-ly, y'rs,
Hi Raymond,
On Wed, 30 Oct 2013 01:12:03 -0600
Raymond Hettinger raymond.hettin...@gmail.com wrote:
On Oct 28, 2013, at 1:16 PM, Victor Stinner victor.stin...@gmail.com wrote:
so what is the
status of the PEP 455 (TransformDict)?
I'm giving a thorough evaluation of the proposal
2013/10/4 Raymond Hettinger raymond.hettin...@gmail.com:
On Sep 22, 2013, at 6:16 PM, Ethan Furman et...@stoneleaf.us wrote:
Are we close to asking for pronouncement?
When you're ready, let me know.
The deadline for new features is in less than 1 month, so what is the
status of the PEP 455
On 9 Oct 2013 01:07, Antoine Pitrou solip...@pitrou.net wrote:
Le Tue, 8 Oct 2013 22:49:28 +1000,
Nick Coghlan ncogh...@gmail.com a écrit :
Well, you could ask the same question about OrderedDict,
defaultdict or Weak*Dictionary since neither of them use
composition :-)
We *did* ask
On Tue, 8 Oct 2013 08:31:46 +1000
Nick Coghlan ncogh...@gmail.com wrote:
That said, with the current plan to lower the barrier to entry for PyPI
dependencies (I should have the 3.4 only ensurepip proposal written up some
time this week), I think it makes sense to let this one bake on PyPI for
Le Tue, 8 Oct 2013 08:21:43 +0200,
Antoine Pitrou solip...@pitrou.net a écrit :
I think there *is* a potentially worthwhile generalisation here,
but I'm far from sure is-a-dict is the right data model - for
composability reasons, it feels like a has-a relationship with an
underlying data
On 8 Oct 2013 18:36, Antoine Pitrou solip...@pitrou.net wrote:
Le Tue, 8 Oct 2013 08:21:43 +0200,
Antoine Pitrou solip...@pitrou.net a écrit :
I think there *is* a potentially worthwhile generalisation here,
but I'm far from sure is-a-dict is the right data model - for
composability
Le Tue, 8 Oct 2013 22:12:02 +1000,
Nick Coghlan ncogh...@gmail.com a écrit :
It's OK if the key transforming API has to constrain the behaviour of
the underlying mapping or require an appropriately designed transform
function to handle more esoteric containers. Either would still be
better
On 8 Oct 2013 22:31, Antoine Pitrou solip...@pitrou.net wrote:
Le Tue, 8 Oct 2013 22:12:02 +1000,
Nick Coghlan ncogh...@gmail.com a écrit :
It's OK if the key transforming API has to constrain the behaviour of
the underlying mapping or require an appropriately designed transform
Le Tue, 8 Oct 2013 22:49:28 +1000,
Nick Coghlan ncogh...@gmail.com a écrit :
Well, you could ask the same question about OrderedDict,
defaultdict or Weak*Dictionary since neither of them use
composition :-)
We *did* ask the same question about those (except the Weak* variants,
simply due
On Fri, Sep 13, 2013 at 10:40 PM, Antoine Pitrou solip...@pitrou.netwrote:
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.
On 08/10/2013 19:02, Yuriy Taraday wrote:
On Fri, Sep 13, 2013 at 10:40 PM, Antoine Pitrou solip...@pitrou.net
mailto:solip...@pitrou.net 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
On Tue, 08 Oct 2013 22:02:43 +0400, Yuriy Taraday yorik@gmail.com wrote:
There should be a way to avoid creation of the second dict when there is no
need to store original keys. For example, email.message module doesn't
store original headers as they are not needed. The same applies to web
On Tue, Oct 8, 2013 at 10:17 PM, MRAB pyt...@mrabarnett.plus.com wrote:
If you don't need the original key, then you might as well just use a
transform function with a dict.
As I understood, storing original keys is not the purpose of TransformDict,
allowing hashing on something other then
On Tue, 8 Oct 2013 23:36:05 +0400
Yuriy Taraday yorik@gmail.com wrote:
On Tue, Oct 8, 2013 at 10:17 PM, MRAB pyt...@mrabarnett.plus.com wrote:
If you don't need the original key, then you might as well just use a
transform function with a dict.
As I understood, storing original keys
In article c4c036b6-130c-4718-beb1-a7c923008...@gmail.com,
Raymond Hettinger raymond.hettin...@gmail.com wrote:
On Sep 22, 2013, at 6:16 PM, Ethan Furman et...@stoneleaf.us wrote:
Are we close to asking for pronouncement?
When you're ready, let me know.
In the meantime, I conducting
100% disagreement. Err, well, 50%.
A property of existing dictionaries is useless. A separate object in, say,
collections is more organized.
3rd party libraries can be hard to find, even the great ones.
On Mon, Oct 7, 2013 at 3:01 PM, Russell E. Owen ro...@uw.edu wrote:
In article
On Fri, Oct 04, 2013 at 11:06:15PM +0200, Victor Stinner wrote:
(If we cannot find a better name, we may add more specialized classes:
KeyInsensitiveDict and IdentiyDict. But I like the idea of using my
own transform function.)
-1 on a plethora of specialised dicts.
I do think that a
On 8 Oct 2013 07:26, Steven D'Aprano st...@pearwood.info wrote:
On Fri, Oct 04, 2013 at 11:06:15PM +0200, Victor Stinner wrote:
(If we cannot find a better name, we may add more specialized classes:
KeyInsensitiveDict and IdentiyDict. But I like the idea of using my
own transform
On 10/07/2013 02:24 PM, Steven D'Aprano wrote:
On Fri, Oct 04, 2013 at 11:06:15PM +0200, Victor Stinner wrote:
if type(self) is not dict:
# This only applies to subclasses, not dict itself.
try:
transform = type(self).__transform__
except AttributeError:
pass
On Mon, Oct 07, 2013 at 02:55:44PM -0700, Ethan Furman wrote:
On 10/07/2013 02:24 PM, Steven D'Aprano wrote:
On Fri, Oct 04, 2013 at 11:06:15PM +0200, Victor Stinner wrote:
if type(self) is not dict:
# This only applies to subclasses, not dict itself.
try:
transform =
On 10/07/2013 02:55 PM, Ethan Furman wrote:
A key difference (pun unavoidable ;) between __missing__ and __transform__ is
that __missing__ is only called when a key
is not found, while __transform__ needs to be called /every/ time a key is
looked up:
d[k]
d.get(k)
d.has_key(k)
Sorry I missed the original discussion, but isn't this a simple case
of putting a decorator around the getitem method (to transform the
input key) and a single line in the body of the setitem method, making
this very easy adaptation of the existing dict class?
Mark
On Mon, Oct 07, 2013 at 06:17:09PM -0700, Mark Janssen wrote:
Sorry I missed the original discussion, but isn't this a simple case
of putting a decorator around the getitem method (to transform the
input key) and a single line in the body of the setitem method, making
this very easy adaptation
06.10.13 00:08, Victor Stinner написав(ла):
2013/10/4 Raymond Hettinger raymond.hettin...@gmail.com javascript:;:
This contrasts with other tools like OrderedDict, ChainMap,
and namedtuple which started their lives outside the standard
library where we we able observe their fitness for
On Sep 22, 2013, at 6:16 PM, Ethan Furman et...@stoneleaf.us wrote:
Are we close to asking for pronouncement?
When you're ready, let me know.
In the meantime, I conducting usability tests on students in Python classes
and researching how well it substitutes for existing solutions for
case
2013/10/4 Raymond Hettinger raymond.hettin...@gmail.com:
* Another issue is that we're accumulating too many dictionary
variants and that is making it difficult to differentiate and choose
between them. I haven't found anyone (even in advanced classes
with very experienced pythonistas) would
Good evening,
On Fri, 4 Oct 2013 13:38:05 -0700
Raymond Hettinger raymond.hettin...@gmail.com wrote:
You can also add to the discussion by trying out your own usability
tests on people who haven't been exposed to this thread or the pep.
I think usability tests should be conducted on people
On Oct 4, 2013, at 2:06 PM, Victor Stinner victor.stin...@gmail.com wrote:
I'm not convinced by your usability test.
You're not the one who needs to be convinced ;-)
Please do conduct your own API tests and report back.
This is necessary for a new class like TransformDict
that was
On Oct 4, 2013, at 2:14 PM, Antoine Pitrou solip...@pitrou.net wrote:
I think usability tests should be conducted on people who actually
have a need for the API. Otherwise they simply don't make sense: if you
don't need an API, then you don't have to learn / understand it either.
You're
On 09/14/2013 12:31 PM, Guido van Rossum wrote:
On Fri, Sep 13, 2013 at 11:40 AM, Antoine Pitrou wrote:
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
On Sun, 15 Sep 2013 13:56:26 +0900
Larry Hastings la...@hastings.org wrote:
On 09/14/2013 07:30 PM, Antoine Pitrou wrote:
On Sat, 14 Sep 2013 14:33:56 +0900
Larry Hastings la...@hastings.org wrote:
Whenever I read a discussion about the dict, I always wonder whether the
same thing applies
15.09.13 14:23, Antoine Pitrou написав(ла):
On Sun, 15 Sep 2013 13:56:26 +0900
Larry Hastings la...@hastings.org wrote:
On 09/14/2013 07:30 PM, Antoine Pitrou wrote:
On Sat, 14 Sep 2013 14:33:56 +0900
Larry Hastings la...@hastings.org wrote:
Whenever I read a discussion about the dict, I
On Sun, 15 Sep 2013 16:14:24 +0300
Serhiy Storchaka storch...@gmail.com wrote:
15.09.13 14:23, Antoine Pitrou написав(ла):
On Sun, 15 Sep 2013 13:56:26 +0900
Larry Hastings la...@hastings.org wrote:
On 09/14/2013 07:30 PM, Antoine Pitrou wrote:
On Sat, 14 Sep 2013 14:33:56 +0900
Larry
15.09.13 16:57, Antoine Pitrou написав(ла):
I don't really care. What's the point in the end? TransformDict is
non-trivial to implement, while the so-called TransformSet is just a
dict with a different API.
I don't see a difference. To me TransformDict is just a dict (or two).
On Sun, 15 Sep 2013 17:45:00 +0300
Serhiy Storchaka storch...@gmail.com wrote:
15.09.13 16:57, Antoine Pitrou написав(ла):
I don't really care. What's the point in the end? TransformDict is
non-trivial to implement, while the so-called TransformSet is just a
dict with a different API.
I
On 16 September 2013 00:45, Serhiy Storchaka storch...@gmail.com wrote:
15.09.13 16:57, Antoine Pitrou написав(ла):
I don't really care. What's the point in the end? TransformDict is
non-trivial to implement, while the so-called TransformSet is just a
dict with a different API.
I don't see
On 09/13/2013 09:53 PM, Joao S. O. Bueno wrote:
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
On Fri, 13 Sep 2013 21:59:11 -0700
Ethan Furman et...@stoneleaf.us wrote:
I mean - given no function to retrieve the canonical key,
one would have to resort to:
my_key = data.__transform__(given_key)
for key, value in data.items():
if data.__transform__(key) == my_key:
On Sat, 14 Sep 2013 14:33:56 +0900
Larry Hastings la...@hastings.org wrote:
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
On 14 September 2013 12:44, Steven D'Aprano st...@pearwood.info wrote:
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
On 14 September 2013 12:44, Steven D'Aprano st...@pearwood.info wrote:
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
On 14/09/2013 05:47, Ethan Furman wrote:
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
On 09/14/2013 03:27 AM, Antoine Pitrou wrote:
On Fri, 13 Sep 2013 21:59:11 -0700
Ethan Furman et...@stoneleaf.us wrote:
I mean - given no function to retrieve the canonical key,
one would have to resort to:
my_key = data.__transform__(given_key)
for key, value in data.items():
if
On Sat, 14 Sep 2013 09:43:13 -0700
Ethan Furman et...@stoneleaf.us wrote:
On 09/14/2013 03:27 AM, Antoine Pitrou wrote:
On Fri, 13 Sep 2013 21:59:11 -0700
Ethan Furman et...@stoneleaf.us wrote:
I mean - given no function to retrieve the canonical key,
one would have to resort to:
On 09/14/2013 10:41 AM, Antoine Pitrou wrote:
On Sat, 14 Sep 2013 09:43:13 -0700 Ethan Furman wrote:
Still, I think it would be useful to expose the transform function.
Any good reason not to?
No good reason. What's the name? transform_func?
I had originally thought transform_key, but
14.09.13 20:41, Antoine Pitrou написав(ла):
On Sat, 14 Sep 2013 09:43:13 -0700
Ethan Furman et...@stoneleaf.us wrote:
Still, I think it would be useful to expose the transform function.
Any good reason not to?
No good reason. What's the name? transform_func?
There is one reason --
On Sat, 14 Sep 2013 22:07:50 +0300
Serhiy Storchaka storch...@gmail.com wrote:
14.09.13 20:41, Antoine Pitrou написав(ла):
On Sat, 14 Sep 2013 09:43:13 -0700
Ethan Furman et...@stoneleaf.us wrote:
Still, I think it would be useful to expose the transform function.
Any good reason not to?
On Fri, Sep 13, 2013 at 11:40 AM, Antoine Pitrou solip...@pitrou.netwrote:
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.
Thanks,
On Sat, 14 Sep 2013 12:31:36 -0700
Guido van Rossum gu...@python.org wrote:
On Fri, Sep 13, 2013 at 11:40 AM, Antoine Pitrou solip...@pitrou.netwrote:
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
14.09.13 20:41, Antoine Pitrou написав(ла):
No good reason. What's the name? transform_func?
transform_func looks... truncated. Why not transform_function or trans_func?
___
Python-Dev mailing list
Python-Dev@python.org
On Sun, 15 Sep 2013 00:55:35 +0300
Serhiy Storchaka storch...@gmail.com wrote:
14.09.13 20:41, Antoine Pitrou написав(ла):
No good reason. What's the name? transform_func?
transform_func looks... truncated. Why not transform_function or trans_func?
The stdlib commonly uses func rather than
On Sat, Sep 14, 2013 at 2:55 PM, Serhiy Storchaka storch...@gmail.comwrote:
14.09.13 20:41, Antoine Pitrou написав(ла):
No good reason. What's the name? transform_func?
transform_func looks... truncated. Why not transform_function or
trans_func?
transform_λ
On 14/09/13 23:31, Eli Bendersky wrote:
On Sat, Sep 14, 2013 at 2:55 PM, Serhiy Storchaka storch...@gmail.com
mailto:storch...@gmail.com wrote:
14.09.13 20:41, Antoine Pitrou написав(ла):
No good reason. What's the name? transform_func?
transform_func looks... truncated.
15.09.13 00:58, Antoine Pitrou написав(ла):
On Sun, 15 Sep 2013 00:55:35 +0300
Serhiy Storchaka storch...@gmail.com wrote:
14.09.13 20:41, Antoine Pitrou написав(ла):
No good reason. What's the name? transform_func?
transform_func looks... truncated. Why not transform_function or trans_func?
On 09/14/2013 05:32 PM, Serhiy Storchaka wrote:
15.09.13 00:58, Antoine Pitrou написав(ла):
On Sun, 15 Sep 2013 00:55:35 +0300
Serhiy Storchaka storch...@gmail.com wrote:
14.09.13 20:41, Antoine Pitrou написав(ла):
No good reason. What's the name? transform_func?
transform_func looks...
On 09/14/2013 07:30 PM, Antoine Pitrou wrote:
On Sat, 14 Sep 2013 14:33:56 +0900
Larry Hastings la...@hastings.org wrote:
Whenever I read a discussion about the dict, I always wonder whether the
same thing applies to a set. Have you considered the utility of a
TransformSet? Or is it YAGNI?
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 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
1 - 100 of 101 matches
Mail list logo
