
Hi, just wanted to send a note that lxml.etree compiles nicely under Python 2.5b3 (AMD64) using the patched Pyrex version here: http://codespeak.net/svn/lxml/pyrex/ The only problem I currently encounter is a bug in linecache in 2.5's stdlib that prevents the doctests from running. Once that's solved, we can see if those tests pass as well. Stefan

On 8/4/06, Stefan Behnel <behnel_ml@gkec.informatik.tu-darmstadt.de> wrote:
just wanted to send a note that lxml.etree compiles nicely under Python 2.5b3 (AMD64) using the patched Pyrex version here:
Woohoo! Thanks for testing this!
If there's really a bug in linecache, be sure to report it against Python on SourceForge so we can get it dealt with. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Every sin is the result of a collaboration." --Lucius Annaeus Seneca

Hi Fred, Fred Drake wrote:
Oh, well. I did report it and then almost instantly got a TYOF back. The problem was: lxml used its own version of doctest.py, which was no longer compatible with 2.5. I always wondered where that came from and what it was good for. Should have asked long ago, I guess... Anyway, now it's gone and there's only one minor error in the test runs. I'll check if I can fix it. It's exception related, so it may still be a bug in the patched Pyrex version. Stefan

On 8/4/06, Stefan Behnel <behnel_ml@gkec.informatik.tu-darmstadt.de> wrote:
Oh, well. I did report it and then almost instantly got a TYOF back. The
TYOF == "That's your own fault" ???
Hmm. There's a separate version in zope.testing as well. I've no idea if that's compatible with 2.5; there's so many other things that fall over with 2.5 it doesn't seem worthwhile to ask.
Ok. Let me know if there's anything I can help with on the 2.5 front. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Every sin is the result of a collaboration." --Lucius Annaeus Seneca

Fred Drake wrote:
Yup. :)
Apparently, they changed some monkeypatching stuff related to the "getlines()" function in linecache.py. It now has a different signature. :-/
Thanks for offering help, that's always appreciated. :) I'll give it some more investigation first. Stefan

Stefan Behnel wrote:
Ok, it was not a Pyrex bug. The problem is that lxml uses multiple inheritance in some exceptions and now that they are new style classes, it's no longer enough to call the constructor of the superclass directly. However, super() does not work for old style classes in 2.4, so I'm a bit challenged in getting this fixed in a backward compatible way. This works nicely in Python 2.4: class Error(Exception): pass class LxmlError(Error): def __init__(self, *args): Error.__init__(self, *args) self.error_log = __copyGlobalErrorLog() while Python 2.5 requires this: class LxmlError(Error): def __init__(self, *args): super(LxmlError, self).__init__(*args) self.error_log = __copyGlobalErrorLog() which does not work for classic classes in 2.3/4. Does anyone have an idea how to fix this nicely? Stefan

On 8/6/06, Stefan Behnel <behnel_ml@gkec.informatik.tu-darmstadt.de> wrote:
Please explain in detail what problems you had with this approach.
The Python 2.4 formulation should still work in Python 2.5. Direct calls to the superclass are not forbidden with new-style classes. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Every sin is the result of a collaboration." --Lucius Annaeus Seneca

Hi Fred, Fred Drake wrote:
As I said, I'm using this: class Error(Exception): pass class LxmlError(Error): def __init__(self, *args): Error.__init__(self, *args) self.error_log = __copyGlobalErrorLog() What I did not say is that afterwards, I use this: class XPathError(LxmlError): pass class LxmlSyntaxError(LxmlError, SyntaxError): pass class XPathSyntaxError(LxmlSyntaxError, XPathError): pass So there is a 'cross inheritance' here in XPathSyntaxError, but even when I remove the XPathError inheritance, I get the same result as follows. I now call this in Pyrex: raise XPathSyntaxError, "some message" and what comes out at the end is: Traceback ... XPathSyntaxError: None Which is not quite what you'd expect. I assume what happens is that the MRO ends up not calling Exception.__init__ or something, which leads to not setting the message. The following, works, however: class LxmlError(Error): def __init__(self, *args): super(LxmlError, self).__init__(*args) self.error_log = __copyGlobalErrorLog() What I now did was to call either the super() stuff or __init__ depending on Error being a subtype of 'object' or not. I would prefer having a simpler solution, though. Stefan

