Re: [Python-Dev] Return error codes from getaddrinfo.
[Alan] >>I want jython to use the same errno symbolic constants as cpython, to >>ease portability of code. [Martin] > That will be very difficult to achieve, as Python is (deliberately) > not even consistent across systems. Instead, it reports what the > platform reports, so you should do the same in Java. I think I need to explain myself more clearly; I'm looking for the errno.SYMBOLIC_CONSTANT for errors returned by the getaddrinfo function. Take the following lines from the cpython 2.5 httplib. Line 998 - 1014 # -=-=-=-=-=-= while True: try: buf = self._ssl.read(self._bufsize) except socket.sslerror, err: if (err[0] == socket.SSL_ERROR_WANT_READ or err[0] == socket.SSL_ERROR_WANT_WRITE): continue if (err[0] == socket.SSL_ERROR_ZERO_RETURN or err[0] == socket.SSL_ERROR_EOF): break raise except socket.error, err: if err[0] == errno.EINTR: continue if err[0] == errno.EBADF: # XXX socket was closed? break raise # -=-=-=-=-=-=-= How can that code work on jython, other than if A: The jython errno module contains definitions for EINTR and EBADF B: The socket module raises the exceptions with the correct errno.SYMBOLIC_CONSTANTS, in the same circumstances as the cpython module. (The actual integers don't matter, but thanks anyway to the three separate people who informed me that googling "11001" was the solution to my problem). And then there are the non-portable uses of error numbers, like this snippet from the 2.5 httplib: Lines 706-711 #-=-=-=-=-=-= try: self.sock.sendall(str) except socket.error, v: if v[0] == 32: # Broken pipe self.close() raise #-=-=-=-=-=-= Do these examples make it clearer why and in what way I want the jython errno symbolic constants to be the same as cpython? Thanks, Alan. ___ 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] Decoding libpython frame information on the stack
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:) 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 forward for your reply. Thanks and regards, Mithun Bollywood, fun, friendship, sports and more... you name it, we have it at http://in.groups.yahoo.com ___ 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] object capability; func_closure; __subclasses__
> 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 + checker mechanism, it ends up in a system which is quite performance intensive. All those proxies being wrapped/unwrapped/checked... In contrast, the mechanism I am looking at here simply requires *moving* just 2 attributes *out* of the core builtins... Quite cheap, simple and effective, no? > Well, you're missing a simpler approach to protecting functions, > anyway. The '__call__' attribute of functions is still callable, but > doesn't provide any access to func_closure, func_code, etc. I > believe this trick also works for bound method objects. Whilst that would have been a nice trick, what about __call__.__self__ ? Or, setting __call__.__doc__ ? > I suspect that you could also use ctypes to remove or alter the > type.__subclasses__ member, though I suppose you might not consider > that to be "pure" Python any more. However, if you use a definition > of pure that allows for stdlib modules, then perhaps it works. :) Ah, thanks! Will look into that. > I wouldn't object (no pun intended) to moving the type.__subclasses__ > method to say, the 'new' or 'gc' modules, since you wouldn't want to > make those available to restricted code, but then they'd still be > available for folks who need/want them. 'gc' has similar > capabilities (again no pun intended) anyway. Ah, that's a great idea! > However, ISTM that this should be a 3.0 change rather than a 2.x one, > even so. With regard to the func_closure thing, I'd actually like to > make it *writable* as well as readable, and I don't mean just to > change the contents of the cells. But, since you can use .__call__ > to make a capability without access to func_closure, it doesn't seem > like you really need to remove func_closure. I don't object to making func_closure writable either. In fact, as someone who has been following your work on generic functions from way before RuleDispatch, I really want to see PEP 3124 in 3.0 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? -- love, tav founder and ceo, esp metanational llp plex:espians/tav | [EMAIL PROTECTED] | +44 (0) 7809 569 369 ___ 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] Decoding libpython frame information on the stack
Hi Mithun, Because python-dev is a mailing list for the development *of* Python rather than development *with* Python, I believe you may not have posted to the best list. Further information about this distinction, and some discussion about potentially setting up a special-interest list exclusively for Python/C interactions, can be found in this recent thread: http://mail.python.org/pipermail/python-dev/2007-June/073680.html Regarding your question, I'll try to answer it as best I can: on our Windows application, we use Microsoft minidumps [1] instead of core dumps. At the time that a crash occurs and a minidump is written, we have some code that digs into the Python interpreter state to get a text traceback for every Python thread currently in execution at the time of the crash, which is appended to the log file that is sent with the minidump in the automated bug report. Doing this is a bit risky because it assumes that the relevant parts of the Python interpreter state aren't corrupt at the time of the crash, but precautions can be made to deal with this edge case. So while I can't help you get a bead on debugging core files, you may want to consider a similar solution on the Unix platform. - Atul [1] http://msdn2.microsoft.com/en-us/library/ms680369.aspx On 6/28/07, Mithun R N <[EMAIL PROTECTED]> wrote: > 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:) 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 forward for your reply. > Thanks and regards, > Mithun > > > > Bollywood, fun, friendship, sports and more... you name it, we have it > at http://in.groups.yahoo.com > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/varmaa%40gmail.com > ___ 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] Decoding libpython frame information on the stack
On Thu, Jun 28, 2007 at 09:41:06AM +0100, Mithun R N wrote: > 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:) 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. Dave Beazley once worked on this subject: http://www.usenix.org/events/usenix01/full_papers/beazley/beazley_html/index.html Dustin ___ 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] object capability; func_closure; __subclasses__
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 + checker >mechanism, it ends up in a system which is quite performance >intensive. All those proxies being wrapped/unwrapped/checked... > >In contrast, the mechanism I am looking at here simply requires >*moving* just 2 attributes *out* of the core builtins... > >Quite cheap, simple and effective, no? > >>Well, you're missing a simpler approach to protecting functions, >>anyway. The '__call__' attribute of functions is still callable, but >>doesn't provide any access to func_closure, func_code, etc. I >>believe this trick also works for bound method objects. > >Whilst that would have been a nice trick, what about __call__.__self__ ? Well, there's no __self__ in 2.3 or 2.4; I guess that was added in 2.5. Darn. >Or, setting __call__.__doc__ ? What does that do? >>I suspect that you could also use ctypes to remove or alter the >>type.__subclasses__ member, though I suppose you might not consider >>that to be "pure" Python any more. However, if you use a definition >>of pure that allows for stdlib modules, then perhaps it works. :) > >Ah, thanks! Will look into that. If it works, you could probably do the same thing to remove __call__.__self__. >I don't object to making func_closure writable either. In fact, as >someone who has been following your work on generic functions from way >before RuleDispatch, I really want to see PEP 3124 in 3.0 > >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? In 3.0, I don't mind if the access method moves, I just want to keep the access. OTOH, I don't really care about __call__.__self__, since I got along fine without it in 2.3/2.4 and didn't know it had been added in 2.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
Re: [Python-Dev] object capability; func_closure; __subclasses__
> 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 too... > In 3.0, I don't mind if the access method moves, I just want to keep > the access. OTOH, I don't really care about __call__.__self__, since > I got along fine without it in 2.3/2.4 and didn't know it had been > added in 2.5. :) w00p! so, suggestions as to how one can go about getting those 2 access methods moved? -- thanks, tav founder and ceo, esp metanational llp plex:espians/tav | [EMAIL PROTECTED] | +44 (0) 7809 569 369 ___ 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] object capability; func_closure; __subclasses__
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 too... > > > In 3.0, I don't mind if the access method moves, I just want to keep > > the access. OTOH, I don't really care about __call__.__self__, since > > I got along fine without it in 2.3/2.4 and didn't know it had been > > added in 2.5. :) > >w00p! > >so, suggestions as to how one can go about getting those 2 access >methods moved? Post a proposal on the Python-3000 list and supply patches to do the moves. ___ 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] Decoding libpython frame information on the stack
>> 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:) 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. Sorry, I missed this the first time round and just saw Dustin's reply. The Python distribution comes with a gdbinit file in the Misc directory. I use it frequently to display Python stack traces from within GDB. Here's the most recent copy online: http://svn.python.org/view/python/trunk/Misc/gdbinit?view=markup The following commands are implemented: pystack - display the full stack trace pystackv - as above, but also display local variables pyframe - display just the current frame pyframev - as above, but also display local variables up, down - move up or down one C stack frame, but display Python frame if you move into PyEval_EvalFrame This should all work within active sessions and sessions debugging core files (e.g., no active process). It needs some rework. For instance, it assumes you're running within Emacs and puts out lines gud can use to display source lines. These look a little funky when debugging from a terminal window. Skip ___ 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] object capability; func_closure; __subclasses__
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 = pythonapi._PyObject_GetDictPtr getdict.restype = POINTER(py_object) getdict.argtypes = [py_object] def dictionary_of(ob): dptr = getdict(ob) if dptr and dptr.contents: return dptr.contents.value 'dictionary_of' returns either a dictionary object, or None if the object has no dictionary. You can then simply delete any unwanted contents. However, you should *never use this* to assign __special__ methods, as Python will not change the type slots correctly. Heck, you should probably never use this, period. :) Usage example: print "before", type.__subclasses__ del dictionary_of(type)['__subclasses__'] print "after", type.__subclasses__ This will print something like: before after Traceback (most recent call last): File "ctypes_dicto.py", line 14, in print "after", type.__subclasses__ AttributeError: type object 'type' has no attribute '__subclasses__' et voila. You should also be able to delete unwanted function type attributes like this:: from types import FunctionType del dictionary_of(FunctionType)['func_closure'] del dictionary_of(FunctionType)['func_code'] Of course, don't blame me if any of this code fries your computer and gives you a disease, doesn't work with new versions of Python, etc. etc. It works for me on Windows and Linux with Python 2.3, 2.4 and 2.5. It may also work with 3.0, but remember that func_* attributes have different names there. ___ 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] object capability; func_closure; __subclasses__
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 not going to be allowed access to new in the first place. We're talking about removing read access to the closure *attribute* only. (And write access to func_code would also have to be removed, else you could replace the bytecode in order to grant yourself read access to the closure contents...) >If so, would I be expected to create a function >object and then use the "new" module to supply its func_closure? Nope. The idea here is that the new module would grow utility functions like get_closure, get_code, set_code, get_subclasses, etc. The 'inspect' module would then use these functions to do its job, and I would use them for generic function stuff. ___ 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] Return error codes from getaddrinfo.
> [Martin] >> That will be very difficult to achieve, as Python is (deliberately) >> not even consistent across systems. Instead, it reports what the >> platform reports, so you should do the same in Java. > > Do these examples make it clearer why and in what way I want the jython > errno symbolic constants to be the same as cpython? I fully understood that, already in your original message. All I was saying is that this will be very difficult to achieve. It would be much easier if you don't take the code of the standard library and the application as given, but instead accept that people may have to change the error conditions somewhat when porting to Jython. Ideally, such porting would allow to still run the same code on CPython, and ideally, you would then provide patches for the Python library to make it run unmodified on Jython (rather than trying to arrange to make the *current* library run unmodified). Regards, Martin ___ 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] object capability; func_closure; __subclasses__
I love you PJE! Thank you! =) On 6/28/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > 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 = pythonapi._PyObject_GetDictPtr > getdict.restype = POINTER(py_object) > getdict.argtypes = [py_object] > > def dictionary_of(ob): > dptr = getdict(ob) > if dptr and dptr.contents: > return dptr.contents.value > > 'dictionary_of' returns either a dictionary object, or None if the > object has no dictionary. You can then simply delete any unwanted > contents. However, you should *never use this* to assign __special__ > methods, as Python will not change the type slots correctly. Heck, > you should probably never use this, period. :) Usage example: > >print "before", type.__subclasses__ >del dictionary_of(type)['__subclasses__'] >print "after", type.__subclasses__ > > This will print something like: > >before >after >Traceback (most recent call last): > File "ctypes_dicto.py", line 14, in >print "after", type.__subclasses__ >AttributeError: type object 'type' has no attribute '__subclasses__' > > et voila. > > You should also be able to delete unwanted function type attributes like > this:: > >from types import FunctionType >del dictionary_of(FunctionType)['func_closure'] >del dictionary_of(FunctionType)['func_code'] > > Of course, don't blame me if any of this code fries your computer and > gives you a disease, doesn't work with new versions of Python, etc. > etc. It works for me on Windows and Linux with Python 2.3, 2.4 and > 2.5. It may also work with 3.0, but remember that func_* attributes > have different names there. > > -- love, tav founder and ceo, esp metanational llp plex:espians/tav | [EMAIL PROTECTED] | +44 (0) 7809 569 369 ___ 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] object capability; func_closure; __subclasses__
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? If so, would I be expected to create a function object and then use the "new" module to supply its func_closure? Robert Brewer System Architect Amor Ministries [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] object capability; func_closure; __subclasses__
At 01:26 PM 6/28/2007 -0400, Phillip J. Eby wrote: >You should also be able to delete unwanted function type attributes >like this:: > >from types import FunctionType >del dictionary_of(FunctionType)['func_closure'] >del dictionary_of(FunctionType)['func_code'] By the way, you probably want to also delete func_globals and func_defaults, as there are security ramifications to those attributes as well. Probably not so much for func_dict/__dict__ though. And of course, for Python<=2.4 you can just use the __call__ attribute and not bother with deleting anything but __subclasses__. ___ 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] What's going on with the check-in emails?
Thanks! The check-in emails are working again. -- Alexandre On 6/27/07, Thomas Wouters <[EMAIL PROTECTED]> wrote: > > The mail-checkins script broke because of the upgrade of the machine that > hosts the subversion repository -- Python 2.3 went away, but two scripts > were still using '#!/usr/bin/env python2.3'. They should be fixed now. > ___ 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] Decoding libpython frame information on the stack
Hi All, Thanks much for your suggestions and help. Shall get back after reading through and trying some stuff mentioned in the emails. Thanks and regards, Mithun --- [EMAIL PROTECTED] wrote: > > >> 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:) 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. > > Sorry, I missed this the first time round and just > saw Dustin's reply. The > Python distribution comes with a gdbinit file in the > Misc directory. I use > it frequently to display Python stack traces from > within GDB. Here's the > most recent copy online: > > > http://svn.python.org/view/python/trunk/Misc/gdbinit?view=markup > > The following commands are implemented: > > pystack - display the full stack trace > pystackv - as above, but also display local > variables > pyframe - display just the current frame > pyframev - as above, but also display local > variables > up, down - move up or down one C stack frame, > but display Python >frame if you move into > PyEval_EvalFrame > > This should all work within active sessions and > sessions debugging core > files (e.g., no active process). > > It needs some rework. For instance, it assumes > you're running within Emacs > and puts out lines gud can use to display source > lines. These look a little > funky when debugging from a terminal window. > > Skip > Send free SMS to your Friends on Mobile from your Yahoo! Messenger. Download Now! http://messenger.yahoo.com/download.php ___ 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
