On Fri, Sep 13, 2013 at 04:26:06AM +, Steve Dower wrote:
> Last I checked, looking up in the instance dict us exactly what it
> does. Even the example you posted is doing that.
The example from the PEP shows:
return cls.__dict__[name]
not "self.__dict__[name]". It is true that "the ins
Last I checked, looking up in the instance dict us exactly what it does. Even
the example you posted is doing that. And the only difference from
__getattribute__ is that it throws instead of following the MRO, which is
intended to allow base classes (via super, and another call to this method) t
On Fri, Sep 13, 2013 at 03:04:49AM +, Steve Dower wrote:
> What about __getlocalattribute__ or __getattributenorecurse__? Long,
> but this isn't going to be used often.
This has nothing to do with locals, nor does it have anything to do with
recursion, so both those names are misleading.
What about __getlocalattribute__ or __getattributenorecurse__? Long, but this
isn't going to be used often.
Putting "type" or "class" in the name would be misleading. It's an instance
method (that is most useful when implemented on a metaclass).
(Apologies for the top post.)
Sent from my Windo
> On 12 sep. 2013, at 17:30, "R. David Murray" wrote:
>
>> On Thu, 12 Sep 2013 16:42:39 +0200, Ronald Oussoren
>> wrote:
>>
>>> On 9 Sep, 2013, at 20:23, Jan Kaliszewski wrote:
>>>
>>> Is '__locallookup__' a really good name? In Python, *local* --
>>> especially in context of *lookups* --
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 Thu, Sep 12, 2013 at 04:42:39PM +0200, Ronald Oussoren wrote:
> I don't particularly like __locallookup__ either, but haven't found a
> better name yet. "__lookup_in_class__" was the best alternative I
> could come up with, and that feels different than other special
> methods. The name in
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 9 Sep, 2013, at 23:18, Mark Shannon wrote:
> On 09/09/13 15:30, Ethan Furman wrote:
>> On 07/30/2013 11:17 PM, Ronald Oussoren wrote:
>>>
>>> And something I forgot to ask: is anyone willing to be the
>>> BDFL-Delegate for
>>> PEP 447?
>>
>> *Bump*.
>>
>> It would be nice if this could mak
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
In issues 7238 [1], 16482 [2], 17697 [3] and 17277 [4], the line
number may be incorrect when the global trace function has been
removed but not the frame f_trace function.
A simple test (see below) in issue 17288 [5] crashes the interpreter
when setting f_lineno in a generator from a return trace
On Thu, 12 Sep 2013 16:42:39 +0200, Ronald Oussoren
wrote:
>
> On 9 Sep, 2013, at 20:23, Jan Kaliszewski wrote:
>
> > Is '__locallookup__' a really good name? In Python, *local* --
> > especially in context of *lookups* -- usually associates with
> > locals() i.e. a namespace of a function/met
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
On 9 Sep, 2013, at 17:43, Mark Shannon wrote:
> I would like time to investigate this further, but at the moment I think it
> will either make attribute lookup poorly defined or slow.
>
> Of the top of my head, the problem as a I see it is basically this:
> Currently, type.__getattribute__() i
On 9 Sep, 2013, at 20:23, Jan Kaliszewski wrote:
> Is '__locallookup__' a really good name? In Python, *local* -- especially in
> context of *lookups* -- usually associates with locals() i.e. a namespace of
> a function/method execution frame or a namespace of a class, during
> *definition* o
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
21 matches
Mail list logo