On 8/6/06, Stefan Behnel <behnel_ml@gkec.informatik.tu-darmstadt.de> wrote:
class LxmlSyntaxError(LxmlError, SyntaxError): pass
Is that the built-in SyntaxError? Leave that out. It's really only intended to be used with Python-language syntax errors. Handling for any other syntax errors should use separate exceptions specific to the processing for that language. Removing that, I get a reasonable error message for Python 2.4 and 2.5. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Every sin is the result of a collaboration." --Lucius Annaeus Seneca

On 8/6/06, Fred Drake <fdrake@gmail.com> wrote:
I think that elementtree and cElementTree do the same thing. I don't like this behavior at all, though -- I spent quite awhile trying to find a syntax error in my code a couple days ago when the real error was in the XML input. --Andy

Hi Fred, Fred Drake wrote:
Well, I'm not the one who put it there (and I definitely would not have used it in the first place). Thing is, lxml is heading for ElementTree compatibility and ElementTree raises a plain SyntaxError in the place where we raise LxmlSyntaxError. So removing the superclass would break compatibility to ET and also break existing code that depends on it... Stefan

On 8/6/06, Stefan Behnel <behnel_ml@gkec.informatik.tu-darmstadt.de> wrote:
Ok, I see. The SyntaxError is used directly in the ElementPath module. ;-( There's not going to be a really clean way to do this, or at least I can't think of it off-hand. Here's what I came up with; it's probably similar to what you did: =========================================== _newstyle_exceptions = isinstance(Exception, type) class Error(Exception): pass class LxmlError(Error): def __init__(self, *args): if _newstyle_exceptions: super(LxmlError, self).__init__(*args) else: Error.__init__(self, *args) self.error_log = [] class XPathError(LxmlError): pass class LxmlSyntaxError(LxmlError, SyntaxError): pass class XPathSyntaxError(LxmlSyntaxError, XPathError): pass raise XPathSyntaxError, "some message" =========================================== -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Every sin is the result of a collaboration." --Lucius Annaeus Seneca

Fred Drake wrote:
Jim, Tim, and others continously improved Python's doctest for Zope. The latest example is Benji's work on footnotes. AFAIK Zope's doctest was regularly sync'ed with Python's, though. At least Python 2.4's doctest is good enough for not having to ship your own version of it. Philipp

On 8/4/06, Stefan Behnel <behnel_ml@gkec.informatik.tu-darmstadt.de> wrote:
just wanted to send a note that lxml.etree compiles nicely under Python 2.5b3 (AMD64) using the patched Pyrex version here:
Woohoo! Thanks for testing this!
If there's really a bug in linecache, be sure to report it against Python on SourceForge so we can get it dealt with. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Every sin is the result of a collaboration." --Lucius Annaeus Seneca

Hi Fred, Fred Drake wrote:
Oh, well. I did report it and then almost instantly got a TYOF back. The problem was: lxml used its own version of doctest.py, which was no longer compatible with 2.5. I always wondered where that came from and what it was good for. Should have asked long ago, I guess... Anyway, now it's gone and there's only one minor error in the test runs. I'll check if I can fix it. It's exception related, so it may still be a bug in the patched Pyrex version. Stefan

On 8/4/06, Stefan Behnel <behnel_ml@gkec.informatik.tu-darmstadt.de> wrote:
Oh, well. I did report it and then almost instantly got a TYOF back. The
TYOF == "That's your own fault" ???
Hmm. There's a separate version in zope.testing as well. I've no idea if that's compatible with 2.5; there's so many other things that fall over with 2.5 it doesn't seem worthwhile to ask.
Ok. Let me know if there's anything I can help with on the 2.5 front. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Every sin is the result of a collaboration." --Lucius Annaeus Seneca

Fred Drake wrote:
Yup. :)
Apparently, they changed some monkeypatching stuff related to the "getlines()" function in linecache.py. It now has a different signature. :-/
Thanks for offering help, that's always appreciated. :) I'll give it some more investigation first. Stefan

Stefan Behnel wrote:
Ok, it was not a Pyrex bug. The problem is that lxml uses multiple inheritance in some exceptions and now that they are new style classes, it's no longer enough to call the constructor of the superclass directly. However, super() does not work for old style classes in 2.4, so I'm a bit challenged in getting this fixed in a backward compatible way. This works nicely in Python 2.4: class Error(Exception): pass class LxmlError(Error): def __init__(self, *args): Error.__init__(self, *args) self.error_log = __copyGlobalErrorLog() while Python 2.5 requires this: class LxmlError(Error): def __init__(self, *args): super(LxmlError, self).__init__(*args) self.error_log = __copyGlobalErrorLog() which does not work for classic classes in 2.3/4. Does anyone have an idea how to fix this nicely? Stefan

