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
Hello,
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 have an associative container
87 matches
Mail list logo
