[Python-Dev] Problem with super() usage
For about the third time in my life, I thought I might have found a use for cooperative super calls, but I've run into another problem with the concept. Consider: class A(object): def m(self): print "A.m" class B(object): def m(self): print "B.m" super(B, self).m() class C(B, A): def m(self): print "C.m" super(C, self).m() >>> c = C() >>> c.m() C.m B.m A.m Okay so far, but... what if I want to use class B on its own, or in combination with other classes that don't have an m() method? >>> b = B() >>> b.m() B.m Traceback (most recent call last): File "", line 1, in ? File "", line 4, in m AttributeError: 'super' object has no attribute 'm' In general, how is one supposed to use super() in a class which may or may not be at the end of the mro with respect to a particular method? The only thing I can think of is to write all my super()-using methods defensively like this: def m(self): ... s = super(C, self) if hasattr(s, 'm'): s.m() which seems awfully tedious. Does the Theory of Cooperative Method Calls have anything to say about this? -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Capabilities / Restricted Execution
Talin wrote: > Scott Dial wrote: >> Phillip J. Eby wrote: >> >>> A function's func_closure contains cell objects that hold the >>> variables. These are readable if you can set the func_closure of some >>> function of your own. If the overall plan includes the ability to restrict >>> func_closure setting (or reading) in a restricted interpreter, then you >>> might be okay. >> >> Except this function (__getattribute__) has been trapped inside of a >> class which does not expose it as an attribute. So, you shouldn't be >> able to get to the func_closure attribute of the __getattribute__ >> function for an instance of the Guard class. I can't come up with a way >> to defeat this protection, at least. If you have a way, then I'd be >> interested to hear it. > > I've thought of several ways to break it already. Some are repairable, > I'm not sure that they all are. > > For example, neither of the following statements blows up: > > print t2.get_name.func_closure[0] > print object.__getattribute__( t2, '__dict__' ) > > Still, its perhaps a useful basis for experimentation. > > -- Talin I quickly poked around it in python and realized that in 2.5 (as opposed to the 2.4 python I was playing in) the cell object exposes cell_contents.. blargh. So, yes, you can defeat the protection because the wrapped instance is exposed. print t2.get_name() t2.get_name.func_closure[0].cell_contents.im_self.name = 'poop' print t2.get_name() Although, your second example with using the object.__getattribute__ doesn't seem to really be an issue. You retrieved the __dict__ for the Guard class which is empty and is something we should not feel concerned about being leaked. Only way I see this as viable is if in "restricted" mode cell_contents was removed from cell objects. -- Scott Dial [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Capabilities / Restricted Execution
On Jul 16, 2006, at 5:42 AM, Scott Dial wrote:
> Talin wrote:
>> Scott Dial wrote:
>>> Phillip J. Eby wrote:
>>>
A function's func_closure contains cell objects that hold the
variables. These are readable if you can set the func_closure
of some
function of your own. If the overall plan includes the ability
to restrict
func_closure setting (or reading) in a restricted interpreter,
then you
might be okay.
>>>
>>> Except this function (__getattribute__) has been trapped inside of a
>>> class which does not expose it as an attribute. So, you shouldn't be
>>> able to get to the func_closure attribute of the __getattribute__
>>> function for an instance of the Guard class. I can't come up with
>>> a way
>>> to defeat this protection, at least. If you have a way, then I'd be
>>> interested to hear it.
>>
>> I've thought of several ways to break it already. Some are
>> repairable,
>> I'm not sure that they all are.
>>
>> For example, neither of the following statements blows up:
>>
>> print t2.get_name.func_closure[0]
>> print object.__getattribute__( t2, '__dict__' )
>>
>> Still, its perhaps a useful basis for experimentation.
>>
>> -- Talin
>
> I quickly poked around it in python and realized that in 2.5 (as
> opposed
> to the 2.4 python I was playing in) the cell object exposes
> cell_contents.. blargh. So, yes, you can defeat the protection because
> the wrapped instance is exposed.
>
> print t2.get_name()
> t2.get_name.func_closure[0].cell_contents.im_self.name = 'poop'
> print t2.get_name()
>
> Although, your second example with using the object.__getattribute__
> doesn't seem to really be an issue. You retrieved the __dict__ for the
> Guard class which is empty and is something we should not feel
> concerned
> about being leaked.
>
> Only way I see this as viable is if in "restricted" mode cell_contents
> was removed from cell objects.
Similarly to how function attributes aren't accessible in restricted
mode. In older versions of python, it's always been possible to get
the closure variables in non-restricted mode, via mutating func_code...
def get_closure_contents(fun):
num = len(fun.func_closure)
vars = ["x%d" % n for n in range(num)]
defines = ' = '.join(vars) + " = None"
returns = ', '.join(vars)+','
exec """
def b():
%s
def bb():
return %s
return bb
""" % (defines, returns)
old_code = fun.func_code
fun.func_code = b().func_code
result = fun()
fun.func_code = old_code
return dict(zip(old_code.co_freevars, result))
def make_secret(x,y):
def g():
return x*y
return g
>>> secret = f(5,7)
>>> secret()
35
>>> get_closure_contents(secret)
{'y': 7, 'x': 5}
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Pronouncement on SF #1520294 sought
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just as 2.5b2 was being release, I updated SF patch #1520294: https://sourceforge.net/tracker/index.php? func=detail&aid=1520294&group_id=5470&atid=305470 This fixes the pydoc, inspect, and types modules for built-in types like getset and member descriptors. I'm not sure if Georg has had a chance to look over the latest rev of the patch (which is currently assigned to him). I'm basically just looking for an RM pronouncement one way or the other. Can this be added to 2.5 or does it have to wait for 2.6? Thanks! - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRLq7SnEjvBPtnXfVAQLCDAP/UWVSiX9zTnG4qMZJaHHbJDFqxZZnURkx m7OXiCo0H9u4+mY59+FJRos1QA+CldEQ815n+AdxfJQFl0pQqOLaFrTBQtRTzbRU wLV06bUT0OZLOW6mrLxCGNVjAZeua4bcNJBBet8uwj9tx+dftbUnQR921bDjrz9V ZFUjUVXVirs= =7utP -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] I have submitted a patch that implement IrDA socket support .
I have uploaded it at https://sourceforge.net/tracker/download.php?group_id=5470&atid=305470&file_id=184896&aid=1522400. socketmodule.c already have a bluetooth socket, so i think we could put irda socket support in it. Now I can run a simple obex session through IrDA socket layer. my reference include: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnirda/html/irdawp.asp ftp://ftp.ravioli.pasta.cs.uit. no/pub/Ravioli/pyobex/patch-py152-irda3 Will anyone have interest in the patch? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dynamic module namspaces
On Jul 15, 2006, at 2:38 PM, Johan Dahlin wrote: > What I want to ask, is it possible to have a sanctioned way to > implement > a dynamic module/namespace in python? > > For instance, it could be implemented to allow you to replace the > __dict__ attribute in a module with a user provided object which > implements the dictionary protocol. I'd like this, as well, although my use case is different: I'd like to be able to deprecate attributes in a module. That is, if I have: foo.py: SOME_CONSTANT = 5 I'd like to be able to do something such that any time anyone accessed foo.SOME_CONSTANT, it'd emit a DeprecationWarning. James ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dynamic module namspaces
On Sat, Jul 15, 2006 at 03:38:04PM -0300, Johan Dahlin wrote: > In an effort to reduce the memory usage used by GTK+ applications > written in python I've recently added a feature that allows attributes > to be lazy loaded in a module namespace. The gtk python module contains > quite a few attributes (around 850) of which many are classes or > interfaces (150+) Have you seen the "demandload" hack that Mercurial uses? You can find it here: http://selenic.com/repo/hg?f=cb4715847a81;file=mercurial/demandload.py You can see an example use of it here: http://selenic.com/repo/hg?f=d276571f2c4b;file=mercurial/commands.py The advantage for an interactive command line tool isn't so much memory consumption as speed. Why waste hundreds of milliseconds importing code that isn't used? There's an experimental branch to use the same demandload code in bzr, the reported results are "400ms for 'bzr rocks' down to 100ms, 'bzr root' from 400ms => 200ms, etc." (according to http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/13967) Over half the runtime wasted on importing unused code! There's a definite need for a nice solution to this, and it should be included in the standard batteries that come with Python. If we can address related problems at the same time, like emitting deprecation warnings for accessing certain module attributes, then even better! -Andrew. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dynamic module namspaces
Andrew Bennetts <[EMAIL PROTECTED]> wrote: > On Sat, Jul 15, 2006 at 03:38:04PM -0300, Johan Dahlin wrote: > > In an effort to reduce the memory usage used by GTK+ applications > > written in python I've recently added a feature that allows attributes > > to be lazy loaded in a module namespace. The gtk python module contains > > quite a few attributes (around 850) of which many are classes or > > interfaces (150+) > > Have you seen the "demandload" hack that Mercurial uses? You can find it > here: > http://selenic.com/repo/hg?f=cb4715847a81;file=mercurial/demandload.py > > You can see an example use of it here: > http://selenic.com/repo/hg?f=d276571f2c4b;file=mercurial/commands.py The problem with that particular method is that it requires that you use a string to describe the set of modules you would like to import, rather than a name. In the py3k mailing list I recently described a mechanism (though not implementation) for a somewhat related method to support automatic reloading when a file has changed (for things like web frameworks), but by removing that file change check, you get the equivalent to what you describe, though you don't need to use strings, you can use names... from dynamicreload import DR and used like... DR.os.path.join(...) As long as you use the DR.-prefixed name, you get automatic reloading (if desired) on access. > The advantage for an interactive command line tool isn't so much memory > consumption as speed. Why waste hundreds of milliseconds importing code that > isn't used? There's an experimental branch to use the same demandload code in > bzr, the reported results are "400ms for 'bzr rocks' down to 100ms, 'bzr root' > from 400ms => 200ms, etc." (according to > http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/13967) > > Over half the runtime wasted on importing unused code! There's a definite > need > for a nice solution to this, and it should be included in the standard > batteries that come with Python. Well, just starting up Python without loading any modules can be time consuming; perhaps even dwarfing the few hundred ms saved by dynamic loading. > If we can address related problems at the same time, like emitting deprecation > warnings for accessing certain module attributes, then even better! __deprecated__ = ['name1', ...] Make your dynamic load/reload aware of the __deprecated__ attribute, and you are done. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