On 8/6/06, Stefan Behnel <behnel_ml@gkec.informatik.tu-darmstadt.de> wrote:
Please explain in detail what problems you had with this approach.
The Python 2.4 formulation should still work in Python 2.5. Direct calls to the superclass are not forbidden with new-style classes. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Every sin is the result of a collaboration." --Lucius Annaeus Seneca

Hi Fred, Fred Drake wrote:
As I said, I'm using this: class Error(Exception): pass class LxmlError(Error): def __init__(self, *args): Error.__init__(self, *args) self.error_log = __copyGlobalErrorLog() What I did not say is that afterwards, I use this: class XPathError(LxmlError): pass class LxmlSyntaxError(LxmlError, SyntaxError): pass class XPathSyntaxError(LxmlSyntaxError, XPathError): pass So there is a 'cross inheritance' here in XPathSyntaxError, but even when I remove the XPathError inheritance, I get the same result as follows. I now call this in Pyrex: raise XPathSyntaxError, "some message" and what comes out at the end is: Traceback ... XPathSyntaxError: None Which is not quite what you'd expect. I assume what happens is that the MRO ends up not calling Exception.__init__ or something, which leads to not setting the message. The following, works, however: class LxmlError(Error): def __init__(self, *args): super(LxmlError, self).__init__(*args) self.error_log = __copyGlobalErrorLog() What I now did was to call either the super() stuff or __init__ depending on Error being a subtype of 'object' or not. I would prefer having a simpler solution, though. Stefan

On 8/6/06, Stefan Behnel <behnel_ml@gkec.informatik.tu-darmstadt.de> wrote:
class LxmlSyntaxError(LxmlError, SyntaxError): pass
Is that the built-in SyntaxError? Leave that out. It's really only intended to be used with Python-language syntax errors. Handling for any other syntax errors should use separate exceptions specific to the processing for that language. Removing that, I get a reasonable error message for Python 2.4 and 2.5. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Every sin is the result of a collaboration." --Lucius Annaeus Seneca

On 8/6/06, Fred Drake <fdrake@gmail.com> wrote:
I think that elementtree and cElementTree do the same thing. I don't like this behavior at all, though -- I spent quite awhile trying to find a syntax error in my code a couple days ago when the real error was in the XML input. --Andy

Hi Fred, Fred Drake wrote:
Well, I'm not the one who put it there (and I definitely would not have used it in the first place). Thing is, lxml is heading for ElementTree compatibility and ElementTree raises a plain SyntaxError in the place where we raise LxmlSyntaxError. So removing the superclass would break compatibility to ET and also break existing code that depends on it... Stefan

On 8/6/06, Stefan Behnel <behnel_ml@gkec.informatik.tu-darmstadt.de> wrote:
Ok, I see. The SyntaxError is used directly in the ElementPath module. ;-( There's not going to be a really clean way to do this, or at least I can't think of it off-hand. Here's what I came up with; it's probably similar to what you did: =========================================== _newstyle_exceptions = isinstance(Exception, type) class Error(Exception): pass class LxmlError(Error): def __init__(self, *args): if _newstyle_exceptions: super(LxmlError, self).__init__(*args) else: Error.__init__(self, *args) self.error_log = [] class XPathError(LxmlError): pass class LxmlSyntaxError(LxmlError, SyntaxError): pass class XPathSyntaxError(LxmlSyntaxError, XPathError): pass raise XPathSyntaxError, "some message" =========================================== -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Every sin is the result of a collaboration." --Lucius Annaeus Seneca

Fred Drake wrote:
Jim, Tim, and others continously improved Python's doctest for Zope. The latest example is Benji's work on footnotes. AFAIK Zope's doctest was regularly sync'ed with Python's, though. At least Python 2.4's doctest is good enough for not having to ship your own version of it. Philipp
participants (5)
-
Andrew Lutomirski
-
Fred Drake
-
Martijn Faassen
-
Philipp von Weitershausen
-
Stefan Behnel