Mailman 3 June 2007 - Python-Dev

Decoding libpython frame information on the stack
by Mithun R N June 29, 2007

June 29, 2007

Hi All, Am a new subscriber to this list. Am facing an issue in deciphering core-files of applications with mixed C and libpython frames in it. I was thinking of knowing any work that has been done with respect to getting into the actual python line (file-name.py:<line number>) from the libpython frames on the stack while debugging such core-files. If anybody knows some information on this, please let me know. I could not get any link on the web that talks about this feature. Looking … [View More]

4 4

What's going on with the check-in emails?
by Alexandre Vassalotti June 28, 2007

June 28, 2007

Hi, It seems there is a problem with check-in emails -- i.e., none have been sent since r56057 (and the svn tree is at r56098 right now). Does someone has a hint what's going on? Thanks, -- Alexandre

4 4

Re: [Python-Dev] object capability; func_closure; __subclasses__
by Phillip J. Eby June 28, 2007

June 28, 2007

At 05:23 PM 6/28/2007 +0100, tav wrote: >Any pointers on removing members via ctypes front? > >Whilst I can understand even the most obscure aspects of your python >code fine, I'm not familiar with C/ctypes... What you want is to get access to the type's real dictionary, not the proxy. Then you can just delete '__subclasses__' from the dictionary using Python code. Here's some code that does the trick: from ctypes import pythonapi, POINTER, py_object getdict = … [View More]

2 2

Re: [Python-Dev] object capability; func_closure; __subclasses__
by Phillip J. Eby June 28, 2007

June 28, 2007

At 10:20 AM 6/28/2007 -0700, Robert Brewer wrote: >tav wrote: > > But, all I am asking for is to not expose func_closure (and perhaps > > some of the other func_*) as members of FunctionType -- isn't it > > possible to add functionality to the ``new`` module which would allow > > one to read/write func_closure? > >Would func_closure then also be removed from the FunctionType >constructor arg list? That wouldn't be necessary, since restricted code is probably … [View More]

1 0

Return error codes from getaddrinfo.
by Alan Kennedy June 28, 2007

June 28, 2007

Dear all, I'm seeking enlightenment on the error codes returned by the socket.getaddrinfo() function. Consider the following on python 2.5 on Windows >>> import urllib >>> urllib.urlopen("http://nonexistent") [snip traceback] IOError: [Errno socket error] (11001, 'getaddrinfo failed') So the error number is 11001. But when I try to find a symbolic constant in the errno module corresponding to this error number, I can't find one. >>> import errno >>… [View More]

2 3

Re: [Python-Dev] object capability; func_closure; __subclasses__
by Phillip J. Eby June 28, 2007

June 28, 2007

At 02:04 AM 6/28/2007 +0100, tav wrote: >rehi all, > >I have been looking at the object capability + Python discussions for >a while now, and was wondering what the use cases for >``object.__subclasses__`` and ``FunctionType.func_closure`` were? > >I don't see __subclasses__ used anywhere in the standard library. And >whilst I can see exposing func_closure as being useful in terms of >"cloning/modifying" an existing function, isn't it possible to do that >without … [View More]

3 2

Re: [Python-Dev] object capability; func_closure; __subclasses__
by Phillip J. Eby June 28, 2007

June 28, 2007

At 04:14 PM 6/28/2007 +0100, tav wrote: > > Well, there's no __self__ in 2.3 or 2.4; I guess that was added > in 2.5. Darn. > >anyone know *why* it was added? > > > >Or, setting __call__.__doc__ ? > > > > What does that do? > >ah, i just wanted a way of providing documentation, and __call__'s >__doc__ isn't writable... > > > If it works, you could probably do the same thing to remove > __call__.__self__. > >will look into that … [View More]

1 0

Re: [Python-Dev] object capability; func_closure; __subclasses__
by Phillip J. Eby June 28, 2007

June 28, 2007

At 01:09 PM 6/28/2007 +0100, tav wrote: >>You know, I find it particularly interesting that, as far as I can >>tell, nobody who proposes making changes to the Python language to >>add security, ever seems to offer any comparison or contrast of their >>approaches to Zope's -- which doesn't require any changes to the >>language. :) > >Whilst it is definitely possible to build up a object capability >system with a pruned down version of Zope 3's proxy + … [View More]

2 1

csv changed from python 2.4 to 2.5
by Christian K June 28, 2007

June 28, 2007

Hi, I could not find documentation of the following change in python2.5. What is the reason for that? Python 2.4.4 (#2, Apr 12 2007, 21:03:11) [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import csv >>> d=csv.get_dialect('excel') >>> d.delimiter = ',' >>> ck@kiste:/media/hda6/home/ck/prog/peak-o-mat/trunk$ python2.5 Python 2.5.1 (r251:54863, May 2 2007, 16:56:35) [GCC 4.1.2 (… [View More]

4 4

object capability; func_closure; __subclasses__
by tav June 28, 2007

June 28, 2007

rehi all, I have been looking at the object capability + Python discussions for a while now, and was wondering what the use cases for ``object.__subclasses__`` and ``FunctionType.func_closure`` were? I don't see __subclasses__ used anywhere in the standard library. And whilst I can see exposing func_closure as being useful in terms of "cloning/modifying" an existing function, isn't it possible to do that without making it introspectable? Years ago, Ka-Ping Yee pointed out: http://mail.… [View More]python.org/pipermail/python-dev/2003-March/034284.html Derived from this we get: # capability.py functions def Namespace(*args, **kwargs): for arg in args: kwargs[arg.__name__] = arg def get(key): return kwargs.get(key) return get class Getter(object): def __init__(self, getter): self.getter = getter def __repr__(self): return self.getter('__repr__') or object.__repr__(self) def __getattr__(self, attr): return self.getter(attr) # io.py module def FileReader(name): file = open(name, 'r') def __repr__(): return '<FileReader: %r>' % name def read(bufsize=-1): return file.read(bufsize) def close(): return file.close() return Getter(Namespace(__repr__, read, close)) ---- Now, a process A -- which has full access to all objects -- can do: >>> motd = FileReader('/etc/motd') And pass it to "process B" operating in a limited scope, which can then call: >>> motd.read() >>> motd.close() But not: >>> motd = type(motd)(motd.name, 'w') which would have been possible *had* motd been created as a ``file`` type by calling: ``open('/etc/motd', 'r')``. Now, there are probably a million holes in this approach, but as long as process B's __import__ is sanitised and it operates in a "limited" scope with regards to references to other functionality, this seems to be relatively secure. However, this is where __subclasses__ and func_closure get in the way. With object.__subclasses__ (as Brett points out), all defined classes/types are available -- including the ``file`` type we were trying to deny process B access to! Is it necessary to expose this attribute publically? And, likewise with func_closure, one can do motd.read.func_closure[0].cell_contents and get hold of the original ``file`` object. Is it absolutely necessary to expose func_closure in this way? Now, whilst probably wrong, I can see myself being able to create a minimal object capability system in pure python if those 2 "features" disappeared. Am I missing something obvious that prevents me from doing that? Can we get rid of them for Python 2.6? Or even 2.5.2? Is anyone besides PJE actually using them? ;p Thanks in advance for your thoughts. -- love, tav founder and ceo, esp metanational llp plex:espians/tav | tav(a)espians.com | +44 (0) 7809 569 369 [View Less]

1 0