[Python-Dev] Python docs about comparisons vs. CPython reality
Hello, Are they bugs in the Python docs or just some CPython implementation details that are purposely not documented? (but then, again, some of the docs seem to be at least not precise...): In https://docs.python.org/3.4/reference/datamodel.html#object.__eq__ there is the statement: > There are no implied relationships among the comparison operators. > The truth of x==y does not imply that x!=y is false. Accordingly, > when defining __eq__(), one should also define __ne__() so that the > operators will behave as expected. On the other hand, in https://docs.python.org/3.4/library/stdtypes.html#comparisons we read: > (in general, __lt__() and __eq__() are sufficient, if you want the > conventional meanings of the comparison operators) And, when I try the __eq__() stuff in CPython it seems that, indeed, the language provides a proper __ne__() implementation for me automatically (without need to implement __ne__() explicitly by myself): Python 3.4.0 (default, Mar 20 2014, 01:28:00) [...] >>> class A: ... def __eq__(self, other): ... if hasattr(self, 'x') and hasattr(other, 'x'): ... return self.x == other.x ... return NotImplemented ... >>> A() == A() False >>> A() != A() True >>> a = A() >>> a.x = 1 >>> a1 = A() >>> a1.x = 1 >>> a2 = A() >>> a2.x = 2 >>> a == a1 True >>> a != a1 False >>> a1 == a1 True >>> a1 != a1 False >>> a1 == a2 False >>> a1 != a2 True Is it a language guarantee (then, I believe, it should be documented) or just an implementation accident? (then, I believe, it still could be documented as a CPython implementation detail). See also the Python equivalent of the SimpleNamespace class (without __ne__() implemented explicitly): https://docs.python.org/3/library/types.html#types.SimpleNamespace On the other hand, the "__lt__() and __eq__() are sufficient" statement seems not to be true: >>> a < a1 False >>> a <= a1 Traceback (most recent call last): File "", line 1, in TypeError: unorderable types: A() <= A() >>> a > a1 False >>> a >= a1 Traceback (most recent call last): File "", line 1, in TypeError: unorderable types: A() >= A() >>> a1 < a2 True >>> a1 <= a2 Traceback (most recent call last): File "", line 1, in TypeError: unorderable types: A() <= A() >>> a1 > a2 False >>> a1 >= a2 Traceback (most recent call last): File "", line 1, in TypeError: unorderable types: A() >= A() On yet another hand, adding __le__() to that class seems to be perfectly sufficient (without adding __gt__() and __ge__()): >>> def le(self, other): ... if hasattr(self, 'x') and hasattr(other, 'x'): ... return self.x <= other.x ... return NotImplemented ... >>> A.__le__ = le >>> a < a1 False >>> a <= a1 True >>> a > a1 False >>> a >= a1 True >>> a1 < a2 True >>> a1 <= a2 True >>> a1 > a2 False >>> a1 >= a2 False What of all this stuff is a language guarantee and what is just an implementation accident? Shouldn't it be documented more accurately? Cheers. *j ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.4): Issue #22295: Adopt 'python -m pip' as the preferred invocation
On Sat, 6 Sep 2014 12:40:19 +0200 (CEST) nick.coghlan wrote: > > The following command will install the latest version of a module and its > dependencies from the Python Package Index:: > > -pip install SomePackage > +python -m pip install SomePackage > + > +.. note:: > + > + For POSIX users (including Mac OS X and Linux users), the examples in > + this guide assume the use of a :term:`virtual environment`. Why not advocate --user instead? It is simpler than messing around with virtual environments and will suffice for most use cases. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.4): Issue #22295: Adopt 'python -m pip' as the preferred invocation
On Sat, Sep 6, 2014 at 7:27 AM, Antoine Pitrou wrote: > Why not advocate --user instead? It is simpler than messing around with > virtual > environments and will suffice for most use cases. I agree, however, --user needs to be more fully integrated into pip's behavior. For example, if I execute pip install --user SomePackage today, when SomePackage is installed someplace outside ~/.local, pip complains that SomePackage is already installed. If I then execute pip install --user --upgrade SomePackage it tries to remove the outdated more global version of SomePackage. Skip ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.4): Issue #22295: Adopt 'python -m pip' as the preferred invocation
> If I then execute > > pip install --user --upgrade SomePackage > > it tries to remove the outdated more global version of SomePackage. BTW, I believe this is a known issue: https://github.com/pypa/pip/issues/1851 https://github.com/pypa/pip/issues/1122 Based on the comment in the second issue, it doesn't appear this will be resolved until 1.7 at the earliest. Skip ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.4): Issue #22295: Adopt 'python -m pip' as the preferred invocation
On 6 September 2014 13:47, Skip Montanaro wrote: > Based on the comment in the second issue, it doesn't appear this will > be resolved until 1.7 at the earliest. The second issue is specific to setuptools, where we have some very unpleasant hacks to deal with the setuptools/distribute mess. Having said that I don't have an immediate feel for what proportion of the issues around --user are fixed in 1.6, as I don't personally use --user much. Paul ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python docs about comparisons vs. CPython reality
On Sat, 06 Sep 2014 13:34:37 +0200, Jan Kaliszewski wrote: > Are they bugs in the Python docs or just some CPython implementation > details that are purposely not documented? (but then, again, some of > the docs seem to be at least not precise...): You might want to read http://bugs.python.org/issue12067 and contribute your thoughts there. There are indeed documentation improvements under discussion. --David ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.4): Issue #22295: Adopt 'python -m pip' as the preferred invocation
On 6 Sep 2014 23:15, "Paul Moore" wrote: > > On 6 September 2014 13:47, Skip Montanaro wrote: > > Based on the comment in the second issue, it doesn't appear this will > > be resolved until 1.7 at the earliest. > > The second issue is specific to setuptools, where we have some very > unpleasant hacks to deal with the setuptools/distribute mess. > > Having said that I don't have an immediate feel for what proportion of > the issues around --user are fixed in 1.6, as I don't personally use > --user much. Using virtual environments also avoids some bad interactions between pkg_resources.requires() and the way Fedora (et al) handle parallel installation of mutually incompatible versions of components that use the same module namespace (e.g. CherryPy 2 vs CherryPy 3) into the system Python. The specific reason for the assumption of virtual environment usage on POSIX is slightly different though: inside a virtual environment created with pyvenv, "python" always refers to Python 3, regardless of platform. Thus, the assumption let me avoid a long-winded explanation of PEP 394 and why the system-wide "python" refers to Python 2 and you need to run "python3 -m pip" to install into Python 3 instead. It was the system level pip vs pip3 distinction that prompted the original change to recommending "-m pip", and I realised explaining the vagaries of python vs python3 would be just as distracting & uninteresting for most users. There's a question at the end of the document about installing into the system Python that could probably be expanded on with more details, but there really are enough ugly edge cases to running custom code in the system Python (at least currently) that the simplest answer is "don't". Cheers, Nick. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
