Re: [Python-Dev] [python-committers] [RELEASED] Python 3.2 rc 1
Hi Georg, I can't be sure it is a bug, but there is a definite difference of behavior between 3.0/3.1 and 3.2rc1. Given this directory layout: $ ls -R Graphics/ Graphics/: __init__.py Vector Xpm.py Graphics/Vector: __init__.py Svg.py And these files: $ cat Graphics/__init__.py __all__ = [Xpm] $ cat Graphics/Xpm.py #!/usr/bin/env python3 XPM = 0 $ cat Graphics/Vector/__init__.py __all__ = [Svg] $ cat Graphics/Vector/Svg.py #!/usr/bin/env python3 from ..Graphics import Xpm SVG = 1 I can do the relative import with Python 3.0 and 3.1 but not with 3.2rc1: $ python30 Python 3.0.1 (r301:69556, Jul 15 2010, 10:31:51) [GCC 4.4.4] on linux2 Type help, copyright, credits or license for more information. from Graphics.Vector import * Svg.SVG 1 $ python31 Python 3.1.2 (r312:79147, Jul 15 2010, 10:56:05) [GCC 4.4.4] on linux2 Type help, copyright, credits or license for more information. from Graphics.Vector import * Svg.SVG 1 $ ~/opt/python32rc1/bin/python3 Python 3.2rc1 (r32rc1:88035, Jan 16 2011, 08:32:59) [GCC 4.4.5] on linux2 Type help, copyright, credits or license for more information. from Graphics.Vector import * Traceback (most recent call last): File stdin, line 1, in module File Graphics/Vector/Svg.py, line 2, in module from ..Graphics import Xpm ImportError: No module named Graphics Should I report it as a bug or is this a planned change of behavior (or was the original behavior wrong?). -- Mark Summerfield, Qtrac Ltd, www.qtrac.eu C++, Python, Qt, PyQt - training and consultancy Advanced Qt Programming - ISBN 0321635906 http://www.qtrac.eu/aqpbook.html ___ 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] [python-committers] [RELEASED] Python 3.2 rc 1
On Mon, Jan 17, 2011 at 2:03 PM, Mark Summerfield l...@qtrac.plus.com wrote: Hi Georg, I can't be sure it is a bug, but there is a definite difference of behavior between 3.0/3.1 and 3.2rc1. I can do the relative import with Python 3.0 and 3.1 but not with 3.2rc1: Are you sure that the package that you are trying to import is the PYTHONPATH of your system's Python 3.0 and Python 3.1 and Not in RC1? Looks to me a PYTHONPATH problem than a problem with rc1. - I tried to recreate the directory structure that you mentioned and tried from Graphics.Vector import * It failed with ImportError on python3, 3.1 and rc. - Just to test the relative imports, I created a directory structure as mentioned here: http://www.python.org/dev/peps/pep-0328/ and tried to test the relative import for usecase :- from ..moduleA import foo and works fine in rc1. - I also find that your use case (from ..Graphics import XPM in Graphics/Vector/Svg.py) is not one of the listed ones in PEP-0328. -- Senthil ___ 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] os.ioprio_get() and os.ioprio_set()
I've recently implemented this functionality in psutil: http://code.google.com/p/psutil/issues/detail?id=147 If desired, I can contribute a patch for the os module, altough being such functions Linux-only, I'm not sure os module is the right place for them to land. Also, I've been thinking about this for quite a bit: would it be the case to add system-specific modules such as linux (and maybe also a win32) to the standard library? --- Giampaolo http://code.google.com/p/pyftpdlib/ http://code.google.com/p/psutil/ ___ 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] os.ioprio_get() and os.ioprio_set()
On Mon, 17 Jan 2011 14:53:19 +0100 Giampaolo Rodolà g.rod...@gmail.com wrote: I've recently implemented this functionality in psutil: http://code.google.com/p/psutil/issues/detail?id=147 If desired, I can contribute a patch for the os module, altough being such functions Linux-only, I'm not sure os module is the right place for them to land. Also, I've been thinking about this for quite a bit: would it be the case to add system-specific modules such as linux (and maybe also a win32) to the standard library? The problem with something named linux is that when some of these APIs get ported to other Unix variants, things will get very confusing. win32 is different since it's quite unlikely for some Windows-specific APIs to get ported to other OSes. Regards Antoine. ___ 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] [python-committers] [RELEASED] Python 3.2 rc 1
On Mon, 17 Jan 2011 09:23:39 -0500 R. David Murray rdmur...@bitdance.com wrote: On Mon, 17 Jan 2011 08:33:42 +, Mark Summerfield l...@qtrac.plus.com wrote: from ..Graphics import Xpm SVG = 1 I can do the relative import with Python 3.0 and 3.1 but not with 3.2rc1: What about 3.1.3? I wonder if it is related to this issue: http://bugs.python.org/issue7902 -- R. David Murray www.bitdance.com I'm not sure. Anyway, I have reported it a Georg's suggestion: http://bugs.python.org/issue10926 And mentioned issue7902. -- Mark Summerfield, Qtrac Ltd, www.qtrac.eu C++, Python, Qt, PyQt - training and consultancy Programming in Python 3 - ISBN 0321680561 http://www.qtrac.eu/py3book.html ___ 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] [python-committers] [RELEASED] Python 3.2 rc 1
On Mon, 17 Jan 2011 08:33:42 +, Mark Summerfield l...@qtrac.plus.com wrote: from ..Graphics import Xpm SVG = 1 I can do the relative import with Python 3.0 and 3.1 but not with 3.2rc1: What about 3.1.3? I wonder if it is related to this issue: http://bugs.python.org/issue7902 -- R. David Murray www.bitdance.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] devguide: Add a doc outlining how to add something to the stdlib.
On Sun, 16 Jan 2011 21:38:43 +0100 brett.cannon python-check...@python.org wrote: + +Adding to a pre-existing module +--- + +If you have found that a function, method, or class is useful and you believe +it would be useful to the general Python community, there are some steps to go +through in order to see it added to the stdlib. + +First is you need to gauge the usefulness of the code. Typically this is done +by sharing the code publicly. Actually, most feature requests get approved without this intermediate step. So I would suggest directing people to the tracker instead. Only very large or controversial additions usually get refused on these grounds. Regards Antoine. ___ 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] devguide: Add a doc outlining how to add something to the stdlib.
On Mon, Jan 17, 2011 at 12:00, Antoine Pitrou solip...@pitrou.net wrote: On Sun, 16 Jan 2011 21:38:43 +0100 brett.cannon python-check...@python.org wrote: + +Adding to a pre-existing module +--- + +If you have found that a function, method, or class is useful and you believe +it would be useful to the general Python community, there are some steps to go +through in order to see it added to the stdlib. + +First is you need to gauge the usefulness of the code. Typically this is done +by sharing the code publicly. Actually, most feature requests get approved without this intermediate step. So I would suggest directing people to the tracker instead. Only very large or controversial additions usually get refused on these grounds. I weakened it to a suggestion, but didn't cut it entirely as I still think it's a good step to take. -Brett Regards Antoine. ___ 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/brett%40python.org ___ 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] Exception __name__ missing?
Is this on purpose?
Python 3.2rc1 (py3k:88040, Jan 15 2011, 18:11:39)
[GCC 4.4.5] on linux2
Type help, copyright, credits or license for more information.
Exception.__name__
'Exception'
e = Exception('has no name')
e.__name__
Traceback (most recent call last):
File stdin, line 1, in module
AttributeError: 'Exception' object has no attribute '__name__'
Ron Adam
___
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] devguide: Add a doc outlining how to add something to the stdlib.
On Mon, 17 Jan 2011 21:00:10 +0100, Antoine Pitrou solip...@pitrou.net wrote: On Sun, 16 Jan 2011 21:38:43 +0100 brett.cannon python-check...@python.org wrote: + +Adding to a pre-existing module +--- + +If you have found that a function, method, or class is useful and you believe +it would be useful to the general Python community, there are some steps to go +through in order to see it added to the stdlib. + +First is you need to gauge the usefulness of the code. Typically this is done +by sharing the code publicly. Actually, most feature requests get approved without this intermediate step. So I would suggest directing people to the tracker instead. Only very large or controversial additions usually get refused on these grounds. A new contributor isn't in general going to know when a small change is controversial without asking *somewhere*, be it a mailing list or the tracker. Searching the tracker to make sure it hasn't already been proposed and rejected is, of course, a good idea. Perhaps the 'search the tracker' advice is worth repeating in this specific context. -- R. David Murray www.bitdance.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] Moving stuff out of Misc and over to the devguide
There is a bunch of stuff in Misc that probably belongs in the devguide (under Resources) instead of in svn. Here are the files I think can be moved (in order of how strongly I think they should be moved): PURIFY.README README.coverty README.klocwork README.valgrind Porting developers.txt maintainers.rst SpecialBuilds.txt Now before anyone yells that is inconvenient, don't forget that all core developers can check out and edit the devguide, and that almost all of the files listed (SpecialBuilds.txt is the exception) are typically edited and viewed on their own. Anyway, if there is a file listed here you don't think should move out of py3k and into the devguide, speak up. ___ 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] Exception __name__ missing?
Am 17.01.2011 21:22, schrieb Ron Adam:
Is this on purpose?
Python 3.2rc1 (py3k:88040, Jan 15 2011, 18:11:39)
[GCC 4.4.5] on linux2
Type help, copyright, credits or license for more information.
Exception.__name__
'Exception'
e = Exception('has no name')
e.__name__
Traceback (most recent call last):
File stdin, line 1, in module
AttributeError: 'Exception' object has no attribute '__name__'
It's not on purpose in the sense that it's not something special
to exceptions. The class __name__ attribute is not accessible
from instances of any class.
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
Re: [Python-Dev] Exception __name__ missing?
2011/1/17 Ron Adam r...@ronadam.com: Is this on purpose? Of course: instances don't have names. -- Regards, Benjamin ___ 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] Moving stuff out of Misc and over to the devguide
Am 17.01.2011 21:32, schrieb Brett Cannon: There is a bunch of stuff in Misc that probably belongs in the devguide (under Resources) instead of in svn. Here are the files I think can be moved (in order of how strongly I think they should be moved): PURIFY.README README.coverty README.klocwork README.valgrind Porting developers.txt maintainers.rst SpecialBuilds.txt Now before anyone yells that is inconvenient, don't forget that all core developers can check out and edit the devguide, and that almost all of the files listed (SpecialBuilds.txt is the exception) are typically edited and viewed on their own. Anyway, if there is a file listed here you don't think should move out of py3k and into the devguide, speak up. No objections, +1. While it seems convenient to have (e.g.) the list of maintainers directly in the source tree, a) developers already know where to find it, no matter if in Misc/ or devguide/ b) others first have to find it anyway, and it's better to find when embedded in the rest of developer-related docs c) everyone can commit to the devguide as well as to cpython d) people should get used to multiple repos with hg coming Same goes for developers.txt. 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
Re: [Python-Dev] Moving stuff out of Misc and over to the devguide
On Mon, Jan 17, 2011 at 12:32 PM, Brett Cannon br...@python.org wrote: There is a bunch of stuff in Misc that probably belongs in the devguide (under Resources) instead of in svn. Here are the files I think can be moved (in order of how strongly I think they should be moved): PURIFY.README README.coverty README.klocwork README.valgrind Porting developers.txt maintainers.rst SpecialBuilds.txt Now before anyone yells that is inconvenient, don't forget that all core developers can check out and edit the devguide, and that almost all of the files listed (SpecialBuilds.txt is the exception) are typically edited and viewed on their own. Anyway, if there is a file listed here you don't think should move out of py3k and into the devguide, speak up. Wow, that Purify file is really old... Unless anyone can confirm it still works, maybe just toss it? Barry? I would think the best way to decide whether something belongs in the developers guide or in Misc is whether it makes sense for this information to be included in that tar files that people download for specific releases. Especially files that contain stuff that might be useful to copy/paste might still be better off closer to the source code. From that POV the files for which the argument to move them over to devguide is weakest are PURIFY.README (though it really should be named README.purify :-), README.valgrind, and SpecialBuilds.txt. There's also something to be said for keeping version-dependent info closer to the source code -- personally, I would expect to be reading the devguide online. -- --Guido van Rossum (python.org/~guido) ___ 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] Moving stuff out of Misc and over to the devguide
On Mon, 17 Jan 2011 12:32:20 -0800 Brett Cannon br...@python.org wrote: There is a bunch of stuff in Misc that probably belongs in the devguide (under Resources) instead of in svn. Here are the files I think can be moved (in order of how strongly I think they should be moved): PURIFY.README README.coverty README.klocwork README.valgrind Porting developers.txt maintainers.rst SpecialBuilds.txt Now before anyone yells that is inconvenient, don't forget that all core developers can check out and edit the devguide, and that almost all of the files listed (SpecialBuilds.txt is the exception) are typically edited and viewed on their own. Well it *is* inconvenient in the case of maintainers.rst, which is often consulted casually for daily bug tracker work. Grepping Misc/maintainers.rst is much easier than first having to find again where your checkout of the devguide is, and ensuring it is up-to-date. Also, I see no need to put the maintainers list in the dev guide, actually. Regards Antoine. ___ 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] devguide: Add a doc outlining how to add something to the stdlib.
On Mon, Jan 17, 2011 at 12:32, R. David Murray rdmur...@bitdance.com wrote: On Mon, 17 Jan 2011 21:00:10 +0100, Antoine Pitrou solip...@pitrou.net wrote: On Sun, 16 Jan 2011 21:38:43 +0100 brett.cannon python-check...@python.org wrote: + +Adding to a pre-existing module +--- + +If you have found that a function, method, or class is useful and you believe +it would be useful to the general Python community, there are some steps to go +through in order to see it added to the stdlib. + +First is you need to gauge the usefulness of the code. Typically this is done +by sharing the code publicly. Actually, most feature requests get approved without this intermediate step. So I would suggest directing people to the tracker instead. Only very large or controversial additions usually get refused on these grounds. A new contributor isn't in general going to know when a small change is controversial without asking *somewhere*, be it a mailing list or the tracker. Searching the tracker to make sure it hasn't already been proposed and rejected is, of course, a good idea. Perhaps the 'search the tracker' advice is worth repeating in this specific context. done ___ 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] Exception __name__ missing?
On 1/17/2011 3:22 PM, Ron Adam wrote: Is this on purpose? This reminds me of something I ran into a few years ago wrt. the attribute on exceptions. Namely, that instances of built-in exceptions do not have a __module__ attribute, but instance of user exceptions do -- a change which appeared in Python 2.5: http://mail.python.org/pipermail/python-list/2007-November/1088229.html I had a use case, using ZSI to provide a SOAP interface, where being able to get the __module__ and __name__ was needed (to serialize into a SOAP fault message). I worked around the issue by referencing the __class__ (as the other replier mentioned). But, I didn't receive any responses then, so I think not a lot of attention was put into these type of attributes on exceptions. -- Scott Dial sc...@scottdial.com scod...@cs.indiana.edu ___ 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] Moving stuff out of Misc and over to the devguide
On Tue, Jan 18, 2011 at 6:54 AM, Antoine Pitrou solip...@pitrou.net wrote: Well it *is* inconvenient in the case of maintainers.rst, which is often consulted casually for daily bug tracker work. Grepping Misc/maintainers.rst is much easier than first having to find again where your checkout of the devguide is, and ensuring it is up-to-date. Also, I see no need to put the maintainers list in the dev guide, actually. Every time I see someone syncing the version-independent maintainers list across branches a little alarm bell goes off in my head to say that file should be somewhere other than the main source tree. It's also quite possible that once the maintainer list is part of the dev guide, triagers will start using the official copy on python.org and the search function in their web browser rather than running grep over a source checkout. So moving the version-independent stuff certainly makes sense, but the stuff that is dependent on a particular version's build system is more questionable. What may make sense is for the devguide to describe the general contents of the files in Misc, but point out that for any given version, the version specific details in Misc take precedence. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | 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
Re: [Python-Dev] Exception __name__ missing?
On Tue, Jan 18, 2011 at 7:09 AM, Scott Dial scott+python-...@scottdial.com wrote: I worked around the issue by referencing the __class__ (as the other replier mentioned). But, I didn't receive any responses then, so I think not a lot of attention was put into these type of attributes on exceptions. That's not a workaround, it is the way you're meant to access __module__ and __name__ on new-style classes (which was the transition that happened for Exception in 2.5). The fact that user-defined classes get a __module__ attribute on instances while builtin and extension types don't isn't unique to exceptions though: class C: pass ... C.__module__ '__main__' C().__module__ '__main__' str.__module__ 'builtins' str().__module__ Traceback (most recent call last): File stdin, line 1, in module AttributeError: 'str' object has no attribute '__module__' import datetime datetime.datetime.__module__ 'datetime' datetime.datetime.now().__module__ Traceback (most recent call last): File stdin, line 1, in module AttributeError: 'datetime.datetime' object has no attribute '__module__' The addition of __module__ to user defined class instances strikes me as a bug. You can see in the language reference [1] that __dict__ and __class__ are the only expected data attributes for class instances. [1] http://docs.python.org/dev/reference/datamodel.html (search for the entry on class instances, then scroll back up and contrast with the sections on class objects, functions and methods) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | 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
Re: [Python-Dev] devguide: Cover how to (un-)apply a patch.
On Mon, 17 Jan 2011 23:37:07 +0100 brett.cannon python-check...@python.org wrote: + +To undo a patch, do:: + +patch -R -p0 patch.diff + Or, simply and more reliably, use the corresponding VCS incantation (svn revert -R . or hg revert -a). Regards Antoine. ___ 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] Moving stuff out of Misc and over to the devguide
On Jan 17, 2011, at 12:53 PM, Guido van Rossum wrote: Wow, that Purify file is really old... Unless anyone can confirm it still works, maybe just toss it? Barry? Wow indeed. The email address in there hasn't worked in, what? a decade? :) Toss it! -Barry signature.asc Description: 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] devguide: Cover how to (un-)apply a patch.
Done On Mon, Jan 17, 2011 at 15:14, Antoine Pitrou solip...@pitrou.net wrote: On Mon, 17 Jan 2011 23:37:07 +0100 brett.cannon python-check...@python.org wrote: + +To undo a patch, do:: + + patch -R -p0 patch.diff + Or, simply and more reliably, use the corresponding VCS incantation (svn revert -R . or hg revert -a). Regards Antoine. ___ 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/brett%40python.org ___ 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] Moving stuff out of Misc and over to the devguide
On Mon, Jan 17, 2011 at 14:41, Nick Coghlan ncogh...@gmail.com wrote: On Tue, Jan 18, 2011 at 6:54 AM, Antoine Pitrou solip...@pitrou.net wrote: Well it *is* inconvenient in the case of maintainers.rst, which is often consulted casually for daily bug tracker work. Grepping Misc/maintainers.rst is much easier than first having to find again where your checkout of the devguide is, and ensuring it is up-to-date. Also, I see no need to put the maintainers list in the dev guide, actually. Every time I see someone syncing the version-independent maintainers list across branches a little alarm bell goes off in my head to say that file should be somewhere other than the main source tree. Ditto for me. It's also quite possible that once the maintainer list is part of the dev guide, triagers will start using the official copy on python.org and the search function in their web browser rather than running grep over a source checkout. So moving the version-independent stuff certainly makes sense, but the stuff that is dependent on a particular version's build system is more questionable. What may make sense is for the devguide to describe the general contents of the files in Misc, but point out that for any given version, the version specific details in Misc take precedence. I am not describing what is in Misc. It comes down to a question of whether any core dev-specific stuff should be in Misc that is not a configuration file or not. I say no, that the directory should contain stuff that applies to everyone and not specifically to core devs. -Brett -Brett Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | 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/brett%40python.org ___ 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] devguide: Cover how to (un-)apply a patch.
Antoine On Mon, 17 Jan 2011 23:37:07 +0100 Antoine brett.cannon python-check...@python.org wrote: + +To undo a patch, do:: + +patch -R -p0 patch.diff + Antoine Or, simply and more reliably, use the corresponding VCS Antoine incantation (svn revert -R . or hg revert -a). I prefer Brett's solution. It's one command instead of one command per VCS. It works with other version control systems and provides me the opportunity to save a copy I can restore later. Skip ___ 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] Exception __name__ missing?
On 01/17/2011 02:27 PM, Georg Brandl wrote:
Am 17.01.2011 21:22, schrieb Ron Adam:
Is this on purpose?
Python 3.2rc1 (py3k:88040, Jan 15 2011, 18:11:39)
[GCC 4.4.5] on linux2
Type help, copyright, credits or license for more information.
Exception.__name__
'Exception'
e = Exception('has no name')
e.__name__
Traceback (most recent call last):
File stdin, line 1, inmodule
AttributeError: 'Exception' object has no attribute '__name__'
It's not on purpose in the sense that it's not something special
to exceptions. The class __name__ attribute is not accessible
from instances of any class.
Yes, I realised this on the way to an appointment. Oh well. ;-)
What I needed was e.__class__.__name__ instead of e.__name__.
I should have thought about this a little more before posting.
The particular reason I wanted it was to format a nice message for
displaying in pydoc browser mode. The server errors, like a missing .css
file, and any other server related errors, go the server console, while the
content errors get displayed in a web page. ie... object not found, or
some other content related reason for not giving what was asked for.
Doing repr(e) was giving me too much.
UnicodeDecodeError('utf8', b'\x7fELF\x02\x01\x01\x00\x00\x00\x
With pages of bytes, and I'd rather not truncate it, although that would be ok.
str(e) was more useful, but didn't include the exception name.
'utf8' codec can't decode byte 0xe0 in position 24: invalid
continuation byte
So doing e.__name__ was the obvious next thing... for some reason I
expected the __name__ attribute in exception instances to be inherited from
the class. Beats me why. shrug
Thanks,
Ron
___
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] devguide: Cover how to (un-)apply a patch.
Am 18.01.2011 01:19, schrieb s...@pobox.com: Antoine On Mon, 17 Jan 2011 23:37:07 +0100 Antoine brett.cannon python-check...@python.org wrote: + +To undo a patch, do:: + +patch -R -p0 patch.diff + Antoine Or, simply and more reliably, use the corresponding VCS Antoine incantation (svn revert -R . or hg revert -a). I prefer Brett's solution. It's one command instead of one command per VCS. It works with other version control systems and provides me the opportunity to save a copy I can restore later. It assumes you already have the copy. 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
Re: [Python-Dev] Exception __name__ missing?
Am 18.01.2011 03:41, schrieb Ron Adam:
On 01/17/2011 02:27 PM, Georg Brandl wrote:
Am 17.01.2011 21:22, schrieb Ron Adam:
Is this on purpose?
Python 3.2rc1 (py3k:88040, Jan 15 2011, 18:11:39)
[GCC 4.4.5] on linux2
Type help, copyright, credits or license for more information.
Exception.__name__
'Exception'
e = Exception('has no name')
e.__name__
Traceback (most recent call last):
File stdin, line 1, inmodule
AttributeError: 'Exception' object has no attribute '__name__'
It's not on purpose in the sense that it's not something special
to exceptions. The class __name__ attribute is not accessible
from instances of any class.
Yes, I realised this on the way to an appointment. Oh well. ;-)
What I needed was e.__class__.__name__ instead of e.__name__.
I should have thought about this a little more before posting.
The particular reason I wanted it was to format a nice message for
displaying in pydoc browser mode. The server errors, like a missing .css
file, and any other server related errors, go the server console, while the
content errors get displayed in a web page. ie... object not found, or
some other content related reason for not giving what was asked for.
Doing repr(e) was giving me too much.
UnicodeDecodeError('utf8', b'\x7fELF\x02\x01\x01\x00\x00\x00\x
With pages of bytes, and I'd rather not truncate it, although that would be
ok.
str(e) was more useful, but didn't include the exception name.
'utf8' codec can't decode byte 0xe0 in position 24: invalid
continuation byte
For these cases, you can use traceback.format_exception_only().
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
