On 15 May 2015 at 00:41, Guido van Rossum 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 TransformDict idea soun
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
Before the Python 3.5 feature freeze, I should step-up and
formally reject PEP 455 for "Adding a key-transforming
dictionary to collections".
I had completed an involved review effort a long time ago
and I apologize for the delay in making the pronouncement.
What made it a interesting choice from
Hi Raymond,
On Wed, 30 Oct 2013 01:12:03 -0600
Raymond Hettinger wrote:
>
> On Oct 28, 2013, at 1:16 PM, Victor Stinner 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
> 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,
On Wed, 30 Oct 2013 16:34:33 +
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* cla
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 simi
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 n
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 ve
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
https://mail.python.org/ma
On Wed, 30 Oct 2013 01:12:03 -0600, Raymond Hettinger
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 code.
>
> I'm giving this
On Wed, 30 Oct 2013 01:12:03 -0600, Raymond Hettinger
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 find the TD to be fascinat
On Oct 28, 2013, at 1:16 PM, Victor Stinner 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, looking at how well the TD f
2013/10/4 Raymond Hettinger :
>> On Sep 22, 2013, at 6:16 PM, Ethan Furman 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 (TransformDict)?
Victor
___
On 9 Oct 2013 01:07, "Antoine Pitrou" wrote:
>
> Le Tue, 8 Oct 2013 22:49:28 +1000,
> Nick Coghlan 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 a
On Tue, 8 Oct 2013 23:36:05 +0400
Yuriy Taraday wrote:
> On Tue, Oct 8, 2013 at 10:17 PM, MRAB 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,
>
On Tue, Oct 8, 2013 at 10:17 PM, MRAB 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 provided key itself is. Thi
On Tue, 08 Oct 2013 22:02:43 +0400, Yuriy Taraday 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
> frameworks pars
On 08/10/2013 19:02, Yuriy Taraday wrote:
On Fri, Sep 13, 2013 at 10:40 PM, Antoine Pitrou 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 it will
probabl
On Fri, Sep 13, 2013 at 10: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.
>
> Regards
>
>
Le Tue, 8 Oct 2013 22:49:28 +1000,
Nick Coghlan 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 to age).
On 8 Oct 2013 22:31, "Antoine Pitrou" wrote:
>
> Le Tue, 8 Oct 2013 22:12:02 +1000,
> Nick Coghlan 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
Le Tue, 8 Oct 2013 22:12:02 +1000,
Nick Coghlan 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 than categorica
On 8 Oct 2013 18:36, "Antoine Pitrou" wrote:
>
> Le Tue, 8 Oct 2013 08:21:43 +0200,
> Antoine Pitrou 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 lik
Le Tue, 8 Oct 2013 08:21:43 +0200,
Antoine Pitrou 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 store
On Tue, 8 Oct 2013 08:31:46 +1000
Nick Coghlan 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 a
> while.
"t
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 adaptat
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 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)
d.fr
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:
> > tr
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 8 Oct 2013 07:26, "Steven D'Aprano" 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" function.)
>
>
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 Tra
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 wrote:
> In article ,
> Raymond Hettinger
In article ,
Raymond Hettinger wrote:
> On Sep 22, 2013, at 6:16 PM, Ethan Furman 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 substitu
06.10.13 00:08, Victor Stinner написав(ла):
2013/10/4 Raymond Hettinger >:
> 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 real problems
> being solved by real us
2013/10/4 Raymond Hettinger >:
> Please do conduct your own API tests and report back.
I don't understand why there is a need to evaluate a "new" API:
TransformDict has the same API than dict. The only differences are that the
constructor takes an extra mandatory parameter and there is a new getit
On Oct 4, 2013, at 2:14 PM, Antoine Pitrou 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 right. Students do
On Oct 4, 2013, at 2:06 PM, Victor Stinner 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 constructed from scratch and pro
Good evening,
On Fri, 4 Oct 2013 13:38:05 -0700
Raymond Hettinger 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 who actually
have a nee
2013/10/4 Raymond Hettinger :
> * 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 knew about
> all the var
On Sep 22, 2013, at 6:16 PM, Ethan Furman 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 insensitive diction
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 http://www.python.org/dev/peps
On 16 September 2013 00:45, Serhiy Storchaka 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 a diff
On Sun, 15 Sep 2013 17:45:00 +0300
Serhiy Storchaka 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
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 16:14:24 +0300
Serhiy Storchaka wrote:
> 15.09.13 14:23, Antoine Pitrou написав(ла):
> > On Sun, 15 Sep 2013 13:56:26 +0900
> > Larry Hastings wrote:
> >> On 09/14/2013 07:30 PM, Antoine Pitrou wrote:
> >>> On Sat, 14 Sep 2013 14:33:56 +0900
> >>> Larry Hastings wrote:
>
15.09.13 14:23, Antoine Pitrou написав(ла):
On Sun, 15 Sep 2013 13:56:26 +0900
Larry Hastings wrote:
On 09/14/2013 07:30 PM, Antoine Pitrou wrote:
On Sat, 14 Sep 2013 14:33:56 +0900
Larry Hastings wrote:
Whenever I read a discussion about the dict, I always wonder whether the
same thing appl
On Sun, 15 Sep 2013 13:56:26 +0900
Larry Hastings wrote:
> On 09/14/2013 07:30 PM, Antoine Pitrou wrote:
> > On Sat, 14 Sep 2013 14:33:56 +0900
> > Larry Hastings wrote:
> >> Whenever I read a discussion about the dict, I always wonder whether the
> >> same thing applies to a set. Have you consi
On 09/14/2013 07:30 PM, Antoine Pitrou wrote:
On Sat, 14 Sep 2013 14:33:56 +0900
Larry Hastings 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?
Well, a TransformSet
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 wrote:
14.09.13 20:41, Antoine Pitrou написав(ла):
No good reason. What's the name? transform_func?
transform_func looks... truncated. Why not tran
15.09.13 00:58, Antoine Pitrou написав(ла):
On Sun, 15 Sep 2013 00:55:35 +0300
Serhiy Storchaka 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 common
On 14/09/13 23:31, Eli Bendersky wrote:
On Sat, Sep 14, 2013 at 2:55 PM, Serhiy Storchaka 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. Why not transform_fu
On Sat, Sep 14, 2013 at 2:55 PM, Serhiy Storchaka 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?
transform_λ
_
On Sun, 15 Sep 2013 00:55:35 +0300
Serhiy Storchaka 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 "function". F
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
https://mail.python.org/mailma
On Sat, 14 Sep 2013 12:31:36 -0700
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 http
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 http://www.python.org/dev/peps/pep-0455/, too.
>
Thanks, Antoine!
Raymond
On Sat, 14 Sep 2013 22:07:50 +0300
Serhiy Storchaka wrote:
> 14.09.13 20:41, Antoine Pitrou написав(ла):
> > 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. Wha
14.09.13 20:41, Antoine Pitrou написав(ла):
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?
There is one reason -- serialization. For example p
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 trans
On Sat, 14 Sep 2013 09:43:13 -0700
Ethan Furman wrote:
> On 09/14/2013 03:27 AM, Antoine Pitrou wrote:
> > On Fri, 13 Sep 2013 21:59:11 -0700
> > Ethan Furman wrote:
> >>
> >>> I mean - given no function to retrieve the canonical key,
> >>> one would have to resort to:
> >>>
> >>> my_key = data._
On 09/14/2013 03:27 AM, Antoine Pitrou wrote:
On Fri, 13 Sep 2013 21:59:11 -0700
Ethan Furman 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)
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 14 September 2013 12:44, Steven D'Aprano 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 was for (mean
On 14 September 2013 12:44, Steven D'Aprano 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 was for (mean
On Sat, 14 Sep 2013 14:33:56 +0900
Larry Hastings 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 at http:
On Fri, 13 Sep 2013 21:59:11 -0700
Ethan Furman 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 09/13/2013 09:53 PM, Joao S. O. Bueno wrote:
On 13 September 2013 22: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
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!
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 abou
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.
G
On 09/13/2013 10:09 PM, R. David Murray wrote:
> On Fri, 13 Sep 2013 20:40:58 +0200, Antoine Pitrou
> 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 ma
On 09/13/2013 11:45 PM, Antoine Pitrou wrote:
> On Fri, 13 Sep 2013 23:18:39 +0300
> Serhiy Storchaka wrote:
>> 13.09.13 23:02, Antoine Pitrou написав(ла):
>> > On Fri, 13 Sep 2013 16:54:01 -0300
>> > "Joao S. O. Bueno" wrote:
>> >> I see the PEP does not contemplate a way to retrieve the origina
On 13 September 2013 22: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
>>> lik
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 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 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
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
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 approp
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:
d
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 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, if
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 l
On Fri, 13 Sep 2013 15:32:55 -0700
Ethan Furman 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
> >> specialized
On Sat, 14 Sep 2013 10:49:52 +1000
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:
> key =
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 "", line 1, in
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 = TransformDict(st
On Fri, 13 Sep 2013 23:18:39 +0300
Serhiy Storchaka wrote:
> 13.09.13 23:02, Antoine Pitrou написав(ла):
> > On Fri, 13 Sep 2013 16:54:01 -0300
> > "Joao S. O. Bueno" wrote:
> >> I see the PEP does not contemplate a way to retrieve the original key
> >> - like we've talked about somewhere along t
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, A
On Sat, 14 Sep 2013 00:05:27 +0300
Serhiy Storchaka wrote:
> 13.09.13 23:21, Antoine Pitrou написав(ла):
> > On Fri, 13 Sep 2013 23:16:10 +0300
> > Serhiy Storchaka wrote:
> >> 13.09.13 21:40, Antoine Pitrou написав(ла):
> >>> Alternative proposals and questions
> >>>
13.09.13 23:21, Antoine Pitrou написав(ла):
On Fri, 13 Sep 2013 23:16:10 +0300
Serhiy Storchaka wrote:
13.09.13 21:40, Antoine Pitrou написав(ла):
Alternative proposals and questions
===
Yet one alternative proposal is to add the dict.__transform__() method.
A
On Fri, 13 Sep 2013 20:40:58 +0200, Antoine Pitrou 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 retains the
>
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.
_
13.09.13 23:02, Antoine Pitrou написав(ла):
On Fri, 13 Sep 2013 16:54:01 -0300
"Joao S. O. Bueno" 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 v
On Fri, 13 Sep 2013 23:16:10 +0300
Serhiy Storchaka 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 contradict Tran
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 interfac
On Fri, 13 Sep 2013 16:09:10 -0400
"R. David Murray" wrote:
> On Fri, 13 Sep 2013 20:40:58 +0200, Antoine Pitrou
> wrote:
> > Rationale
> > =
> >
> > Numerous specialized versions of this pattern exist. The most common
> > is a case-insensitive case-preserving dict, i.e. a dict-like co
On Fri, 13 Sep 2013 16:54:01 -0300
"Joao S. O. Bueno" 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 MutableMapping API, to make
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 wrote:
> On Fri, 13 Sep 2013 22:31:02 +0300
> Serhiy Storchaka wrote:
>> 13.09.13 21:40, Antoine Pitrou написав(ла):
>> > Both ar
1 - 100 of 104 matches
Mail list logo
