Re: [Python-Dev] frozenset C API?
On 9/5/07, Bill Janssen [EMAIL PROTECTED] wrote: It's actually easier to do all or nothing. I'm tempted to just report 'critical' extensions. Simpler to provide them all, though I should note that the purpose of the information provided here is mainly for authorization/accounting purposes, not for other use of the certificate. If that's desired, they should pull the binary form of the certificate (there's an interface for that), and use M2Crypto or PyOpenSSL to decode it in general. This certificate has already been validated; the issue is how to get critical information to the app so it can make authorization decisions (like subjectAltName when the subject field is empty). Reporting non-critical extensions like extended key usage is nifty, but seems pointless. RFC 2818 If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead. This is from an explanation of how to do hostname verification when doing HTTPS requests. HTTPS clients MUST do this in order to be compliant. Is an HTTPS client not in your list of use cases? In general, HTTP/TLS requests are generated by dereferencing a URI. As a consequence, the hostname for the server is known to the client. If the hostname is available, the client MUST check it against the server's identity as presented in the server's Certificate message, in order to prevent man-in-the-middle attacks. I really don't understand why you would not expose all data in the certificate. It seems totally obvious. The data is there for a reason. I want the subjectAltName. Probably other people want other stuff. Why cripple it? Please include it all. -- Christopher Armstrong International Man of Twistery http://radix.twistedmatrix.com/ http://twistedmatrix.com/ http://canonical.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] frozenset C API?
On 9/6/07, Martin v. Löwis [EMAIL PROTECTED] wrote: You mean, providing the entire certificate as a blob? That is planned (although perhaps not implemented). Or do you mean expose all data in a structured manner. BECAUSE IT'S NOT POSSIBLE. Sorry for shouting, but people don't ever get the notion of extension. It seems totally obvious. The data is there for a reason. I want the subjectAltName. Probably other people want other stuff. Why cripple it? Please include it all. That's not possible. You can get the whole thing as a blob, and then you have to decode it yourself if something you want is not decoded. Sorry, I guess I thought it was obvious. Please let me get at the bytes of just the unknown-to-ssl-module extension without forcing me to write an entire general ASN.1 certificate parser or use another (incomplete) one. Many extensions have simple data in them that is trivial to parse alone. -- Christopher Armstrong International Man of Twistery http://radix.twistedmatrix.com/ http://twistedmatrix.com/ http://canonical.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of dynamic attribute access discussion
On 2/13/07, Martin v. Löwis [EMAIL PROTECTED] wrote: Anthony Baxter schrieb: and the wrapper class idea of Nick Coghlan: attrview(obj)[foo] This also appeals - partly because it's not magic syntax wink I also like this. Martin and Anthony are correct. We do not need more syntax for such a trivial and trivially-implemented feature. The syntax is no real benefit. -- Christopher Armstrong International Man of Twistery http://radix.twistedmatrix.com/ http://twistedmatrix.com/ http://canonical.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unicode hell/mixing str and unicode as dictionary keys
On 8/4/06, Ralf Schmitt [EMAIL PROTECTED] wrote: Jean-Paul Calderone wrote: I like the exception that 2.5 raises.I only wish it raised by default when using 'ascii' and u'ascii' as keys in the same dictionary. ;)Oh, and that str and unicode did not hash like they do.;) No problem: import sys reload(sys)module 'sys' (built-in) sys.setdefaultencoding(base64) a==ua Traceback (most recent call last):...binascii.Error: Incorrect paddingMaybe this is all just a matter of choosing the right defaultencoding ? :)Doing this is amazingly stupid. I can't believe how often I hear this suggestion. Apparently the fact that you have to reload(sys) to do it isn't warning enough? -- Christopher ArmstrongInternational Man of Twisteryhttp://radix.twistedmatrix.com/http://twistedmatrix.com/ http://canonical.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Community buildbots
On 7/13/06, Giovanni Bajo [EMAIL PROTECTED] wrote: I think python should have a couple more of future imports. from __future__ import new_classes and from __future__ import unicode_literals would be really welcome, and would smooth the Py3k migration process Along similar lines as glyph, after complaining about this for a long time offline with my friends, I decided it's probably a good idea to get involved and vote that the __future__ import for unicode_literals be implemented. python -U is a failure for obvious reasons and a __future__ import is clearly better. Does anyone want to pair on this? -- Christopher Armstrong International Man of Twistery http://radix.twistedmatrix.com/ http://twistedmatrix.com/ http://canonical.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Community buildbots (was Re: User's complaints)
On 7/13/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Thu, 13 Jul 2006 11:29:16 -0700, Aahz [EMAIL PROTECTED] wrote: There's been some recent discussion in the PSF wondering where it would make sense to throw some money to remove grit in the wheels; do you think this is a case where that would help? Most likely yes. It's not a huge undertaking, and there are a lot of people out there in the community with the knowledge of Buildbot to make this happen. I'm at least willing to set up the buildbots for projects I care about (Twisted, pydoctor, whatever), and perhaps help out with the setting up the buildmaster. -- Christopher Armstrong International Man of Twistery http://radix.twistedmatrix.com/ http://twistedmatrix.com/ http://canonical.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] threadsafe patch for asynchat
On 2/8/06, Alex Martelli [EMAIL PROTECTED] wrote: On 2/7/06, Fredrik Lundh [EMAIL PROTECTED] wrote: ... what other reactive socket framework is there that would fit well into the standard library ? is twisted really simple enough ? Twisted is wonderful, powerful, rich, and very large. Perhaps a small subset could be carefully extracted that (given suitable volunteers to maintain it in the future) might fit in the standard library, but [a] that extraction is not going to be a simple or fast job, and [b] I suspect that the minimum sensible subset would still be much larger (and richer / more powerful) than asyncore. The subject of putting (parts of) Twisted into the standard library comes up once every 6 months or so, at least on our mailing list. For all that I think asyncore is worthless, I'm still against copying Twisted into the stdlib. Or at least I'm not willing to maintain the necessary fork, and I fear the nightmares about versioning that can easily occur when you've got both standard library and third party versions of a project. But, for the record, to the people who argue not to put Twisted into the stdlib because of its size: The parts of it that would actually be applicable (i.e. those that obselete async* in the stdlib) are only a few kilobytes of code. At a quick run of wc, the parts that support event loops, accurate timed calls, SSL, Unix sockets, TCP, UDP, arbitrary file descriptors, processes, and threads sums up to about 5300 lines of code. asynchat and asyncore are about 1200. -- Twisted | Christopher Armstrong: International Man of Twistery Radix|-- http://radix.twistedmatrix.com | Release Manager, Twisted Project \\\V/// |-- http://twistedmatrix.com |o O|| wvw-+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
On 2/7/06, Martin v. Löwis [EMAIL PROTECTED] wrote: Brett Cannon wrote: But I know that everyone and their email client is against me on this one, so I am not going to really try to tear into this. But I do think that lambda needs a renaming. Speaking as someone who still forgets that Python's lambda is not the same as those found in functional languages Can you elaborate on that point? I feel that Python's lambda is exactly the same as the one in Lisp. Sure, the Lisp lambda supports multiple sequential expressions (the progn feature), but I understand that this is just an extension (although one that has been around several decades). Of course, Python's expressions are much more limited as Lisp's (where you really can have macros and special forms in as the expression in a lambda), but the lambda construct itself seems to be the very same one. If we phrase it somewhat differently, we can see that lambdas are different in Python and Lisp, in a very practical way. First: Everything in Lisp is an expression. There's no statement, in Lisp, that isn't also an expression. Lambdas in Lisp can contain arbitrary expressions; therefore you can put any language construct inside a lambda. In Python, you cannot put any language construct inside a lambda. Python's and Lisp's lambdas are effectively totally different. +1 on keeping Lambda, +1 on making it more useful. -- Twisted | Christopher Armstrong: International Man of Twistery Radix|-- http://radix.twistedmatrix.com | Release Manager, Twisted Project \\\V/// |-- http://twistedmatrix.com |o O|| wvw-+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Doc-SIG] that library reference, again
On 12/30/05, Robey Pointer [EMAIL PROTECTED] wrote: On 29 Dec 2005, at 18:58, David Goodger wrote: [Fredrik Lundh] I'm beginning to fear that I've wasted my time on a project that nobody's interested in. [David Goodger] Could be. I don't see HTML+PythonDoc as a significant improvement over LaTeX. [Fredrik Lundh] Really? Yes, really. Just out of curiosity (really -- not trying to jump into the flames) why not just use epydoc? If it's good enough for 3rd-party python libraries, isn't that just a small step from being good enough for the builtin libraries? It's not really even good enough for a lot of my usage without some seriously evil hacks. The fundamental design decision of epydoc to import code, plus some other design decisions on the way it figures types and identity seriously hinder its utility. Ever notice how trying to document your third-party-library-using application will *also* document that third party library, for example? Or how it'll blow up when you're trying to document your gtk-using application on a remote server without an X server running? Or how it just plain blows right up with most Interface systems? etc. -- Twisted | Christopher Armstrong: International Man of Twistery Radix|-- http://radix.twistedmatrix.com | Release Manager, Twisted Project \\\V/// |-- http://twistedmatrix.com |o O|| wvw-+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a quit that actually quits
On 12/28/05, Reinhold Birkenfeld [EMAIL PROTECTED] wrote: Fredrik Lundh wrote: sourceforge just went off the air, so I'm posting this patch here, in order to distract you all from Christian's deque thread. this silly little patch changes the behaviour of the interpreter so that quit and exit actually exits the interpreter. it does this by installing a custom excepthook that looks for NameErrors at the top level, in interactive mode only. What is wrong with something like this: class Quitter: ... def __repr__(self): raise SystemExit ... exit = quit = Quitter() It could optionally check for top level too, of course. Not sure if this is what you mean by check for top level too, but the obvious problem is that calling vars(__builtins__) (or similar) will cause your interpreter to exit. :) -- Twisted | Christopher Armstrong: International Man of Twistery Radix|-- http://radix.twistedmatrix.com | Release Manager, Twisted Project \\\V/// |-- http://twistedmatrix.com |o O|| wvw-+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 352 Transition Plan
On 10/29/05, Nick Coghlan [EMAIL PROTECTED] wrote: Another point in PEP 352's favour, is that it makes it far more feasible to implement something like PEP 344 by providing __traceback__ and __prev_exc__ attributes on BaseException. Not sure if I'm fully in-context here, but watch out for __traceback__ and garbage collection, since the traceback objects refer to all the frames. I expect there's a significant amount of code out there that expects Exception instances to be reasonably persistent. At least Twisted does, with its encapsulation of Exceptions for the purposes of asynchrony -- Failure objects. These Failure objects also refer to tracebacks, but we had to be very careful about deleting them fairly quickly because of GC issues. After deletion they simply contain an inert, basically stringified copy of the traceback. On an only semi-related note, at one point I tried making it possible to have longer-lived Traceback objects that could be reraised, but found it very hard to do, at least with my self-imposed requirement of keeping it in an extension module. http://mail.python.org/pipermail/python-dev/2005-September/056091.html -- Twisted | Christopher Armstrong: International Man of Twistery Radix|-- http://radix.twistedmatrix.com | Release Manager, Twisted Project \\\V/// |-- http://twistedmatrix.com |o O|| wvw-+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 351, the freeze protocol
On 10/24/05, Josiah Carlson [EMAIL PROTECTED] wrote:
Should dicts and sets automatically freeze their mutable keys?
Dictionaries don't have mutable keys,
Since when?
class Foo:
def __init__(self):
self.x = 1
f = Foo()
d = {f: 1}
f.x = 2
Maybe you meant something else? I can't think of any way in which
dictionaries don't have mutable keys is true. The only rule about
dictionary keys that I know of is that they need to be hashable and
need to be comparable with the equality operator.
--
Twisted | Christopher Armstrong: International Man of Twistery
Radix|-- http://radix.twistedmatrix.com
| Release Manager, Twisted Project
\\\V/// |-- http://twistedmatrix.com
|o O||
wvw-+
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3000 and exec
On 10/11/05, Guido van Rossum [EMAIL PROTECTED] wrote: My idea was to make the compiler smarter so that it would recognize exec() even if it was just a function. Another idea might be to change the exec() spec so that you are required to pass in a namespace (and you can't use locals() either!). Then the whole point becomes moot. I think that's a great idea. It goes a step towards a more analyzable Python, and really, I've never found a *good* use case for allowing this invisible munging of locals. I would guess that it would simplify the implementation, given that there are currently so many special cases around exec, including when used with nested scopes. -- Twisted | Christopher Armstrong: International Man of Twistery Radix|-- http://radix.twistedmatrix.com | Release Manager, Twisted Project \\\V/// |-- http://twistedmatrix.com |o O|| wvw-+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pythonic concurrency
On 10/11/05, Guido van Rossum [EMAIL PROTECTED] wrote: I recall using a non-preemptive system in the past; in Amoeba, to be precise. Initially it worked great. But as we added more powerful APIs to the library, we started to run into bugs that were just as if you had preemptive scheduling: it wouldn't always be predictable whether a call into the library would need to do I/O or not (it might use some sort of cache) so it would sometimes allow other threads to run and sometimes not. Or a change to the library would change this behavior (making a call that didn't use to block into sometimes-blocking). I'm going to be giving a talk at OSDC (in Melbourne) this year about concurrency systems, and I'm going to talk a lot about the subtleties between these various non-preemptive (let's call them cooperative :) systems. I advocate a system that gives you really straightforward-looking code, but still requires you to annotate the fact that context switches can occur on every frame where they might occur (i.e., with a yield). I've given examples before of my new 2.5-yield + twisted Deferred code here, but to recap it just means that you have to do: def foo(): x = yield getPage() return Yay when you want to download a web page, and the caller of 'foo' would *also* need to do something like yay = yield foo(). I think this is a very worthwhile tradeoff for those obsessed with natural code. -- Twisted | Christopher Armstrong: International Man of Twistery Radix|-- http://radix.twistedmatrix.com | Release Manager, Twisted Project \\\V/// |-- http://twistedmatrix.com |o O|| wvw-+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for 2.5: Returning values from PEP 342 enhanced generators
On 10/4/05, Piet Delport [EMAIL PROTECTED] wrote: One system that could benefit from this change is Christopher Armstrong's defgen.py[1] for Twisted, which he recently reincarnated (as newdefgen.py) to use enhanced generators. The resulting code is much cleaner than before, and closer to the conventional synchronous style of writing. [1] the saga of which is summarized here: http://radix.twistedmatrix.com/archives/000114.html However, because enhanced generators have no way to differentiate their intermediate results from their real result, the current solution is a somewhat confusing compromise: the last value yielded by the generator implicitly becomes the result returned by the call. Thus, to return something, in general, requires the idiom yield Foo; return. If valued returns are allowed, this would become return Foo (and the code implementing defgen itself would probably end up simpler, as well). Hey, that would be nice. I've found people confused by the way defgen handles return values before, getting seemingly meaningless values out of their defgens (if the defgen didn't specifically yield some meaningful value at the end). At first I thought return foo in a generator ought to be equivalent to yield foo; return, but at least for defgen, it turns out raising StopIteration(foo) would be better, as I would have a very explicit way to specify and find the return value of the generator. -- Twisted | Christopher Armstrong: International Man of Twistery Radix|-- http://radix.twistedmatrix.com | Release Manager, Twisted Project \\\V/// |-- http://twistedmatrix.com |o O|| wvw-+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pythonic concurrency - cooperative MT
On 10/3/05, Martin Blais [EMAIL PROTECTED] wrote:
On 10/1/05, Antoine [EMAIL PROTECTED] wrote:
like this with their deferred objects, no? I figure they would
need to do something like this too. I will have to check.)
A Deferred object is just the abstraction of a callback - or, rather, two
callbacks: one for success and one for failure. Twisted is architected
around an event loop, which calls your code back when a registered event
happens (for example when an operation is finished, or when some data
arrives on the wire). Compared to generators, it is a different way of
expressing cooperative multi-threading.
So, the question is, in Twisted, if I want to defer on an operation
that is going to block, say I'm making a call to run a database query
that I'm expecting will take much time, and want to yield (defer)
for other events to be processed while the query is executed, how do I
do that? As far as I remember the Twisted docs I read a long time ago
did not provide a solution for that.
Deferreds don't make blocking code non-blocking; they're just a way to
make it nicer to write non-blocking code. There are utilities in
Twisted for wrapping a blocking function call in a thread and having
the result returned in a Deferred, though (see deferToThread). There
is also a lightweight and complete wrapper for DB-API2 database
modules in twisted.enterprise.adbapi, which does the threading
interaction for you.
So, since this then exposes a non-blocking API, you can do stuff like
d = pool.runQuery('SELECT User_ID FROM Users')
d.addCallback(gotDBData)
d2 = ldapfoo.getUser('bob')
d2.addCallback(gotLDAPData)
And both the database call and the ldap request will be worked on concurrently.
--
Twisted | Christopher Armstrong: International Man of Twistery
Radix|-- http://radix.twistedmatrix.com
| Release Manager, Twisted Project
\\\V/// |-- http://twistedmatrix.com
|o O||
wvw-+
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Active Objects in Python
On 9/28/05, Greg Ewing [EMAIL PROTECTED] wrote:
Nick Coghlan wrote:
PEP 342's yield expressions can probably be used to help address that
problem,
though:
class SomeAO(ActiveObject):
def processSomeMessage(self):
msg = yield
# Do something with the message
next_msg = yield makeSomeBlockingCall(self)
# Do something with the next message
I don't see how that helps, since makeSomeBlockingCall()
is evaluated (and therefore blocks) *before* the yield
happens.
Sounds like makeSomeBlockingCall is just misnamed (probably depending
who you ask).
I wrote a small library recently that wraps Twisted's Deferreds and
asynchronous Failure objects such that you can do stuff like
try:
x = yield remoteObject.getSomething()
except Foo:
print Oh no!
This is just a 2.5-ification of defgen, which is at
twisted.internet.defer.{deferredGenerator,waitForDeferred}. So anyway,
if your actor messages always return Deferreds, then this works quite
nicely.
--
Twisted | Christopher Armstrong: International Man of Twistery
Radix|-- http://radix.twistedmatrix.com
| Release Manager, Twisted Project
\\\V/// |-- http://twistedmatrix.com
|o O||
wvw-+
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] reference counting in Py3K
On 9/7/05, Josiah Carlson [EMAIL PROTECTED] wrote: Guido van Rossum [EMAIL PROTECTED] wrote: On 9/6/05, Greg Ewing [EMAIL PROTECTED] wrote: A better plan would be to build something akin to Pyrex into the scheme of things, so that all the refcount/GC issues are taken care of automatically. That sounds exciting. I have to admit that despite hearing many enthusiastic reviews, I've never used it myself -- in fact I've written very little C code in the last few years, and zero new extension modules. (Lots of Java, but that's another story. :-) Here's a perspective from the trenches as it were. Encouraging its use for the writing of new extension modules: ick, -1. Writing pretty yet high performing Pyrex is an art that I'm not sure anyone can master. I'd just like to put in that it seems like the suggestions to use Pyrex were aimed at C-library wrapping extensions, not necessarily ones that were written in C for performance (I gather that there are very few of those, comparatively). So the encouragement to use Pyrex for new extension modules still seems perfect, to me; its use should definitely be encouraged when one needs to wrap some third-party library, and I'd bet that that's the common case. -- Twisted | Christopher Armstrong: International Man of Twistery Radix|-- http://radix.twistedmatrix.com | Release Manager, Twisted Project \\\V/// |-- http://twistedmatrix.com |o O|| wvw-+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Asynchronous use of Traceback objects
With the implementation and soon release of PEP 342, I've been thinking more about traceback objects lately. First I'll give you some background information for my problem. I've implemented a module for integrating Twisted's Deferreds with the new yield expression, that allows you to do stuff like: @defgen def foo(): x = yield deferredOperation() print x Basically, defgen checks for Deferreds coming out of the generator, and when it finds one, adds a callback to that Deferred which will resume the generator, sending the result in. Since Deferreds have error support, it also allows code like this: @defgen def foo(userinput): try: x = yield deferredOperation(userinput) except ValueError: Crap, wrong user input! We have this object in Twisted called the Failure, which is used for conveniently passing around exceptions asynchronously, and Deferreds use them to represent errors in deferred operations. The Failure objects have a reference to an exception object and the traceback that was associated with the original raising of that exception. However, we can only hold on to that traceback for so long, because traceback objects have references to so many things and can so easily cause horrible GC issues. The loss of this traceback object isn't *usually* a problem because we store enough other information in the Failure object to print representations of tracebacks nicely. However, if we try to re-raise the exception, we lose that traceback information. defgen re-raises the exception from a Failure into a defgen-using function with g.throw(). Unfortunately, quite often the traceback has been cleaned from the Failure object, and this means you'll get exceptions in defgen-using code with very bizarre and uninformative tracebacks. I had the idea to create a fake Traceback object in Python that doesn't hold references to any frame objects, but is still able to be passed to 'raise' and formatted as tracebacks are, etc. Unfortunately, raise does a type check on its third argument and, besides, it seems the traceback formatting functions are very reliant on the internal structure of traceback objects, so that didn't work. It does seem that I would be able to construct a passable fake Traceback object from C code -- one that had references to fake frames. These fake objects would only remember the original line numbers, filenames and so forth so that traceback printing could still work. I can try implementing this soon, but I'd just like to make sure I'm on the right track. For example, perhaps a better idea would be to change the traceback-printing functions to use Python attribute lookup instead of internal structure lookup, and then change raise to accept arbitrary Python objects as its third argument, as long as it matches the traceback interface. That would probably mean much more work, though. One concern is that I really don't like requiring C modules to use Twisted; all of the ones currently in there are optional. What's the likelihood of such a traceback-constructor getting its way into CPython if I do implement it? It may seem niche, but I expect many Twisted users would like to use PEP 342 defgen (many users are already using the defgen I wrote for python 2.2 generators). Thanks for any help, and have fun, -- Twisted | Christopher Armstrong: International Man of Twistery Radix|-- http://radix.twistedmatrix.com | Release Manager, Twisted Project \\\V/// |-- http://twistedmatrix.com |o O|| wvw-+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Asynchronous use of Traceback objects
On 9/4/05, Phillip J. Eby [EMAIL PROTECTED] wrote: At 06:24 PM 9/3/2005 +1000, Christopher Armstrong wrote: For example, perhaps a better idea would be to change the traceback-printing functions to use Python attribute lookup instead of internal structure lookup, and then change raise to accept arbitrary Python objects as its third argument, as long as it matches the traceback interface. Given that traceback printing isn't a performance-critical activity, there probably isn't a reason any more for requiring a particular C layout. On the other hand, being able to create frame or traceback instances or subclasses would probably also solve your problem, without having to do too much hacking on the C code that expects a particular layout. I guess the biggest difference in these two strategies, to me, is that one can be implemented in an external module while the other *requires* changes to CPython to work. So I'll do the former, i.e., writing C functions that construct traceback objects, accessible from Python. Maybe after I do that I could write a PEP (if that's necessary) on changing the traceback stuff on a more fundamental level, to allow for Python objects. putting-on-his-C-gloves-ly, -- Twisted | Christopher Armstrong: International Man of Twistery Radix|-- http://radix.twistedmatrix.com | Release Manager, Twisted Project \\\V/// |-- http://twistedmatrix.com |o O|| wvw-+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
