Re: [Python-Dev] Why doesn't `functools.total_ordering` use the existing ordering methods?
On Mon, Apr 25, 2011 at 20:43, cool-RR wrote: > Hello, > Today I was trying to use `total_ordering` for the first time. I was > expecting that in order to implement e.g. `x > y` it would do `not x < y and > not x == y`, assuming that `__lt__` and `__eq__` are defined. But I see it > just does `y < x`, which is problematic. For example if you have a class > that is decorated by `total_ordering`, and implements only `__lt__` and > `__eq__`, then trying to do `x < y` will result in infinite recursion. > Why not have `total_ordering` work in the way I suggested? This has been partly fixed for Python 3.2, although it can still happen if you compare two types that both use the total_ordering decorator. See http://bugs.python.org/issue10042 . -- Lennart Regebro: http://regebro.wordpress.com/ Porting to Python 3: http://python3porting.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] cpython (2.7): #11901: add description of how bitfields are laid out to hexversion docs
On 25.04.2011 22:14, r.david.murray wrote: > http://hg.python.org/cpython/rev/48758cd0769b > changeset: 69558:48758cd0769b > branch: 2.7 > parent: 69545:e4fcfb8066ff > user:R David Murray > date:Mon Apr 25 16:10:18 2011 -0400 > summary: > #11901: add description of how bitfields are laid out to hexversion docs > > Patch by Sijin Joseph. > > files: > Doc/library/sys.rst | 24 > Misc/ACKS | 1 + > 2 files changed, 25 insertions(+), 0 deletions(-) > > > diff --git a/Doc/library/sys.rst b/Doc/library/sys.rst > --- a/Doc/library/sys.rst > +++ b/Doc/library/sys.rst > @@ -562,6 +562,30 @@ > ``version_info`` value may be used for a more human-friendly encoding of > the > same information. > > + The ``hexversion`` is a 32-bit number with the following layout Should have a colon at the end. > + > + > +-++ > + | bits (big endian order) | meaning > | We usually have table headings capitalized. > + > +=++ > + | :const:`1-8`| ``PY_MAJOR_VERSION`` (the ``2`` in > | > + | | ``2.1.0a3``) > | > + > +-++ > + | :const:`9-16` | ``PY_MINOR_VERSION`` (the ``1`` in > | > + | | ``2.1.0a3``) > | > + > +-++ > + | :const:`17-24` | ``PY_MICRO_VERSION`` (the ``0`` in > | > + | | ``2.1.0a3``) > | > + > +-++ > + | :const:`25-28` | ``PY_RELEASE_LEVEL`` (``0xA`` for alpha, > | > + | | ``0xB`` for beta, ``0xC`` for gamma and > | Even though PY_RELEASE_LEVEL_GAMMA is defined, I think this should say "release candidate" instead of "gamma". > + | | ``0xF`` for final) > | > + > +-++ > + | :const:`29-32` | ``PY_RELEASE_SERIAL`` (the ``3`` in > | > + | | ``2.1.0a3``) > | > + > +-++ ... and zero in final releases. > + thus ``2.1.0a3`` is hexversion ``0x020100a3`` Please capitalize and add a period. 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] [Python-checkins] cpython (3.2): Issue #11919: try to fix test_imp failure on some buildbots.
This seems to be changing what is tested -- are you saying that filenames with an included directory name are not intended to be supported? On 4/25/11, antoine.pitrou wrote: > http://hg.python.org/cpython/rev/2f2c7eb27437 > changeset: 69556:2f2c7eb27437 > branch: 3.2 > parent: 69554:77cf9e4b144b > user:Antoine Pitrou > date:Mon Apr 25 21:39:49 2011 +0200 > summary: > Issue #11919: try to fix test_imp failure on some buildbots. > > files: > Lib/test/test_imp.py | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > > diff --git a/Lib/test/test_imp.py b/Lib/test/test_imp.py > --- a/Lib/test/test_imp.py > +++ b/Lib/test/test_imp.py > @@ -171,8 +171,9 @@ > support.rmtree(test_package_name) > > def test_issue9319(self): > +path = os.path.dirname(__file__) > self.assertRaises(SyntaxError, > - imp.find_module, "test/badsyntax_pep3120") > + imp.find_module, "badsyntax_pep3120", [path]) > > > class ReloadTests(unittest.TestCase): > > -- > Repository URL: http://hg.python.org/cpython > ___ 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-checkins] cpython (3.2): Issue #11919: try to fix test_imp failure on some buildbots.
Le mardi 26 avril 2011 à 10:03 -0400, Jim Jewett a écrit : > This seems to be changing what is tested -- are you saying that > filenames with an included directory name are not intended to be > supported? I don't know, but that's not the point of this very test. (I also find it a bit surprising that find_module() would accept a module name - and not a filename - containing a slash and treat it as some kind of directory path) 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
[Python-Dev] Tip for hg merge
Hi, > If not, next developer tring to merge will find some other > unrelated code to merge, and she doesn't have the context knowledge to > know what to do :-). Here’s a useful tip: instead of merging pulled changesets with your branch, do the reverse. That is: $ hg pull $ hg heads . # get only heads for the checked-out branch $ hg up other-head $ hg merge Now instead of merging unknown code into your checkout, you will merge the code added by your unpushed changesets to the other code. If you’re using a three-way file merge tool, it is your code that will be in the “other” pane, not the unknown code. Regards ___ 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] Allowing import star with namespaces
We all know that doing: > from pkg import * is bad because it obliterates the 'pkg' namespace. So why not allow something like: > import pkg.* This would still be helpful for interactive sessions while keeping namespaces around. Sorry if this has been brought up before, my searching didn't find anything relevant in the archives. Thanks, Brendan ___ 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] Allowing import star with namespaces
Brendan Moloney wrote: We all know that doing: from pkg import * is bad because it obliterates the 'pkg' namespace. So why not allow something like: I don't quite know what you mean by obliterating the pkg namespace, but if my guess is correct, you're wrong. One of the problems with import * is that it (potentially) obliterates the caller's namespace, not pkg. That is, if you have a function spam(), and you do "from module import *", and module also has spam(), it blows away your function. The pkg namespace isn't touched -- it's just unavailable to the caller. >> import pkg.* This would still be helpful for interactive sessions while keeping namespaces around. I don't understand what the difference between that and just "import pkg" would be. By the way, this sort of question should probably go to the python-ideas mailing list for any extended discussion. -- Steven ___ 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] Allowing import star with namespaces
Brendan Moloney wrote: We all know that doing: --> from pkg import * is bad because it obliterates the 'pkg' namespace. The strongest reason for not doing this is that it pollutes the current namespace, not that it obliterates the 'pkg' namespace. So why not allow something like: --> import pkg.* How would that be different from --> import pkg ? If you want convenience for interactive work, you can always: --> import pkg --> from pkg import * and then have the best (and worst!) of both techniques. ~Ethan~ ___ 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] cpython: test_logging coverage improvements.
On Tue, 26 Apr 2011 19:43:12 +0200 vinay.sajip wrote: > http://hg.python.org/cpython/rev/ababe8a73327 > changeset: 69575:ababe8a73327 > user:Vinay Sajip > date:Tue Apr 26 18:43:05 2011 +0100 > summary: > test_logging coverage improvements. Apparently produces some failures: == FAIL: test_time (test.test_logging.FormatterTest) -- Traceback (most recent call last): File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_logging.py", line 2238, in test_time self.assertEqual(f.formatTime(r), '1993-04-21 08:03:00,123') AssertionError: '1993-04-21 09:03:00,123' != '1993-04-21 08:03:00,123' - 1993-04-21 09:03:00,123 ? ^ + 1993-04-21 08:03:00,123 ? ^ (http://www.python.org/dev/buildbot/all/builders/AMD64%20FreeBSD%208.2%203.x/builds/121/steps/test/logs/stdio) 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
[Python-Dev] Simple XML-RPC server over SSL/TLS
Hi there, I'm working on a project where I'm using Python's simple XML-RPC server [1] on Python 3.x. I need to use it over TLS, which is not possible directly, but it's pretty simple to implement extending few classes of the standard library. But what I would like to know, is if is there any reason why XML-RPC can't optionally work over TLS/SSL using Python's ssl module. I'll create a ticket, and send a patch, but I was wondering if it was a reason why this was not implemented. Cheers, Marc 1. http://docs.python.org/dev/library/xmlrpc.server.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] Allowing import star with namespaces
Ethan Furman wrote: > The strongest reason for not doing this is that it pollutes the current > namespace, not that it obliterates the 'pkg' namespace. Sorry, I phrased that badly. When I said "obliterates the 'pkg' namespace" I was referring to dumping the 'pkg' namespace into the current namespace (polluting it, as you would say). > How would that be different from > --> import pkg Because that does not import all of the (public) modules and packages under 'pkg'. For example scipy has has a subpackage 'linalg'. If I just do 'import scipy' then I can not refer to 'scipy.linalg' until I do 'import scipy.linalg'. Steven D'Aprano wrote: > By the way, this sort of question should probably go to the python-ideas > mailing list for any extended discussion. Sorry, didn't realize that would be the more appropriate list. Thanks, Brendan ___ 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] Issue Tracker
Okay, I finally found a little time and got roundup installed and operating. Only major complaint at this point is that the issue messages are presented in top-post format (argh). Does anyone know off the top of one's head what to change to put roundup in bottom-post (chronological) format? TIA! ~Ethan~ ___ 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-checkins] cpython (3.2): Issue #11919: try to fix test_imp failure on some buildbots.
Le mardi 26 avril 2011 à 10:03 -0400, Jim Jewett a écrit : > This seems to be changing what is tested -- are you saying that > filenames with an included directory name are not intended to be > supported? The test checks the Python parser, not the imp module :-) I don't understand why: sometimes, find_module() accepts a (relative) path, sometimes it doesn't. Victor ___ 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] Issue Tracker
On 26/04/2011 22.32, Ethan Furman wrote: Okay, I finally found a little time and got roundup installed and operating. Only major complaint at this point is that the issue messages are presented in top-post format (argh). Does anyone know off the top of one's head what to change to put roundup in bottom-post (chronological) format? TIA! ~Ethan~ See line 309 of http://svn.python.org/view/tracker/instances/python-dev/html/issue.item.html?view=markup If you have other questions about Roundup see https://lists.sourceforge.net/lists/listinfo/roundup-users Best Regards, Ezio Melotti ___ 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
