Re: [Python-Dev] Move encoding_decl to the top of Grammar/Grammar?
Here's the corresponding tracker issue: http://bugs.python.org/issue4347 I've uploaded a patch there anyway, since I'm going to need this stuff working for a presentation I'm giving tomorrow. Cheers, T Thomas Lee wrote: Hi all, Currently, Parser/parsetok.c has a dependency on graminit.h. This can cause headaches when rebuilding after adding new syntax to Grammar/Grammar because parsetok.c is part of pgen, which is responsible for *generating* graminit.h. This circular dependency can result in parsetok.c using a different value for encoding_decl to what is used in ast.c, which causes PyAST_FromNode to fall over at runtime. It effectively looks something like this: * Grammar/Grammar is modified * build begins -- pgen compiles, parsetok.c uses encoding_decl=X * graminit.h is rebuilt with encoding_decl=Y * ast.c is compiled using encoding_decl=Y * when python runs, parsetok() emits encoding_decl nodes that PyAST_FromNode can't recognize: SystemError: invalid node XXX for PyAST_FromNode A nice, easy short term solution that doesn't require unwinding this dependency would be to simply move encoding_decl to the top of Grammar/Grammar and add a big warning noting that it needs to come before everything else. This will help to ensure its value never changes when syntax is added/removed. I'm happy to provide a patch for this (including some additional dependency info for files dependent upon graminit.h and Python-ast.h), but was wondering if there were any opinions about how this should be resolved. Cheers, Tom ___ 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/tom%40vector-seven.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] Attribute error: providing type name
Martin v. Löwis wrote: > Alex Martelli wrote: > I think the standard exception hierarchy should grow additional standard > fields. E.g. AttributeError should have attributes 'type','name', or > perhaps even 'object','name'. TypeError should have attributes > 'expected', 'actual' (or, again, 'expected', 'object'). > And so on - that might produce quite a large PEP. I don't think there's any reason to do it in one big bang. And approached individually, each such alternate constructor is a small RFE consisting of: 1. Specific C API for creating exceptions of that type with a standard message and attributes 2. Python level class method 3. New attributes on the affected object Point 3 would be optional really, since most of the gain comes from the better error messages. If extra attributes were included in such an RFE, the potential lifecycle implications of including references to actual objects rather than merely their types makes the better choice fairly obvious to me (i.e. just include the type information, since it generally tells you everything you need to know for TypeErrors and AttributeErrors). > As 3.0 missed the > chance to fix this, compatibility is also an issue. It might be possible > to overload exception constructors on the number of parameters, or using > keyword parameters for the new way of filling the exception. Or go the traditional "multiple constructor" route and provide class methods for the alternative mechanisms. > And no, I don't volunteer to write this PEP :-) Assuming I understand what you mean by "nested exceptions" correctly, they should be covered by the __context__ and __cause__ attributes in Py3k: Exception context: === >>> try: ... raise IOError ... except: ... raise AttributeError ... Traceback (most recent call last): File "", line 2, in IOError During handling of the above exception, another exception occurred: Traceback (most recent call last): File "", line 4, in AttributeError === Exception cause: === >>> raise AttributeError from KeyError KeyError The above exception was the direct cause of the following exception: Traceback (most recent call last): File "", line 1, in AttributeError === Putting it all together: === >>> try: ... raise IOError ... except: ... try: ... raise KeyError ... except Exception as ex: ... raise AttributeError from ex ... Traceback (most recent call last): File "", line 2, in IOError During handling of the above exception, another exception occurred: Traceback (most recent call last): File "", line 5, in KeyError The above exception was the direct cause of the following exception: Traceback (most recent call last): File "", line 7, in AttributeError === Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- ___ 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] Tomorrow's releases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I believe we are on track for releasing Python 3.0 final and 2.6.1 tomorrow. There is just one release blocker for 3.0 left -- Guido needs to finish the What's New for 3.0. This is bug 2306. So that Martin can have something to work with when he wakes up tomorrow morning, I would like to tag and branch the tree some time today, Tuesday 02-Dec US/Eastern. Therefore I am freezing both the 2.6 and 3.0 trees, with special dispensation to Guido for the updated What's New. Ping me on irc @ freenode #python-dev if you have anything else to check in to either tree before then. As soon as I hear from Guido, or issue 2306 is closed, I'm branching 3.0 and tagging it for release. Great work everyone, we're almost there! - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSTWbPnEjvBPtnXfVAQKtOgP9EZgGkE8/UY1IRn7j0l6vX6uqbPapg+9H MlBIZrA6mEbGiaDSvPRiwuo71jP5cg0u/xFRdDlGYl0GAzOEWvKCZVlVsndM4kbh 7UxHjHfkIOo4MUw4zz1NrJ4GRNgBQa52OOtiOKKkIhr/oMsg+GWv8Y9hRXYA9xue s8as2AQe2QU= =5j55 -END PGP SIGNATURE- ___ 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] Attribute error: providing type name
Nick Coghlan wrote: > Martin v. Löwis wrote: >> Alex Martelli wrote: >> I think the standard exception hierarchy should grow additional standard >> fields. E.g. AttributeError should have attributes 'type','name', or >> perhaps even 'object','name'. TypeError should have attributes >> 'expected', 'actual' (or, again, 'expected', 'object'). > >> And so on - that might produce quite a large PEP. > > I don't think there's any reason to do it in one big bang. And > approached individually, each such alternate constructor is a small RFE > consisting of: > > 1. Specific C API for creating exceptions of that type with a standard > message and attributes > 2. Python level class method > 3. New attributes on the affected object > > Point 3 would be optional really, since most of the gain comes from the > better error messages. If extra attributes were included in such an RFE, > the potential lifecycle implications of including references to actual > objects rather than merely their types makes the better choice fairly > obvious to me (i.e. just include the type information, since it > generally tells you everything you need to know for TypeErrors and > AttributeErrors). > >> As 3.0 missed the >> chance to fix this, compatibility is also an issue. It might be possible >> to overload exception constructors on the number of parameters, or using >> keyword parameters for the new way of filling the exception. > > Or go the traditional "multiple constructor" route and provide class > methods for the alternative mechanisms. > Bear in mind, though, that as new functionality none of this can go in before 3.1/2.7. So a PEP might not be a bad idea if only to establish best practices. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.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
[Python-Dev] Accessing source code in zipped packages
About a month ago, I submitted two patches that address Pdb and doctest inability to load source code from modules with custom loaders such as modules loaded from zip files: http://bugs.python.org/issue4201 http://bugs.python.org/issue4197 The patches are very simple, basically calls to linecache.getline() need to be provided with the module's dict to enable linecache to find the module's __loader__. Is there a chance that these patches could make it to 2.6.1? ___ 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] Accessing source code in zipped packages
Alexander Belopolsky schrieb: About a month ago, I submitted two patches that address Pdb and doctest inability to load source code from modules with custom loaders such as modules loaded from zip files: http://bugs.python.org/issue4201 http://bugs.python.org/issue4197 The patches are very simple, basically calls to linecache.getline() need to be provided with the module's dict to enable linecache to find the module's __loader__. There is also http://bugs.python.org/issue4223 which goes in the same direction. Georg ___ 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
