2013/9/12 Ethan Furman :
> On 09/11/2013 02:39 PM, Tim Delaney wrote:
>>
>>
>> I would think that retrieving the keys from the dict would return the
>> transformed keys (I'd
>> call them canonical keys).
>
>
> The more I think about this the more I agree. A canonicaldict with a key
> function that
On 13 September 2013 01:40, Antoine Pitrou wrote:
> Le Thu, 12 Sep 2013 08:05:44 -0700,
> Ethan Furman a écrit :
> > On 09/12/2013 07:43 AM, Antoine Pitrou wrote:
> > >
> > > Yeah, so this is totally silly. What you're basically saying is "we
> > > don't need TransformDict since people can re-im
On 13 September 2013 07:29, Tim Delaney wrote:
>
> In this case though, there are two pieces of information:
>
> 1. A canonical key (which may or may not equal the original key);
>
> 2. The original key.
>
> It seems to me then that TransformDict is a specialised case of
> CanonicalDict, where th
On Thu, 12 Sep 2013 08:05:44 -0700, Ethan Furman wrote:
> On 09/12/2013 07:43 AM, Antoine Pitrou wrote:
> >
> > Yeah, so this is totally silly. What you're basically saying is "we
> > don't need TransformDict since people can re-implement it themselves".
>
> No, what I'm saying is that the "case-
On 09/12/2013 08:40 AM, Antoine Pitrou wrote:
Le Thu, 12 Sep 2013 08:05:44 -0700,
Ethan Furman a écrit :
On 09/12/2013 07:43 AM, Antoine Pitrou wrote:
Yeah, so this is totally silly. What you're basically saying is "we
don't need TransformDict since people can re-implement it
themselves".
N
On 9/12/2013 8:40 AM, Antoine Pitrou wrote:
Le Thu, 12 Sep 2013 08:05:44 -0700,
Ethan Furman a écrit :
On 09/12/2013 07:43 AM, Antoine Pitrou wrote:
Yeah, so this is totally silly. What you're basically saying is "we
don't need TransformDict since people can re-implement it
themselves".
No, w
Le Thu, 12 Sep 2013 08:05:44 -0700,
Ethan Furman a écrit :
> On 09/12/2013 07:43 AM, Antoine Pitrou wrote:
> >
> > Yeah, so this is totally silly. What you're basically saying is "we
> > don't need TransformDict since people can re-implement it
> > themselves".
>
> No, what I'm saying is that the
On 09/12/2013 07:43 AM, Antoine Pitrou wrote:
Yeah, so this is totally silly. What you're basically saying is "we
don't need TransformDict since people can re-implement it themselves".
No, what I'm saying is that the "case-preserving" aspect of transformdict is silly. The main point of transf
Le Thu, 12 Sep 2013 07:08:47 -0700,
Ethan Furman a écrit :
> On 09/11/2013 02:39 PM, Tim Delaney wrote:
> >
> > I would think that retrieving the keys from the dict would return
> > the transformed keys (I'd call them canonical keys).
>
> The more I think about this the more I agree. A canonical
On 09/11/2013 02:39 PM, Tim Delaney wrote:
I would think that retrieving the keys from the dict would return the
transformed keys (I'd
call them canonical keys).
The more I think about this the more I agree. A canonicaldict with a key function that simply stored the transformed
key and it's
On 09/11/2013 02:39 PM, Tim Delaney wrote:
On 12 September 2013 02:03, Ethan Furman mailto:et...@stoneleaf.us>> wrote:
On 09/11/2013 08:49 AM, Victor Stinner wrote:
2013/9/11 Ethan Furman mailto:et...@stoneleaf.us>>:
He isn't keeping the key unchanged (notice no white s
On 12 September 2013 02:03, Ethan Furman wrote:
> On 09/11/2013 08:49 AM, Victor Stinner wrote:
>
>> 2013/9/11 Ethan Furman :
>>
>>> He isn't keeping the key unchanged (notice no white space in MAPPING),
>>> he's
>>> merely providing a function that will automatically strip the whitespace
>>> fro
On 09/11/2013 10:49 AM, Antoine Pitrou wrote:
What I dislike is the idea of doing additional work because some
barriers are imposed ;-). PEP or PyPI are on a similar scale here. At
least a PEP would help record the various discussion details, so I'd
favour that over the PyPI path.
I would thin
On Wed, 11 Sep 2013 19:31:56 +0200
"Martin v. Löwis" wrote:
> Am 11.09.13 15:04, schrieb Antoine Pitrou:
> > There are not many possible APIs to create case-insensitive dicts, or
> > identity dicts.
>
> That is certainly not true. Most obviously, you have the choice of a
> specialized case-mappi
Am 11.09.13 15:04, schrieb Antoine Pitrou:
> There are not many possible APIs to create case-insensitive dicts, or
> identity dicts.
That is certainly not true. Most obviously, you have the choice of a
specialized case-mapping dict, or a generalized type that can be used
for case mapping also. Do
11.09.13 16:50, Stephen J. Turnbull написав(ла):
Which modules in the stdlib would benefit from rewriting using
"transformdict"? How about on PyPI?
At least _threading_local, cProfile, doctest, json, and perhaps future
implementations of __sizeof__ for some classes would benefit from
rewriti
2013/9/11 Ethan Furman :
> He isn't keeping the key unchanged (notice no white space in MAPPING), he's
> merely providing a function that will automatically strip the whitespace
> from key lookups.
transformdict keeps the key unchanged, see the first message:
>>> d = transformdict(str.lower)
Le Wed, 11 Sep 2013 07:48:56 -0700,
Ethan Furman a écrit :
> On 09/11/2013 06:58 AM, Victor Stinner wrote:
> >
> > The os.environ mapping uses a subclass of MutableMapping which
> > accepts 4 functions: encoder/decoder for the key and encoder/decoder
> > for the value. Such type is even more gener
On 09/11/2013 08:48 AM, Antoine Pitrou wrote:
Le Wed, 11 Sep 2013 07:48:56 -0700,
Ethan Furman a écrit :
Personally, I wouldn't mind having all four; for one thing, the name
'transformdict' would then be entirely appropriate. ;)
The key decoder function is quite useless since the original k
On 09/11/2013 08:49 AM, Victor Stinner wrote:
2013/9/11 Ethan Furman :
He isn't keeping the key unchanged (notice no white space in MAPPING), he's
merely providing a function that will automatically strip the whitespace
from key lookups.
transformdict keeps the key unchanged, see the first mes
On 09/11/2013 06:58 AM, Victor Stinner wrote:
The os.environ mapping uses a subclass of MutableMapping which
accepts 4 functions: encoder/decoder for the key and encoder/decoder
for the value. Such type is even more generic. transformdict cannot
replace os._Environ.
True, it's more generic --
On 09/11/2013 06:58 AM, Victor Stinner wrote:
2013/9/11 Steven D'Aprano :
But the proposal is not for a case-insensitive dict. It is more general
than that, with case-insensitivity just one specific use-case for such
a transformative dict. Arguably the most natural, or at least obvious,
such tra
On 09/11/2013 02:38 AM, Serhiy Storchaka wrote:
There is a question about specifying the transform function.
There are three ways to do this:
1. Positional argument of the constructor.
d = TransformDict(str.casefold, Foo=5)
This method follows the precedent of defaultdict:
--> from collecti
On 09/11/2013 05:47 AM, Nick Coghlan wrote:
On 11 September 2013 21:57, R. David Murray wrote:
Except it is wider than that: the transform function can be anything,
not just case folding.
I suggested surjectiondict or ontodict, but Antoine didn't like those :)
(I had to look up the terms...it'
Le Wed, 11 Sep 2013 22:50:08 +0900,
"Stephen J. Turnbull" a écrit :
> Antoine Pitrou writes:
>
> > ExitStack was quite a new thing, API-wise. The proposal here is to
> > generalize something which already exists in various forms all
> > over the Internet, and respecting a well-known API, Mutab
2013/9/11 Steven D'Aprano :
> But the proposal is not for a case-insensitive dict. It is more general
> than that, with case-insensitivity just one specific use-case for such
> a transformative dict. Arguably the most natural, or at least obvious,
> such transformation, but there are others.
>
> I
On Wed, Sep 11, 2013 at 10:47:12PM +1000, Nick Coghlan wrote:
> I'll join the chorus requesting that this live on PyPI for a while first.
Another alternative would be ActiveState's Python recipes:
http://code.activestate.com/recipes/langs/python
which is a lot lighter weight than creating a pac
Antoine Pitrou writes:
> ExitStack was quite a new thing, API-wise. The proposal here is to
> generalize something which already exists in various forms all over the
> Internet, and respecting a well-known API, MutableMapping.
What Nick said was "I was too close to the design, and time and a v
On Wed, Sep 11, 2013 at 06:08:25AM -0500, Skip Montanaro wrote:
> (I still don't care for the name. "Transform" != "case folding" in my
> mind. A quick scan of your links suggests most people think something
> like "cidict" or "CaseInsensitiveDict" would be more descriptive.)
But the proposal is
Le Wed, 11 Sep 2013 22:47:12 +1000,
Nick Coghlan a écrit :
>
> I'll join the chorus requesting that this live on PyPI for a while
> first.
>
> I think this is a case similar to what happened with
> contextlib.ExitStack: I'm not sure if anyone actually *used*
> contextlib2 for anything significan
On 11 September 2013 21:57, R. David Murray wrote:
> Except it is wider than that: the transform function can be anything,
> not just case folding.
>
> I suggested surjectiondict or ontodict, but Antoine didn't like those :)
> (I had to look up the terms...it's been a long time since I studied
> m
On Wed, 11 Sep 2013 06:08:25 -0500, Skip Montanaro wrote:
> > Seriously, I'm curious: what needs to mature, according to you?
>
> In my mind, its availability on PyPI along with demonstrated use in
> the wild (plus corresponding votes to demonstrate that people use/like
> it) would help. That yo
11.09.13 14:07, Antoine Pitrou написав(ла):
But I don't think the "type generator" API would be easier to implement
in C, anyway.
No, I mean subclassing approach.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/list
> Seriously, I'm curious: what needs to mature, according to you?
In my mind, its availability on PyPI along with demonstrated use in
the wild (plus corresponding votes to demonstrate that people use/like
it) would help. That you can find several implementations at this
doesn't mean it's necessar
Le Wed, 11 Sep 2013 13:37:53 +0300,
Serhiy Storchaka a écrit :
>
> Actually the defaultdict is just simple wrapper around existing
> functionality of the __missing__ method. We can add the __transform__
> method directly in the dict class. I think it will significant (2-3x)
> decrease a size o
11.09.13 12:52, Antoine Pitrou написав(ла):
Le Wed, 11 Sep 2013 12:38:13 +0300,
Serhiy Storchaka a écrit :
2. Subclassing.
class CaseInsensitiveDict(TransformDict):
def transform(self, key):
return key.casefold()
d = CaseInsensitiveDict(Foo=5)
I thought about this first, and
Le Wed, 11 Sep 2013 12:38:13 +0300,
Serhiy Storchaka a écrit :
> 2. Subclassing.
>
> class CaseInsensitiveDict(TransformDict):
> def transform(self, key):
> return key.casefold()
> d = CaseInsensitiveDict(Foo=5)
I thought about this first, and then I remembered that python-dev isn'
There is a question about specifying the transform function.
There are three ways to do this:
1. Positional argument of the constructor.
d = TransformDict(str.casefold, Foo=5)
2. Subclassing.
class CaseInsensitiveDict(TransformDict):
def transform(self, key):
return key.casefold()
Le Tue, 10 Sep 2013 21:40:36 -0500,
Raymond Hettinger a écrit :
>
> On Sep 10, 2013, at 4:28 AM, Antoine Pitrou
> wrote:
>
> > In http://bugs.python.org/issue18986 I proposed adding a new mapping
> > type to the collections module.
>
> I would *really* like for this to start outside the standa
On Sep 10, 2013, at 4:28 AM, Antoine Pitrou wrote:
> In http://bugs.python.org/issue18986 I proposed adding a new mapping
> type to the collections module.
I would *really* like for this to start outside the standard library.
It needs to mature with user feedback before being dumped
in the coll
On 10 September 2013 18:46, Antoine Pitrou wrote:
> On Tue, 10 Sep 2013 18:44:20 -0300
> "Joao S. O. Bueno" wrote:
>> On 10 September 2013 18:06, Antoine Pitrou wrote:
>> > On Tue, 10 Sep 2013 17:38:26 -0300
>> > "Joao S. O. Bueno" wrote:
>> >> On 10 September 2013 16:08, Paul Moore wrote:
>>
On 09/10/2013 05:26 PM, Eric V. Smith wrote:
On 9/10/2013 6:18 PM, Ethan Furman wrote:
On 09/10/2013 03:12 PM, MRAB wrote:
On 10/09/2013 22:46, Antoine Pitrou wrote:
On Tue, 10 Sep 2013 18:44:20 -0300
"Joao S. O. Bueno" wrote:
On 10 September 2013 18:06, Antoine Pitrou wrote:
On Tue, 10 Se
On 9/10/2013 2:46 PM, Antoine Pitrou wrote:
> >>Which reminds one - this class should obviously have a method for
> >>retrivieng the original key value, given a matching key -
> >>
> >>d.canonical('foo') -> 'Foo'
> >
> >I don't know. Is there any use case?
> >(sure, it is trivially implemented)
On 9/10/2013 6:18 PM, Ethan Furman wrote:
> On 09/10/2013 03:12 PM, MRAB wrote:
>> On 10/09/2013 22:46, Antoine Pitrou wrote:
>>> On Tue, 10 Sep 2013 18:44:20 -0300
>>> "Joao S. O. Bueno" wrote:
On 10 September 2013 18:06, Antoine Pitrou wrote:
> On Tue, 10 Sep 2013 17:38:26 -0300
On 09/10/2013 03:12 PM, MRAB wrote:
On 10/09/2013 22:46, Antoine Pitrou wrote:
On Tue, 10 Sep 2013 18:44:20 -0300
"Joao S. O. Bueno" wrote:
On 10 September 2013 18:06, Antoine Pitrou wrote:
> On Tue, 10 Sep 2013 17:38:26 -0300
> "Joao S. O. Bueno" wrote:
>> On 10 September 2013 16:08, Paul M
On Tue, 10 Sep 2013 18:44:20 -0300
"Joao S. O. Bueno" wrote:
> On 10 September 2013 18:06, Antoine Pitrou wrote:
> > On Tue, 10 Sep 2013 17:38:26 -0300
> > "Joao S. O. Bueno" wrote:
> >> On 10 September 2013 16:08, Paul Moore wrote:
> >> > If you provide "retain the last", I can't see any obvio
On 09/10/2013 01:36 PM, Lukas Lueg wrote:
Should'nt the key'ing behaviour be controlled by the type of the key instead of
the type of the container?
That would be up to the key function.
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
On 10 September 2013 18:06, Antoine Pitrou wrote:
> On Tue, 10 Sep 2013 17:38:26 -0300
> "Joao S. O. Bueno" wrote:
>> On 10 September 2013 16:08, Paul Moore wrote:
>> > If you provide "retain the last", I can't see any obvious way of
>> > implementing "retain the first" in application code witho
On 10/09/2013 22:46, Antoine Pitrou wrote:
On Tue, 10 Sep 2013 18:44:20 -0300
"Joao S. O. Bueno" wrote:
On 10 September 2013 18:06, Antoine Pitrou wrote:
> On Tue, 10 Sep 2013 17:38:26 -0300
> "Joao S. O. Bueno" wrote:
>> On 10 September 2013 16:08, Paul Moore wrote:
>> > If you provide "ret
Should'nt the key'ing behaviour be controlled by the type of the key
instead of the type of the container?
2013/9/10 MRAB
> On 10/09/2013 20:08, Paul Moore wrote:
>
>> On 10 September 2013 19:31, Antoine Pitrou wrote:
>>
>>> I think it would be a flaw to have this detail implementation-defined
On 10 September 2013 20:59, MRAB wrote:
>> try:
>> del d[k]
>> finally:
>> d[k] = v
>>
> That would raise a KeyError is the key was missing. A better way is:
>
> d.pop(k, None)
Sorry, I was thinking of try...except: pass. But pop is indeed better.
Teach me to code stuff on the fly witho
On 10 September 2013 16:08, Paul Moore wrote:
> If you provide "retain the last", I can't see any obvious way of
> implementing "retain the first" in application code without in effect
> reimplementing the class.
Which reminds one - this class should obviously have a method for
retrivieng the ori
On Tue, 10 Sep 2013 17:38:26 -0300
"Joao S. O. Bueno" wrote:
> On 10 September 2013 16:08, Paul Moore wrote:
> > If you provide "retain the last", I can't see any obvious way of
> > implementing "retain the first" in application code without in effect
> > reimplementing the class.
>
> Which remi
On 10/09/2013 20:08, Paul Moore wrote:
On 10 September 2013 19:31, Antoine Pitrou wrote:
I think it would be a flaw to have this detail implementation-defined.
This would be like saying that it is implementation-defined which
of A,B,C is returned from "A and B and C" if all are true.
Ok, it s
On 10 September 2013 19:31, Antoine Pitrou wrote:
>> I think it would be a flaw to have this detail implementation-defined.
>> This would be like saying that it is implementation-defined which
>> of A,B,C is returned from "A and B and C" if all are true.
>
> Ok, it seems everyone (except me :-)) a
On Tue, 10 Sep 2013 14:44:01 +0200
"Martin v. Löwis" wrote:
> Am 10.09.13 14:35, schrieb Antoine Pitrou:
> >> ['FOO'] or ['foo']? Both answers are justifiable. Both are possibly
> >> even useful depending on context...
> >
> > I think it would be best to leave it as an implementation detail,
> >
On Tue, 10 Sep 2013 16:21:18 +0100, Nigel Small wrote:
> Could a more generic variant of this class work? In the same way that
> `sorted` can accept a comparison function, similar could be done for a
> dictionary-like class:
>
> d = transformdict(key=str.lower)
>
> Strictly speaking, this would
On 09/10/2013 07:54 AM, Antoine Pitrou wrote:
Le Tue, 10 Sep 2013 15:09:56 +0200,
Hrvoje Niksic a écrit :
On 09/10/2013 02:24 PM, Paul Moore wrote:
td['FOO'] = 42
td['foo'] = 32
list(td.keys())
['FOO'] or ['foo']? Both answers are justifiable.
Note that the same question can be reasonably
Could a more generic variant of this class work? In the same way that
`sorted` can accept a comparison function, similar could be done for a
dictionary-like class:
d = transformdict(key=str.lower)
Strictly speaking, this would provide case-insensitive but not
case-preserving behaviour. For any gi
On 9/10/2013 8:54 AM, Janzert wrote:
I intuitively expected, and I think most often would want, the first
key to be held.
My intuition matches yours, but my thoughts are that it should be
changeable by specific request.
___
Python-Dev mailing list
On 09/10/2013 11:54 AM, Janzert wrote:
> On 9/10/2013 10:54 AM, Antoine Pitrou wrote:
>> (also, I would intuitively expect the latest key to be held, not the
>> first one, since that's what happens for values.)
>>
>> Regards
>>
>> Antoine.
>>
>
> I intuitively expected, and I think most often woul
On 9/10/2013 10:54 AM, Antoine Pitrou wrote:
(also, I would intuitively expect the latest key to be held, not the
first one, since that's what happens for values.)
Regards
Antoine.
I intuitively expected, and I think most often would want, the first key
to be held. The reason being that I w
On 09/10/2013 06:09 AM, Hrvoje Niksic wrote:
On 09/10/2013 02:24 PM, Paul Moore wrote:
td['FOO'] = 42
td['foo'] = 32
list(td.keys())
['FOO'] or ['foo']? Both answers are justifiable.
Note that the same question can be reasonably asked for dict itself:
d = {}
d[1.0] = 'foo'
d[1] = 'bar'
d
On 10/09/2013 3:15pm, Armin Rigo wrote:
Hi Richard,
On Tue, Sep 10, 2013 at 3:42 PM, Richard Oudkerk wrote:
I guess another example is creating an "identity dict" (see
http://code.activestate.com/lists/python-ideas/7161/) by doing
d = transformdict(id)
This is bogus, because only the i
Le Tue, 10 Sep 2013 16:15:56 +0200,
Armin Rigo a écrit :
> Hi Richard,
>
> On Tue, Sep 10, 2013 at 3:42 PM, Richard Oudkerk
> wrote:
> > I guess another example is creating an "identity dict" (see
> > http://code.activestate.com/lists/python-ideas/7161/) by doing
> >
> > d = transformdict(id
Le Tue, 10 Sep 2013 15:09:56 +0200,
Hrvoje Niksic a écrit :
> On 09/10/2013 02:24 PM, Paul Moore wrote:
> td['FOO'] = 42
> td['foo'] = 32
> list(td.keys())
> >
> > ['FOO'] or ['foo']? Both answers are justifiable.
>
> Note that the same question can be reasonably asked for dict its
On Tue, Sep 10, 2013 at 11:28 AM, Antoine Pitrou wrote:
> Therefore I propose adding the general pattern. Simple example:
>
>>>> d = transformdict(str.lower)
>>>> d['Foo'] = 5
>>>> d['foo']
>5
>>>> d['FOO']
>5
>>>> list(d)
>['Foo']
>
> (case-insensitive but case-pre
Le Tue, 10 Sep 2013 07:18:41 -0700,
Eli Bendersky a écrit :
> On Tue, Sep 10, 2013 at 5:22 AM, Antoine Pitrou
> wrote:
>
> > Le Tue, 10 Sep 2013 22:00:37 +1000,
> > Nick Coghlan a écrit :
> > > Is this just syntactic sugar for recursive lookup of a transformed
> > > version in __missing__?
> >
On Tue, Sep 10, 2013 at 5:22 AM, Antoine Pitrou wrote:
> Le Tue, 10 Sep 2013 22:00:37 +1000,
> Nick Coghlan a écrit :
> > Is this just syntactic sugar for recursive lookup of a transformed
> > version in __missing__?
>
> Nope. For one, it doesn't use __missing__ at all. I think
> using __missing
Hi Richard,
On Tue, Sep 10, 2013 at 3:42 PM, Richard Oudkerk wrote:
> I guess another example is creating an "identity dict" (see
> http://code.activestate.com/lists/python-ideas/7161/) by doing
>
> d = transformdict(id)
This is bogus, because only the id will be stored, and the original
key
On Sep 10, 2013, at 03:57 PM, Antoine Pitrou wrote:
>Le Tue, 10 Sep 2013 09:49:28 -0400,
>Barry Warsaw a écrit :
>> On Sep 10, 2013, at 12:04 PM, Victor Stinner wrote:
>>
>> >The http.client and email.message modules convert headers to lower
>> >case, but keep the original case.
>>
>> As RDM po
Le Tue, 10 Sep 2013 09:49:28 -0400,
Barry Warsaw a écrit :
> On Sep 10, 2013, at 12:04 PM, Victor Stinner wrote:
>
> >The http.client and email.message modules convert headers to lower
> >case, but keep the original case.
>
> As RDM pointed out on the tracker, email headers aren't a great use
>
On Sep 10, 2013, at 12:04 PM, Victor Stinner wrote:
>The http.client and email.message modules convert headers to lower
>case, but keep the original case.
As RDM pointed out on the tracker, email headers aren't a great use case for
this because they aren't really dictionaries. They're lists with
On 10/09/2013 10:28am, Antoine Pitrou wrote:
Therefore I propose adding the general pattern. Simple example:
>>> d = transformdict(str.lower)
>>> d['Foo'] = 5
>>> d['foo']
5
>>> d['FOO']
5
>>> list(d)
['Foo']
I guess another example is creating an "identity dict
On 09/10/2013 02:24 PM, Paul Moore wrote:
td['FOO'] = 42
td['foo'] = 32
list(td.keys())
['FOO'] or ['foo']? Both answers are justifiable.
Note that the same question can be reasonably asked for dict itself:
>>> d = {}
>>> d[1.0] = 'foo'
>>> d[1] = 'bar'
>>> d
{1.0: 'bar'}
So, dict.__setitem
Am 10.09.13 14:35, schrieb Antoine Pitrou:
>> ['FOO'] or ['foo']? Both answers are justifiable. Both are possibly
>> even useful depending on context...
>
> I think it would be best to leave it as an implementation detail,
> because whichever is easiest to implement depends on the exact
> implemen
Le Tue, 10 Sep 2013 13:24:29 +0100,
Paul Moore a écrit :
> On 10 September 2013 13:00, Nick Coghlan wrote:
> > Is this just syntactic sugar for recursive lookup of a transformed
> > version in __missing__? Or a way of supplying a custom "key"
> > function to a dictionary?
>
> Not quite, because
On 10 September 2013 13:00, Nick Coghlan wrote:
> Is this just syntactic sugar for recursive lookup of a transformed version
> in __missing__? Or a way of supplying a custom "key" function to a
> dictionary?
Not quite, because the dict should preserve the originally entered key.
>>> td['FOO'] =
On 10 September 2013 13:24, Paul Moore wrote:
> On 10 September 2013 13:00, Nick Coghlan wrote:
>> Is this just syntactic sugar for recursive lookup of a transformed version
>> in __missing__? Or a way of supplying a custom "key" function to a
>> dictionary?
>
> Not quite, because the dict should
Le Tue, 10 Sep 2013 22:00:37 +1000,
Nick Coghlan a écrit :
> Is this just syntactic sugar for recursive lookup of a transformed
> version in __missing__?
Nope. For one, it doesn't use __missing__ at all. I think
using __missing__ would be... missing the point, because it wouldn't
working properly
Is this just syntactic sugar for recursive lookup of a transformed version
in __missing__? Or a way of supplying a custom "key" function to a
dictionary?
Any such proposal should consider how it composes with other dict variants
like defaultdict, OrderedDict and counter.
Cheers,
Nick.
___
On Tue, Sep 10, 2013 at 11:28 AM, Antoine Pitrou wrote:
> On the tracker issue, it seems everyone agreed on the principle. There
> is some bikeshedding left to do, though. So here are the reasonable
> naming proposals so far:
>
> - transformkeydict
> - coercekeydict
> - transformdict
> - coercedic
On 10 September 2013 10:28, Antoine Pitrou wrote:
> On the tracker issue, it seems everyone agreed on the principle. There
> is some bikeshedding left to do, though. So here are the reasonable
> naming proposals so far:
>
> - transformkeydict
> - coercekeydict
> - transformdict
> - coercedict
>
>
2013/9/10 Antoine Pitrou :
> In http://bugs.python.org/issue18986 I proposed adding a new mapping
> type to the collections module.
>
> The original use case is quite common in network programming and
> elsewhere (Eric Snow on the tracker mentioned an application with stock
> symbols). You want to
Le Tue, 10 Sep 2013 04:42:46 -0500,
Skip Montanaro a écrit :
> > (case-insensitive but case-preserving, as the best filesystems
> > are ;-))
>
> > I have a sweet spot for "transformdict" myself.
>
> Antoine,
>
> "Transform" does not remind me of "case-insensitive but
> case-preserving".
That w
> (case-insensitive but case-preserving, as the best filesystems are ;-))
> I have a sweet spot for "transformdict" myself.
Antoine,
"Transform" does not remind me of "case-insensitive but
case-preserving". If this is important enough to put into the
collections module (I'm skeptical), shouldn't
86 matches
Mail list logo
