[Piglit] [Patch v2 1/3] framework.log: Replace synchronized_self decorator

[Dylan Baker]

On Friday, April 25, 2014 05:23:47 PM Ilia Mirkin wrote:
> On Fri, Apr 25, 2014 at 4:45 PM, Dylan Baker <baker.dylan.c at gmail.com> 
wrote:
> > On Friday, April 25, 2014 16:40:36 Ilia Mirkin wrote:
> >> On Fri, Apr 25, 2014 at 4:38 PM, Dylan Baker <baker.dylan.c at gmail.com>
> >> 
> >> wrote:
> >> > This replaces the synchronized_self decorator from piglit's threads
> >> > 
> >> > module with a context manager (with foo: <stuff>). This is more
> >> > standard
> >> > 
> >> > python, and means having a little less hand rolled code around.
> >> > 
> >> > 
> >> > 
> >> > v2: - fix mixed usage of __lock and _lock
> >> 
> >> There's probably an obvious reason for this, but I'm missing it -- why
> >> 
> >> are you using _lock when all the other vars are hidden with __?
> > 
> > I've been bitten too many times now using __, I'm trying not to use that
> > mechanism unless I can come up with a good reason to.
> > 
> > 
> > 
> > Unless I'm completely misunderstanding python style, a leading _ is the
> > equivalent what ruby calls a protected member: That class and all of it's
> > children have access to that member. In python it's only suggested that
> > method not be called outside of the class. and leading __ is the
> > equivalent
> > of a 'private' method, only that class, and not it's children, can access
> > that member.
> 
> I think that's roughly correct -- if you have a member named __foo, it
> gets auto-renamed to some random string (so, still accessible for the
> very determined, just not under its original name -- I think it's
> hashed with the defining class's name or something along those lines).
> Having _foo being protected is merely a convention -- nothing enforces
> it.
> 
> > Which means I did the wrong thing when I wrote Log. Unless I completely
> > misunderstood?
> 
> Not sure why __ is the wrong thing for log's private members. Or why
> you wouldn't want lock to be considered private.
> 
>   -ilia
> 

The problem is subclassing. In our case __lock would become _Log__lock to a 
class the descends from Log, making it impossible to obtain the same lock 
instance. And that's a problem.

[snip]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/piglit/attachments/20140426/6bd20617/attachment.sig>