[issue43828] MappingProxyType accepts string
New submission from Andy Maier :
MappingProxyType objects can currently be initialized from a string object.
Given is purpose, I think this is a bug and should result in TypeError being
raised.
Example code (on CPython 3.9.1):
>>> from types import MappingProxyType
>>> mp = MappingProxyType('abc')
>>> list(mp)
['a', 'b', 'c']
>>> mp.items()
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'str' object has no attribute 'items'
Other invalid input types are properly checked:
>>> mp = MappingProxyType(42)
Traceback (most recent call last):
File "", line 1, in
TypeError: mappingproxy() argument must be a mapping, not int
>>> mp = MappingProxyType(['a'])
Traceback (most recent call last):
File "", line 1, in
TypeError: mappingproxy() argument must be a mapping, not list
>>> mp = MappingProxyType(('a',))
Traceback (most recent call last):
File "", line 1, in
TypeError: mappingproxy() argument must be a mapping, not tuple
--
components: Library (Lib)
messages: 390935
nosy: andymaier
priority: normal
severity: normal
status: open
title: MappingProxyType accepts string
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue43828>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43828] MappingProxyType accepts string
Change by Andy Maier : -- type: -> behavior ___ Python tracker <https://bugs.python.org/issue43828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43829] MappingProxyType cannot hash a hashable underlying mapping
New submission from Andy Maier :
Objects of MappingProxyType do expose a __hash__() method, but if the
underlying mapping is hashable, it still does not support hashing it.
Example:
Content of mp_hash.py:
--
#!/usr/bin/env python
from nocasedict import NocaseDict, HashableMixin
from types import MappingProxyType
class HashableDict(HashableMixin, NocaseDict):
"""A hashable dictionary"""
pass
hd = HashableDict({'a': 1, 'b': 2})
print("hash(hd): {}".format(hash(hd)))
mp = MappingProxyType(hd)
print("hash(mp): {}".format(hash(mp)))
---
Running the mp_hash.py script:
hash(hd): 3709951335832776636
Traceback (most recent call last):
File
"/Users/maiera/Projects/Python/cpython/issues/mappingproxy/./mp_hash.py", line
14, in
print("hash(mp): {}".format(hash(mp)))
TypeError: unhashable type: 'mappingproxy'
There are use cases where a function wants to return an immutable view on an
internal dictionary, and the caller of the function should be able to use the
returned object like a dictionary, except that it is read-only.
Note there is https://bugs.python.org/issue31209 on the inability to pickle
MappingProxyType objects which was closed without adding the capability. That
would fall under the same argument.
--
components: Library (Lib)
messages: 390936
nosy: andymaier
priority: normal
severity: normal
status: open
title: MappingProxyType cannot hash a hashable underlying mapping
type: behavior
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue43829>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43828] MappingProxyType accepts string
Andy Maier added the comment:
I accept that the issue was closed, but wanted to document some things:
1. The dict class manages very well to detect that a string is invalid input:
>>> d = dict('abc')
Traceback (most recent call last):
File "", line 1, in
ValueError: dictionary update sequence element #0 has length 1; 2 is required
2. When initialized with strings, it looses some of its dictionary methods, but
does a quite reasonable job in pointing that out in the error message:
>>> mp = MappingProxyType('abc')
>>> mp.items()
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'str' object has no attribute 'items'
--
___
Python tracker
<https://bugs.python.org/issue43828>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43912] http.client.BadStatusLine raised and response contains request
New submission from Andy Maier : Hello, we have a nasty occurrence of BadStatusLine that shows the status line of the request(!!) in one of our projects. That exception is raised when checking a response and should check the response, not the request. Further debugging revealed that not only the status line is from the request, but also the headers and the body of the response are from the request when this error happens. Example exception when using http.client to send the requests: http.client.BadStatusLine: POST http://localhost:5 HTTP/1.1 I have created a standalone script that can be used to reproduce the behavior. The script can use http.client or the requests package for sending the requests. The server is a threaded HTTP server. The script needs to be run multiple times to reproduce the error. On my local system, the error showed up pretty reliably within the first 50 repetitions of the script. The header comment of the script explains the details. If http.client is chosen to be used, the script is purely based on standard Python library functions. The error shows up on all CPython versions I tried, up to 3.9. -- components: Library (Lib) files: badstatusline.py messages: 391601 nosy: andymaier priority: normal severity: normal status: open title: http.client.BadStatusLine raised and response contains request type: behavior versions: Python 3.9 Added file: https://bugs.python.org/file49971/badstatusline.py ___ Python tracker <https://bugs.python.org/issue43912> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43912] http.client.BadStatusLine raised and response contains request
Andy Maier added the comment: I should have added that my local system is macOS, and that "up to 3.9" means I only tried up to 3.9. -- ___ Python tracker <https://bugs.python.org/issue43912> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38810] SSL connect() raises SSLError "[SSL] EC lib (_ssl.c:728)"
New submission from Andy Maier : A user of our pywbem package gets an SSLError with message "[SSL] EC lib (_ssl.c:728)" when invoking the connect() method on an SSL wrapped socket. See https://github.com/pywbem/pywbem/issues/1950. The issue is that with this error message, it is not possible for us to figure out what the problem is and how to correct it. This happens with CPython 3.5. I have tried to find the place in _ssl.c (https://github.com/python/cpython/blob/3.5/Modules/_ssl.c) where a string "EC lib" or " lib" is created but did not find it there. I have two requests: 1. Please explain what the reason is for this exception and what to change in the environment to make it work. 2. Please improve the message in this exception so that it is self-explanatory. -- assignee: christian.heimes components: SSL messages: 356654 nosy: andymaier, christian.heimes priority: normal severity: normal status: open title: SSL connect() raises SSLError "[SSL] EC lib (_ssl.c:728)" versions: Python 3.5 ___ Python tracker <https://bugs.python.org/issue38810> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38810] SSL connect() raises SSLError "[SSL] EC lib (_ssl.c:728)"
Andy Maier added the comment: More details about the environment this happens on: Python 3.5.7 (default, Aug 16 2019, 10:17:32) [GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux -- ___ Python tracker <https://bugs.python.org/issue38810> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38810] SSL connect() raises SSLError "[SSL] EC lib (_ssl.c:728)"
Andy Maier added the comment: Our user was able to fix this issue by upgrading the OpenSSL version used on the client side from 1.0.1e-fips to 1.1.1. It seems to me that Python's SSL support cannot do anything about this issue. As far as I'm concerned ths issue can be closed. -- ___ Python tracker <https://bugs.python.org/issue38810> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38810] SSL connect() raises SSLError "[SSL] EC lib (_ssl.c:728)"
Andy Maier added the comment: Thanks for the help, Christian! -- ___ Python tracker <https://bugs.python.org/issue38810> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41639] Unpickling derived class of list does not call __init__()
New submission from Andy Maier :
Unpickling an object of a user class that derives from list seems to miss
calling the user class's __init__() method:
Consider this script, which defines a derived class of the built-in list for
the purpose of creating a case insensitive list. The real example has all
methods of list implemented, but this subset example also shows the issue:
-
import pickle
def _lc_list(lst):
result = list()
for value in lst:
result.append(value.lower())
return result
class NocaseList(list):
#def __new__(cls, iterable=()):
#self = super(NocaseList, cls).__new__(cls, iterable)
#print("Debug: __new__() for self={}".format(id(self)))
#return self
def __init__(self, iterable=()):
print("Debug: __init__() for self={}".format(id(self)))
super(NocaseList, self).__init__(iterable)
self.lc_list = _lc_list(self)
def append(self, value):
super(NocaseList, self).append(value)
self.lc_list.append(value.lower())
def extend(self, iterable):
super(NocaseList, self).extend(iterable)
for value in iterable:
self.lc_list.append(value.lower())
ncl = NocaseList(['A', 'b'])
pkl = pickle.dumps(ncl)
nclx = pickle.loads(pkl)
-
$ python ./pickle_extend.py
Debug: __init__() for self=4498704880
Traceback (most recent call last):
File "./pickle_extend.py", line 32, in
nclx = pickle.loads(pkl)
File "./pickle_extend.py", line 28, in extend
self.lc_list.append(value.lower())
AttributeError: 'NocaseList' object has no attribute 'lc_list'
Uncommenting the __new__() method in the script shows that __new__() is called
but not __init__():
$ python ./pickle_extend.py
Debug: __new__() for self=4359683024
Debug: __init__() for self=4359683024
Debug: __new__() for self=4360134304
Traceback (most recent call last):
File "./pickle_extend.py", line 32, in
nclx = pickle.loads(pkl)
File "./pickle_extend.py", line 28, in extend
self.lc_list.append(value.lower())
AttributeError: 'NocaseList' object has no attribute 'lc_list'
--
messages: 375909
nosy: andymaier
priority: normal
severity: normal
status: open
title: Unpickling derived class of list does not call __init__()
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue41639>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41661] os.path.relpath does not document ValueError on Windows with different drives
New submission from Andy Maier :
I found that os.path.relpath() on Windows raises ValueError when the path and
the start path are on different drives. This is to be expected, as there is no
single root on Windows.
On Python 3.7, the behavior is:
>>> os.path.relpath('c:/abc', 'a:/')
Traceback (most recent call last):
File "", line 1, in
File "...\Python\Python37\lib\ntpath.py", line 564, in relpath
path_drive, start_drive))
ValueError: path is on mount 'c:', start on mount 'a:'
The issue is that this ValueError and the reasons for it are not mentioned at
all in the documentation for os.path.relpath(). Other os.path functions do
document specific behaviors for different drives on Windows, for example
os.path.commonpath(), so there is a precedence for documenting this. Also, it
should be normal to document the possible exceptions that can be raised.
I did read https://bugs.python.org/issue7195 from 2009 where the original issue
discussed also lead to a request to update the documentation of
os.path.relpath() to show the ValueError for this case, but that angle of the
issue ended up being ignored back then, unfortunately.
My suggestion is to add something like the following sentence the documentation:
"On Windows, ValueError is raised when path and start are on different drives."
--
assignee: docs@python
components: Documentation
messages: 376057
nosy: andymaier, docs@python
priority: normal
severity: normal
status: open
title: os.path.relpath does not document ValueError on Windows with different
drives
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue41661>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41698] io.[Text]IOBase.seek doesn't take keyword parameter - revisited
New submission from Andy Maier :
I stumbled across the problem reported in https://bugs.python.org/issue25030 on
Python 3.8:
>>> with open('x.txt', 'a') as fp:
... fp.seek(0, whence=os.SEEK_END)
...
Traceback (most recent call last):
File "", line 2, in
TypeError: seek() takes no keyword arguments
Which I coded with a keyword argument because the documentation says so:
seek(offset, whence=SEEK_SET)
See https://docs.python.org/3.8/library/io.html#io.IOBase.seek
The fix for issue issue25030 changed the documentation to:
seek(offset[, whence])
and supposedly was integrated into 2.7, 3.4, and the default branch back then.
It seems the fix got lost?
--
assignee: docs@python
components: Documentation
messages: 376272
nosy: andymaier, docs@python
priority: normal
severity: normal
status: open
title: io.[Text]IOBase.seek doesn't take keyword parameter - revisited
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue41698>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41698] io.[Text]IOBase.seek doesn't take keyword parameter - revisited
Andy Maier added the comment: Thanks for referencing the PR that reintroduced the old way of documenting it. >From my perspective, the proposal is fine. There are already some cases where >it is documented like that, e.g. str.removeprefix(prefix, /). -- ___ Python tracker <https://bugs.python.org/issue41698> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41639] Unpickling derived class of list does not call __init__()
Andy Maier added the comment: Thanks for the clarification. Just for the record: I have implemented __setstate__() such that it completely restores the state from just the inherited list state. That makes it independent of whether __init__() or __new__() is called: def __getstate__(self): state = self.__dict__.copy() del state['_lc_list'] return state def __setstate__(self, state): self.__dict__.update(state) self._lc_list = _lc_list(self) This issue can be closed. -- ___ Python tracker <https://bugs.python.org/issue41639> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41639] Unpickling derived class of list does not call __init__()
Andy Maier added the comment: And just to be complete: That did not require implementing __reduce__(). -- ___ Python tracker <https://bugs.python.org/issue41639> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34434] Removal of kwargs for int() etc not described as change
New submission from Andy Maier : Python 3.7 removed support for passing the argument to the built-in functions int(), bool(), float(), list() and tuple() as a keyword argument. This change is described in the "What's New" for 3.7 (https://docs.python.org/3/whatsnew/3.7.html) in section "API and Feature Removals": Functions bool(), float(), list() and tuple() no longer take keyword arguments. The first argument of int() can now be passed only as positional argument. The issue is that this change is not described in the documentation of these built-in functions. -- messages: 323756 nosy: andymaier priority: normal severity: normal status: open title: Removal of kwargs for int() etc not described as change type: enhancement versions: Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue34434> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21561] help() on enum34 enumeration class creates only a dummy documentation
New submission from Andy Maier:
Using the enum34 backport of enums, the help() function on an enum class Colors
displays only:
---
Help on class Colors in module __main__:
Colors =
---
Source code to reproduce:
---
from enum import Enum # enum34 package
class Colors(Enum):
"""docstring for enumeration Colors"""
RED = 1
GREEN = "2"
BLUE = [3]
help(Colors)
---
Versions used:
python 2.7.6
enum34 1.0
Platform: Windows 7
I debugged the issue, found the place where it breaks down, and made a fix.
However, it may well be that the fix is just a cure to a symptom, and that a
better fix is possible.
Here is the fix:
In pydoc.py, class TextDoc, method docclass():
Change this code on line 1220+:
---
if thisclass is __builtin__.object:
attrs = inherited
continue
elif thisclass is object:
tag = "defined here"
else:
tag = "inherited from %s" % classname(thisclass,
object.__module__)
---
to this, by adding the two lines marked with "added":
---
if thisclass is __builtin__.object:
attrs = inherited
continue
elif thisclass is object:
tag = "defined here"
elif thisclass is None:# <-- added
tag = "inherited from TBD" # <-- added
else:
tag = "inherited from %s" % classname(thisclass,
object.__module__)
---
It breaks down during the last round through the 'while attrs' loop, where
thisclass is None. I did not investigate why thisclass is None.
Without the fix, this causes an AttributeError to be raised by the classname()
function, which then further on causes the dummy documentation to be generated.
With the fix, the help(Colors) output becomes:
---
Help on class Colors in module __main__:
class Colors(enum.Enum)
| docstring for enumeration Colors
|
| Method resolution order:
| Colors
| enum.Enum
| __builtin__.object
|
| Data and other attributes defined here:
|
| BLUE =
|
| GREEN =
|
| RED =
|
| --
| Data and other attributes inherited from TBD:
|
| __members__ = {'BLUE': , 'GREEN': http://bugs.python.org/file35327/bug1.py
___
Python tracker
<http://bugs.python.org/issue21561>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21561] help() on enum34 enumeration class creates only a dummy documentation
Andy Maier added the comment: The pydoc.py of Python 3.4 that supposedly has been fixed has a lot of changes compared to 2.7, but the place where I applied my "fix" in TextDoc.docclass() is unchanged. So it seems that my fix should be regarded only to be a quick fix, and the real fix would be somewhere in the 3.4 pydoc.py. I tried to understand the changes but gave up after a while. My quick fix (with a better text than one that contains "TBD") is still better than not having it fixed, but more ideally the real fix should be rolled back to the 2.7 pydoc.py. Is there anything else I can do to help with this bug? -- ___ Python tracker <http://bugs.python.org/issue21561> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21561] help() on enum34 enumeration class creates only a dummy documentation
Andy Maier added the comment: Using Ethan's sample code (Thanks!!), I was pointed in the right direction and was able to produce a simple piece of code that reproduces the behavior without depending on enum34, as well as a proposal for a fix in pydoc.py. The problem can be reproduced with a class that specifies a metaclass that has class attributes and includes these class attributes in its __dir__() result, which causes them to "propagate" as class attributes to the class using that metaclass, at least for the purposes of pydoc. In the course of the processing within pydoc.py, the tuple returned by inspect.classify_class_attrs() for such class attributes then has None for its class item, which triggers the issue I originally reported (pydoc traps and produces just a dummy help description). In my original problem with the enum34 module, the same thing happens, just here the "propagated" class attributes include the __members__ list, which is defined as a property. So I do believe that my simple code represents the same error situation as the original enum34 issue. Because pydoc.py already has its own classify_class_attrs() function that wrappers inspect.classify_class_attrs() for the purpose of treating data descriptors correctly, I think it would be acceptable to continue down the path of fixing it up, just this case for class attributes propagated by the metaclass. That's what my proposed fix does. Unfortunately, it seems one can attach only one file, so I paste the reproduction code in here, and attach the fixed pydoc.py. Here is the code that reproduces the issue: bug2.py # Boolean test switches that control whether a class variable of the metaclass # is added to the dir() result. # If the fix is not present, then enabling each one triggers the error # behavior; If none of them is enabled, the error behavior is not triggered. with_food = True # Add the 'normal' class attribute 'food' with_drink = True # Add the property-based class attribute 'drink' class FoodMeta(type): """Metaclass that adds its class attributes to dir() of classes using it.""" food = 'ham' # 'normal' class attribute @property def drink(cls): # property-based class attribute return 'beer' def __dir__(cls): ret = [name for name in cls.__dict__] # the normal list if with_food: ret += ['food'] if with_drink: ret += ['drink'] print "bug2.FoodMeta.__dir__(): return=%s" % (repr(ret),) return ret class Food(object): """docstring for Food class""" __metaclass__ = FoodMeta def diet(self): return "no!" if __name__ == '__main__': print "bug2: Calling help(Food):" help(Food) -> Please review the reproduction code and the fix and let me know how to proceed. Andy -- Added file: http://bugs.python.org/file35501/pydoc_fix2.py ___ Python tracker <http://bugs.python.org/issue21561> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21561] help() on enum34 enumeration class creates only a dummy documentation
Andy Maier added the comment: Here is the bug2.py file pasted into the previous message, for convenience. -- Added file: http://bugs.python.org/file35502/bug2.py ___ Python tracker <http://bugs.python.org/issue21561> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21561] help() on enum34 enumeration class creates only a dummy documentation
Andy Maier added the comment: Attaching the patch for pydoc.py, relative to the tip of 2.7. the patch contains just the proposed fix, and no longer the debug prints. -- keywords: +patch Added file: http://bugs.python.org/file35673/pydoc.py.patch ___ Python tracker <http://bugs.python.org/issue21561> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21561] help() on enum34 enumeration class creates only a dummy documentation
Andy Maier added the comment: Attaching the patch for Lib/test/test_pydoc.py, relative to the tip of 2.7. The patch adds a testcase test_class_with_metaclass(), which defines a class that provokes the buggy behavior, and verifies the fix. -- Added file: http://bugs.python.org/file35674/test_pydoc.py.patch ___ Python tracker <http://bugs.python.org/issue21561> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17904] bytes should be listed as built-in function for 2.7
Andy Maier added the comment: Ezio, what do you mean with "string signature"? For me, the patch looks fine as it is. -- nosy: +andymaier ___ Python tracker <http://bugs.python.org/issue17904> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21898] .hgignore: Missing ignores for Eclipse/pydev
New submission from Andy Maier: The .hgignore file misses some entries for directories and files created by Eclipse with pydev. The additional lines for .hgignore would be: ^.project ^.pydevproject ^.settings/ This change applies to 2.7 and 3.x. -- messages: 222032 nosy: andymaier priority: normal severity: normal status: open title: .hgignore: Missing ignores for Eclipse/pydev type: enhancement versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker <http://bugs.python.org/issue21898> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21898] .hgignore: Missing ignores for Eclipse/pydev
Changes by Andy Maier : -- keywords: +patch Added file: http://bugs.python.org/file35817/issue21898.diff ___ Python tracker <http://bugs.python.org/issue21898> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21900] .hgignore: Missing ignores for downloaded doc build tools
New submission from Andy Maier: In Python 2.7 and up to Python 3.3, the documentation build process downloads tools such as Sphinx etc. into the Doc/tools subtree. The .hgignore file misses entries to ignore those. The additional lines for .hgignore would be: ^Doc/tools/docutils/ ^Doc/tools/jinja2/ ^Doc/tools/pygments/ ^Doc/tools/sphinx/ This change applies to 2.7 only (assuming 3.1-3.3 are no longer patched). -- messages: 222041 nosy: andymaier priority: normal severity: normal status: open title: .hgignore: Missing ignores for downloaded doc build tools versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue21900> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21900] .hgignore: Missing ignores for downloaded doc build tools
Changes by Andy Maier : -- keywords: +patch Added file: http://bugs.python.org/file35818/issue21900.diff ___ Python tracker <http://bugs.python.org/issue21900> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17904] bytes should be listed as built-in function for 2.7
Andy Maier added the comment: Your patch right now generates the line: New in version 2.6: bytes() has been added as an alias for str() at the end of the paragraph for str(). To me, that is sufficient for the description of str(). If anything, we could add a separate paragraph for bytes(), after the paragraph for bytearray(), e.g. like this: -- .. function:: bytes() Alias for :func:`str`. .. versionadded:: 2.6 -- If that is what you had in mind, I think it is a good idea to add it. Andy -- ___ Python tracker <http://bugs.python.org/issue17904> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14097] Improve the "introduction" page of the tutorial
Andy Maier added the comment:
Zach, I reviewed your 2.7 backport, including a comparison with the latest 3.x
patch.
Comments on the 2.7 backport:
1. In "3.1.1 Numbers", on "If both operands are ints,":
The "ints" is a link labeled "int" followed by a normal font "s". I think it
would be better to avoid concatenating them, and to say something like: "If
both operands are of type int,".
Comments on both the 2.7 backport and on the latest 3.x patch:
2. In the last paragraph of "3.1.1 Numbers" ("In addition to int and float,
Python supports..:":
The long type could be mentioned here as well, only with a link and no
explanation, consistent with how Decimal and Fraction are mentioned.
Comments on just the latest 3.x patch:
3. In "3.1.2. Strings", I am missing a mentioning that the characters in
strings are Unicode characters. I think quite a bit of the unicode subclause of
the 2.x patch would be appropriate. I would also mention byte strings at this
point, but only the fact that they exist and with a link.
--
nosy: +andymaier
___
Python tracker
<http://bugs.python.org/issue14097>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21900] .hgignore: Missing ignores for downloaded doc build tools
Andy Maier added the comment: That is indeed true; i just verified that by creating a new clone repository. Sorry for the extra work. When I created the bug yesterday, I had my repository clone updated to "2.7" and the .hgignore definitely did not have the entries. I even saw all the downloaded doc tools in the status window of my hg client (which is what caused me to attempt to fix this in the first place). I did do a commit to my local repository clone but did not push that (I would not have the rights anyway). If anyone has an explanation on whyt I saw, I'd be grateful. Andy -- ___ Python tracker <http://bugs.python.org/issue21900> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21900] .hgignore: Missing ignores for downloaded doc build tools
Andy Maier added the comment: > Regardless, though, you are having a Mercurial issue here, not a Python one :) That seems to be the case ... I don't think I can reproduce it. All fine then. Thanks, David! -- ___ Python tracker <http://bugs.python.org/issue21900> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14097] Improve the "introduction" page of the tutorial
Andy Maier added the comment: > Andy: in future, please use the 'review' link to post reviews,... Will do ... I just now discovered the "Start Review" link (I'm new here, so thanks for telling me...) Andy -- ___ Python tracker <http://bugs.python.org/issue14097> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10031] Withdraw anti-recommendation of relative imports from documentation
Andy Maier added the comment:
Hi, I would like to revive this issue, and have a few comments:
1. In Darren's original proposal, I suggest to say "implicit (old-style)
relative imports" instead of "old-style relative imports", because that is the
term used in the Python Tutorial (the description of the ´import´ statement in
2.7 does not mention implicit relative imports at all).
2. It seems to me that David's suggestion is already reflected in the original
proposal. Or maybe I don't understand it right...
3. I agree with Éric's comment that implicit relative imports should still be
explained. However, I'm not sure that needs to be done in the FAQ. After all,
the FAQ does not explain absolute or explicit relative imports either, and
spending more words on the discouraged approach than on the recommended
approaches does not seem appropriate to me.
4. I have to say that I'm generally unhappy if I see PEPs mentioned as a
specification ("See PEP 328 for details"). I have sympathy for referencing PEPs
as background information and for the rationales they usually contain. Could we
reference the description of the ´import´ statement for details, instead of
referencing the PEP (in both FAQs)?
Andy
--
nosy: +andymaier
___
Python tracker
<http://bugs.python.org/issue10031>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10225] Fix doctest runable examples in python manual
Andy Maier added the comment: Hi, I would like to revive this issue and have added a review comment to issue10225-py3k.diff. Otherwise, I have reviewed the changes in both diffs and think they are good to go. Andy -- nosy: +andymaier ___ Python tracker <http://bugs.python.org/issue10225> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10536] Enhancements to gettext docs
Andy Maier added the comment: Éric, I have reviewed the patch, and have one minor comment on it (see review page). Otherwise, I think it is good to go into v3 (The version list for this issue also shows 2.7, and the 2.7 version of this file is quite different from the v3 tip version, so a backport is still needed). Barry's review I think is also still needed :-) My 2 cents on your questions to Barry: On 3): I like your proposal. On a): Can you be more specific on where it is POSIX specific, and what the issue is with that? On b): After understanding that your comment is about the v3 version, I agree with the comment in general. However, the set of functions changes between 2.7 and 3.x tip (for example, ugettext() from v2 is no longer in v3 because gettext() now returns Unicode strings), and if people try to understand what changed, I think it would be helpful to be more explicit, particularly because the v2 text is also explicit. So I would leave the "Unicode string" verbiage unchanged. But I don't have a strong opinion on this and can go either way. Andy -- nosy: +andymaier ___ Python tracker <http://bugs.python.org/issue10536> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14050] Tutorial, list.sort() and items comparability
Andy Maier added the comment: Just out of curiosity: Why do the patches attached to this issue not have a "review" link? Also, both (2.7 and 3.2) patches do not line up with the current 2.7 and 3.x tip, both hunks get rejected. Comments on both patches: 1. It would be helpful if the text "Each item needs to define an ordering relationship." was followed by a statement about what happens when that is not the case (that is what Ezio also suggested), and where to look for details on how to define an ordering relationship. The problem with that is that there is no good place that is devoted to exactly that. The relatively best place for defining comparison I found so far is: https://docs.python.org/2.7/tutorial/datastructures.html#comparing-sequences-and-other-types and its 3.x equivalent. 2. The example that raises the TypeError is not needed, IMHO. This puts too much focus on the case that does not work. If we mention in the description that a TypeError is raised, that should be sufficient. Andy -- nosy: +andymaier ___ Python tracker <http://bugs.python.org/issue14050> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
Andy Maier added the comment:
Hi, I'd like to revive this issue.
IMHO, the changes in issue12067-expressions_v2.diff go too far. I don't think
that deleting the entire section about the details of comparing objects of the
same type makes sense.
I agree with Terry's statement in msg170936 that the chapter is about the
operators and not about the ways to customize them, so some of what the patch
introduces in that area should not be introduced.
So far, that means that I'm pretty much against that patch entirely...
Having said that, I do believe that there are still issues:
1. both the 2.7 and 3.x sections about the comparison operators are
sufficiently convoluted and could be organized better by grouping the various
statements that are made, into categories like this:
- comparisons involving objects of user-defined types
- comparing objects of same built-in type
- comparing objects of differing built-in type
2. There are still some errors, ambiguities and omissions that need to be
fixed. For example, in the 3.x version:
a) omission about treatment of NaN for numbers of different type (could in
theory be implied from the statement "are converted to same type", but that
statement is problematic as was pointed out in Mark's comment on this issue).
b) Amgiguous statement "Most numeric types [of same type] can be compared with
one another.". I think what is true is that all built-in numeric types
(including Fraction and Decimal) compare mathematically correct in 3.x, and
that the only non-support is that complex numbers are not considered orderable
and an attempt to use an ordering operator raises TypeError.
c) Ambiguous statement "When cross-type comparison is not supported, the
comparison method returns NotImplemented.". If this is about the customization
methods, it should not be here, but there. Here, it is relevant that a
TypeError is raised when using the operator.
d) Terminology in "Bytes objects are compared lexicographically using the
numeric values of their elements.": Chapter [4.8.1. Bytes] defines bytes
objects as immutable sequences of single bytes (not elements).
e) Terminology in "Tuples and lists are compared lexicographically using
comparison of corresponding elements.": lists and tuples contain "items" not
"elements", and an item-wise comparison should not be called
"lexicographically" because that makes sense only when the items are characters.
f) Ambiguity in "If not equal, the sequences are ordered the same as their
first differing elements.": "Are ordered" could be interpreted (e.g. by
non-native speakers) to mean that the sequence is changed to achieve that
ordering, which is not the case of course.
g) Editorial: In the list item about sets and froze sets, the example set {2,3}
is not in example font.
h) Omission: Range types are not covered.
i) Omission: The section "Comparison of objects of differing types..." is
silent about which built-in types support comparison across types (except for
numeric types where that is covered). I think that should be explicitly listed
for those built-in types that are also listed explicitly in the section about
comparing objects of same type.
I'll try to come up with a patch for 3.x, and once that is agreed, with one for
2.x.
Andy
--
nosy: +andymaier
___
Python tracker
<http://bugs.python.org/issue12067>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14050] Tutorial, list.sort() and items comparability
Andy Maier added the comment: Ah! I was somehow suspecting that. Thanks for clarifying! I'll prepare a patch. To correct my earlier message, the best place to link for comparisons is probably the Conparisons subchapter of the Expressions chapter in the reference. See also issue12067. -- ___ Python tracker <http://bugs.python.org/issue14050> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
Changes by Andy Maier : -- versions: +Python 3.5 -Python 3.2, Python 3.3 Added file: http://bugs.python.org/file35843/issue12067-expressions_v3.diff ___ Python tracker <http://bugs.python.org/issue12067> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
Andy Maier added the comment: Uploaded issue12067-expressions_v3.diff for the 3.5 tip. Please review. -- ___ Python tracker <http://bugs.python.org/issue12067> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
Andy Maier added the comment: Uploaded issue12067-expressions_v4.diff to improve the unicode footnote 3, and to revert to using the term "lexicographical" for sequences (after learning that it applies there as well). Also, this version was produced using "hg diff" to make it properly reviewable. Please review. -- Added file: http://bugs.python.org/file35845/issue12067-expressions_v4.diff ___ Python tracker <http://bugs.python.org/issue12067> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
Andy Maier added the comment: PS: The v4 patch does not address comments f) and h) from msg04, and it seems to me they do not need to be addressed. -- ___ Python tracker <http://bugs.python.org/issue12067> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
Andy Maier added the comment: Terry, I'd like to comment on your statement: > 3. By default, == and /= compare identities. in msg148774. What experiment lead you to that conclusion? Here is one that contradicts it (using cpython 3.4.1): >>> i1 = 42 >>> f1 = 42.0 >>> i1 == f1 True >>> i1 is f1 False Is it possible, that your experiment got influenced by the optimization that attempts to reuse existing objects of immutable types? Like in this: >>> i1 = 42 >>> i2 = 40 + 2 >>> i1 == i2 True >>> i1 is i2 True Andy -- ___ Python tracker <http://bugs.python.org/issue12067> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
Andy Maier added the comment: Uploaded v5 of the patch. Changes: 1. The statement that comparison of different built-in types (always) raises TypeError, was too general. Changed to distinguish equal and order operators, as summarized by Ezio in items 3) and 4) of msg148760. 2. Ensured max line length of 80, in text areas affected by the patch. Andy -- versions: +Python 3.4 Added file: http://bugs.python.org/file35850/issue12067-expressions-py34_v5.diff ___ Python tracker <http://bugs.python.org/issue12067> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
Andy Maier added the comment: It seems I still need to practice creating patches ... uploading v6 which should create a review link. No other changes. Sorry for that. Andy -- Added file: http://bugs.python.org/file35851/issue12067-expressions-py34_v6.diff ___ Python tracker <http://bugs.python.org/issue12067> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
Andy Maier added the comment: Another attempt. Really sorry... -- Added file: http://bugs.python.org/file35853/issue12067-expressions-py34_v7.diff ___ Python tracker <http://bugs.python.org/issue12067> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14050] Tutorial, list.sort() and items comparability
Andy Maier added the comment: Uploaded patch version py34_v2, which contains the following changes relative to 3.4: 1. The changes in the description of list.sort() from "default" in list.sort(), by adding this text: (the arguments can be used for sort customization, see :func:`sorted` for their explanation) 2. The proposed extension of the description of list.sort() from patch version py32. 3. A statement that TypeError is raised if the ordering relationship is not established. 4. A reference where to look in order to establish ordering relationship for user-defined classes. (referencing the Basic customization section of the Language Reference). 5. A reference where the ordering relationships for built-in types are described (referencing the Comparison chapter of the Language Reference). -> Please review. Andy -- Added file: http://bugs.python.org/file35854/issue14050-list_sort-py34_v2.diff ___ Python tracker <http://bugs.python.org/issue14050> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14050] Tutorial, list.sort() and items comparability
Andy Maier added the comment: uploaded patch version py27_v2, which contains the same changes as py34_v2, relative to 2.7, except for this differences: 1. The change from "default" was already in 2.7. 2. The reference to defining ordering methods for user-defined classes includes a reference to object.__cmp__(), in addition. -> Please review Andy -- Added file: http://bugs.python.org/file35855/issue14050-list_sort-py27_v2.diff ___ Python tracker <http://bugs.python.org/issue14050> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6953] readline documenation needs work
Andy Maier added the comment: I would like to revive this issue. >From the discussion, it seems to me that the following changes in the Python >Library documentation would make sense: 1. Move add_history() higher up in the sequence of functions, for example to after write_history_file(). 2. Clarify that the pos arguments of remove_history_item() and replace_history_item() are 0-based. 3. Clarify that the index argument of get_history_item() is 1-based. I do understand Stefan's comment from msg100757 that it is actually 'history_base'-based. On the one hand, history_base is not exposed or implied or even described at the Python level. After searching the GNU readline documentation, it seems that a notion of history base is not described there, either (I may have missed it, though). So either we simply state it is 1-based, or we provide in addition the background story mentioning some notion of history_base that is publicly described. I have the following additional comments: 4. The current documentation is very abridged, probably because it intends to be "just" a description of the Python binding to GNU readline. I think it either needs to evolve into a standalone description (i.e. that does not depend on the description of GNU readline), or it needs to properly reference the description of GNU readline. If we go that route, a simple reference to the document is not sufficient, for one because it is not the only underlying implementation, and second, because it is large and not easy at all to map to the Python readline functions. 5. One needs to understand what the main entities are the module operates on, e.g. init file, history file(s), a (single, global?) history object, the line buffer. Regardless of what we do regarding comment 4., I think the Python docs should describe these main entities in the introduction text. 6. Some more information about the init file is needed. I suspect it is specific to the underlying implementation that is used. If so, add references to the format descriptions for each implementation (by Python OS platform). 7. parse_and_bind(): Change the description to state that it parses and binds the init statement provided in the string argument. That string may or may not come from an init file. The example at the end specifies a statement that is not from an init file. 8. get_line_buffer() talks about "line buffer" and insert_text() talks about "command line". I suspect that means to be the same. If so, use one term consistently. 9. read_init_file(): I suspect it returns a tuple of statements from the init file? In any case, describe how the init file content comes back. Are comments removed? Where is the last filename used remembered, does that survive restarts of the Python runtime? 10. read_history_file(): Add that the history file content is put into a (global?) history object, replacing its prior history. 11. write_history_file(): Add that the (global?) history object is where the information comes from. Is an existing history file replaced? Appended? Exception raised? 12. clear_history(): From the text, I read that if the underlying GNU readline does not support it, this Python function does not exist in the module. If this is not how it works (e.g. if the function exists and raises an exception in the unsupported case), that text should be clarified. Also, mention which version of GNU readline is minimally needed in order to support the function. 13. get_history_length(): It says "get the desired length of the history file", but I think it is really the desired number of lines in the history file (i.e. consistent with set_history_length(). 14. get_history_item() and remove_history_item() talk about "history item", while all other functions talk about "history line" or "line". Use one term consistently. 15. the completion related functions (from set_completer() to set_completion_display_matches_hook()) are really somewhat short: What is the role of a completer function? Which completion types are defined? What is the beginning index of tab-completion? What are word delimiters for tab-completion? 16. Last but not least, the libedit library is mentioned for MacOS. Has that been implemented yet, and is it part of standard Python? If so, mention that. Andy -- nosy: +andymaier versions: +Python 3.4, Python 3.5 -Python 3.2 ___ Python tracker <http://bugs.python.org/issue6953> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10289] Document magic methods called by built-in functions
Andy Maier added the comment: I have reviewed the descriptions of the built-in functions in Python 3.4, and found only the following issues w.r.t. missing __special__functions: 1. getattr(), setattr(), delattr(): They only refer to object attributes and miss to mention the fallback to object.__getattr__(), etc. Because hasattr() calls getattr() to test for the presence, the __getattr__() is relevant for hasattr() as well. 2. len() misses to describe that it uses s.__len__(). 3. sorted() misses to describe how rich comparison methods can be used. I think we can integrate the changes to list.sort() proposed in issue14050. 4. str() delegates the description to stdtypes.html#str, which in turn does describe obj.__str__(). Not sure we need to do something for str(). I did not check 2.7 yet. Andy -- nosy: +andymaier versions: +Python 3.4, Python 3.5 -Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue10289> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
Andy Maier added the comment:
I see.
But I don't think it is a sensible default, as the source code states.
The Python doc (v2 and v3) is quite consistent in stating that `==` compares
the values of two objects, while `is` compares object identity.
Having a default implementation on the object type that implements `==` by
comparing object identity is not consistent with that.
-> Can someone please elaborate what the reason for that is?
-> Where is the discrepancy between the documentation of == and its default
implementation on object documented?
To me, a sensible default implementation for == on object would be (in Python):
if v is w:
return True;
elif type(v) != type(w):
return False
else:
raise ValueError("Equality cannot be determined in default implementation")
Andy
--
___
Python tracker
<http://bugs.python.org/issue12067>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10289] Document magic methods called by built-in functions
Andy Maier added the comment: Uploaded a patch for Python 3.4, and for merging into "default". The patch addresses items 1) to 3) from my previous post; item 4) does not need to be addressed IMHO. Andy -- keywords: +patch Added file: http://bugs.python.org/file35879/issue10289-magic-py34_v1.diff ___ Python tracker <http://bugs.python.org/issue10289> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10289] Document magic methods called by built-in functions
Andy Maier added the comment: Uploaded v2 of the 3.4/default patch, which removes the comment line at the top of Doc/library/functions.rst (mentioned by Éric in the original message of this issue). -> Please review the patch. -> Please also double check whether there are any additional built-in functions in 3.x that have a need to document their underlying __special__ functions. Andy -- Added file: http://bugs.python.org/file35881/issue10289-magic-py34_v2.diff ___ Python tracker <http://bugs.python.org/issue10289> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14050] Tutorial, list.sort() and items comparability
Andy Maier added the comment: Comments on v2 of both patches: 1. The paragraph "Each item needs to ..." describes the requirement in terms of "ordering relationships between items". It would be both simpler and less ambiguous to describe the requirement in terms of "type must be orderable". See the text added to sorted() as part of the patch for issue10289, for details. -- ___ Python tracker <http://bugs.python.org/issue14050> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10289] Document magic methods called by built-in functions
Andy Maier added the comment: Comments on the patch py34_v2: 1. On complex(): It delegates to object.__complex__(); that should also be described. 2. On hex(): The use of "__index__()" is text and should be changed to a hyperlink. Andy -- ___ Python tracker <http://bugs.python.org/issue10289> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10289] Document magic methods called by built-in functions
Andy Maier added the comment: I reviewed the description of the built-in functions in Python 2.7, and found these issues: 1. The following built-in functions do not mention their underyling __special__ functions: - cmp() - delattr(), getattr(), hasattr(), setattr() - complex(), int(), long(), float() - hash() - len() - str() - int(), oct() 2. The following built-in functions list the __special__ functions they invoke as text that is not a hyperlink: - dir() - format() - hex() 3. The following built-in functions could be improved from the description of the 3.x version: - bool(): References and links from 3.x version could be added. - bytearray(): References from last line of 3.x version could be added. - callable(): Wording "if they have a..." could be improved by using 3.x wording. 4. The codepage of the ASCII string for chr() is not documented. Andy -- ___ Python tracker <http://bugs.python.org/issue10289> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
Changes by Andy Maier : -- nosy: +benjamin.peterson, steven.daprano ___ Python tracker <http://bugs.python.org/issue12067> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
Changes by Andy Maier : -- nosy: +ethan.furman ___ Python tracker <http://bugs.python.org/issue12067> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
Andy Maier added the comment: Uploaded v8 of the patch for 3.4 and default. It reflects hopefully everything that was said in this issue thread, and on the python-dev mailing list (subject: == on object tests identity in 3.x), at least to the extent it was related to comparisons. Besides the doc changes it contained previously, it now also contains improvements for the test suite for comparisons (lib/test/test_compare.py). -> Please review both. Andy -- Added file: http://bugs.python.org/file35924/issue12067-expressions-py34_v8.diff ___ Python tracker <http://bugs.python.org/issue12067> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
Changes by Andy Maier : Added file: http://bugs.python.org/file35938/try_eq.py ___ Python tracker <http://bugs.python.org/issue12067> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
Changes by Andy Maier : Added file: http://bugs.python.org/file35939/try_eq.out ___ Python tracker <http://bugs.python.org/issue12067> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
Andy Maier added the comment: Mark: Both are good points! Would you add the cases from your second comment under "symmetry"? -- ___ Python tracker <http://bugs.python.org/issue12067> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
Andy Maier added the comment: Uploaded v9 of the patch for 3.4 and default. It reflects Marc's comment, plus the result of the recent discussion on python-dev since v8 of th epatch, up to 2014-07-15 (subject: == on object tests identity in 3.x). -> Please review the patch. -- Added file: http://bugs.python.org/file35971/issue12067-expressions-py34_v9.diff ___ Python tracker <http://bugs.python.org/issue12067> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11945] Adopt and document consistent semantics for handling NaN values in containers
Changes by Andy Maier : -- nosy: +andymaier ___ Python tracker <http://bugs.python.org/issue11945> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
Andy Maier added the comment: Just wanted to say that i will continue working on this, working in the comments made so far... Andy -- ___ Python tracker <http://bugs.python.org/issue12067> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
Andy Maier added the comment: @Guido: Agree to all you said in your #msg226496. There is additional information about comparison in: - Tutorial (5.8. Comparing Sequences and Other Types), - Library Reference (5.3. Comparisons), - Language Reference (3.3.1. Basic customization) that needs to be reviewed in light of this patch. I'm just not sure I want to make this patch even larger as it is already, and tend to do that in a follow on issue and patch (unless directed otherwise). Andy -- ___ Python tracker <http://bugs.python.org/issue12067> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22001] containers "same" does not always mean "__eq__".
Andy Maier added the comment: I reviewed the issues discussed here and believe that the patch for #Issue 12067 adresses all of them (and yes, it is large, unfortunately). It became large because I think that more needed to be fixed. May I suggest to review that patch. Andy -- nosy: +andymaier ___ Python tracker <http://bugs.python.org/issue22001> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
Andy Maier added the comment: Uploading v10 of the patch, which addresses all review comments made on v9. There is one open question back to Martin Panter about which different types of byte sequences can be compared in Py 3.4. I also believe this patch addresses all of Issue 22001. Let me know if you find that that is not the case. If we continue to scope this patch to only the comparison chapter of the language reference, then I think we are done (see msg229229 about other places that need review and possibly updates). Please review the patch v10. -- Added file: http://bugs.python.org/file36896/issue12067-expressions-py34_v10.diff ___ Python tracker <http://bugs.python.org/issue12067> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
Andy Maier added the comment: Here is the delta between v9 and v10 of the patch, if people want to see just that. -- Added file: http://bugs.python.org/file36897/issue12067-expressions-py34_delta-v9-v10.diff ___ Python tracker <http://bugs.python.org/issue12067> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
Andy Maier added the comment: I have addressed the comments by Jim Jewett, Martin Panter and of myself in a new version v11, which got posted. For the expression.rst doc file, this version of the patch has its diff sections in a logical order, so that the original text and the patched text are close by each other. Please review. -- Added file: http://bugs.python.org/file36920/issue12067-expressions-py34_v11.diff ___ Python tracker <http://bugs.python.org/issue12067> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
Andy Maier added the comment: I also made sure in both files that the line length of any changed or new lines is max 80. Sorry if that creates extra changes when looking at deltas between change sets. -- ___ Python tracker <http://bugs.python.org/issue12067> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
Andy Maier added the comment: I have posted v12 of the patch, which addresses all comments since v11. This Python 3.4 patch can be applied to the "default" (3.5 dev) branch as well. I will start working on a similar patch for Python 2.7 now. -- Added file: http://bugs.python.org/file36978/issue12067-expressions-py34_v12.diff ___ Python tracker <http://bugs.python.org/issue12067> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions
Andy Maier added the comment: Nir, I appreciate very much what you are doing. I was about to do the same ;-) I'll review your code shortly. I like the idea to use /etc/os-release, as it has the most complete information. Stay tuned. Andy Am 6. Dezember 2015 18:12:52 MEZ, schrieb Nir Cohen : > >Nir Cohen added the comment: > >I have a premliminary implementation of it: https://github.com/nir0s/ld > >Would love some help. It tries to use adhere to the standards >(os-release first, lsb-release later, then, distro-specific release >files). > >It also returns more types of values then there were before. > >-- >nosy: +nir0s > >___ >Python tracker ><http://bugs.python.org/issue1322> >___ -- ___ Python tracker <http://bugs.python.org/issue1322> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26678] Incorrect linking to elements in datetime package
New submission from Andy Maier: Hi, I did search for these in the open bugs, but did not find any matching bug. I have a project that revealed that some of its InterSphinx links to existing classes/types or methods to not resolve their targets, or to resolve to a target that is not the right one (IMO). This issue here describes everything I found in the datetime package. Line numbers in this issue apply to the datetime.rst file as of commit 96a98bcaac70 (https://hg.python.org/cpython/file/96a98bcaac70/Doc/library/datetime.rst). * class datetime.tzinfo: An intersphinx link to it gets resolved but targets the short description of the class in the intro (line 106 of datetime.rst), and I did not find a way to target the full description (line 1552), which is really what this should be resolved to (IMO). I suspect that this has to do with the fact that this class has only one anchor on its short description on line 106, while companion classes such as datetime.datetime have two anchors (lines 91 and 681) where the last one wins (and happens to be the long description). However, see the next item. * class datetime.timezone: Same issue as for class datetime.tzinfo; links get resolved but land on the short intro. However, this time there are two anchors (lines 113 and 1795). So maybe my suspicion above is rather speculation... * method datetime.tzinfo.utcoffset: An intersphinx link to it does not get resolved. On line 1579 in datetime.rst, there is a `.. method:: tzinfo.utcoffset(dt)` but at least these intersphinx links did not get resolved: :func:`py:tzinfo.utcoffset` :func:`py:datetime.tzinfo.utcoffset` Do method anchors need the anchor for their defining class close by to work? Which because if the first issue above, would be the short version of it, way above. (Again speculation) * Same for method datetime.tzinfo.dst -- assignee: docs@python components: Documentation messages: 262698 nosy: andymaier, docs@python priority: normal severity: normal status: open title: Incorrect linking to elements in datetime package type: enhancement versions: Python 3.6 ___ Python tracker <http://bugs.python.org/issue26678> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26678] Incorrect linking to elements in datetime package
Andy Maier added the comment: Hi Martin! The intersphinx stuff is simply linking from a Sphinx RST documentation to a different Sphinx RST documentation, using support from the intersphinx extension of Sphinx. I think the name comes from the interwiki links in MediaWiki. It only comes into play here because my particular documentation is outside of the Python documentation. The same issues would arise when linking from other places in the Python documentation. Your explanation about :noindex: hits the nail on the head, I think. It seems to me that a minimal variant for fixing this would be: * add :noindex: to the class markup for the short descriptions of tzinfo and timezone. * add a class markup for tzinfo at its long description. I don't know whether that solves the method linking issue, though, but its worth a try. -- ___ Python tracker <http://bugs.python.org/issue26678> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26678] Incorrect linking to elements in datetime package
Andy Maier added the comment: Ok. If these methods generate index entries, maybe the problem is on my side by not linking them correctly. So let's try with the other two changes. Unfortunately, I cannot easily build cpython at the moment to verify, I moved to Linux and when trying to build cpython, bash rejects the configure script because of trailing CR characters. This is a freshly installed hg package on Ubuntu 14.04, against a fresh clone of the cpython repo. Any idea what is happening there? -- ___ Python tracker <http://bugs.python.org/issue26678> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26678] Incorrect linking to elements in datetime package
Andy Maier added the comment: Martin, I can now link to the two methods e.g. via :meth:`py:datetime.tzinfo.utcoffset`, and it resolves nicely. See here (linking to Python 2): https://pywbem.readthedocs.org/en/latest/#pywbem.MinutesFromUTC Don't know why it now works, probably user error I would say. Your change is still appreciated, and it would be great if it could also go into Python 2.7 :-) Hope I'm not asking for too much. On Python build: hg config problem sounds like a good path. Thanks! -- ___ Python tracker <http://bugs.python.org/issue26678> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26678] Incorrect linking to elements in datetime package
Andy Maier added the comment: Martin, I just noticed that your fix must already be active. My link to tzinfo now lands on the long description. So maybe it was not a user error of mine that resolved the problem with the two methods (I was pretty sure I had tried the same syntax I use now), but whatever did the trick in your change. Anyway, thanks much for this quick turnaround!! Andy -- ___ Python tracker <http://bugs.python.org/issue26678> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions
Andy Maier added the comment: Nir currently proposes to change the package name from "ld" to "dist". See https://github.com/nir0s/ld/issues/103 Comments on this name change proposal are welcome (over there). On "Given the unremarkable simplicity of implementing this function correctly ...": It seems to me that this is over-simplifying the task somewhat. Nir's "ld" package needs to understand all of the (currently) three different formats on Linux, and goes for a precedence-based approach to consolidate the information. Also, determining supposedly simple things like a reliable distro ID, or a precise distro version is not trivial, given that some Linux distros provide their data quite inconsistently between the different data sources and sometimes change things like distro ID incompatibly in a new minor release. Overall, I can only encourage people to try out the "ld" package (v0.5.0 is currently on PyPI) and give feedback (on its GitHub project). Does the deprecation and removal of these functions discriminate Linux compared to Windows and OS-X? Maybe, but I'm pragmatic here, and for me the important criteria is the one that was stated from the beginning in this discussion: The higher change rate in Linux fits quite well with the approach of having a separate package that is not part of the standard Python. Does that mean that less batteries are now included in Python out of the box: Yes, a very small part of the batteries is now no longer included. But maybe one day when the "ld" package is perfect and does not require a high change rate anymore, it gets added to standard Python. Also, there are many packages the average Python project needs these days that are no longer coming with standard Python (six, setuptools, pbr, better unit testers, lxml, M2Crypto, Sphinx, lxml, ). If you look at the long backlog of pull requests and open issues in standard Python, it is a good thing actually, not to overload the community maintaining the standard Python even further. But that is a bit off-topic for this issue, I am just mentioning it in order to beg for acceptance for the approach taken for linux distro information. -- ___ Python tracker <http://bugs.python.org/issue1322> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions
Andy Maier added the comment: @leycec: By the way, the "ld" package *does* use shlex.shlex() to parse the os-release file. -- ___ Python tracker <http://bugs.python.org/issue1322> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions
Andy Maier added the comment: Just for completeness: The "ld" package is now called "distro" and its v0.6.0 is on PyPI: https://pypi.python.org/pypi/distro -- ___ Python tracker <http://bugs.python.org/issue1322> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions
Changes by Andy Maier : -- nosy: +andymaier ___ Python tracker <http://bugs.python.org/issue1322> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions
Andy Maier added the comment: Do we really think that a package on pypi solves the problem better? The discussion only shows that it is more likely we end up with multiple different packages on pypi, instead of one that is commonly agreed. I agree it is tough to get to an agreed upon approach, but having this in the Python base at least ensures that it is the one approach everybody uses. The /etc/os-release format seems to be used more often now, so I'm wondering why we cannot come up with a reasonable approach that is backwards compatible, supports /etc/os-release, and (if still needed), also /etc/lsb-release and the lsb_release script. Again: If we ever want to end up with just one package on pypi, that very discussion needs to happen. It seems to me that if the approach should be compatible, then we cannot use the new generic files (lsb* and os-release) first. The currently implemented approach needs to be used first. Then the new generic files. -- ___ Python tracker <http://bugs.python.org/issue1322> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
Changes by Andy Maier : Added file: http://bugs.python.org/file38303/issue12067-expressions-py3.5_v14.diff ___ Python tracker <http://bugs.python.org/issue12067> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
Andy Maier added the comment: I have posted v14 of the patch (for the 3.5 'default' branch), based on Martin's v13. v14 addresses all comments Martin made, as described in my responses to them (see patch set 10). On Issue 4395: That issue should be pursued in addition to this issue; it seems Martin's patch for it is complementary to the patch for this issue here. On Issue 22000: I agree that that issue is addressed by the patch for this issue here. All: Please review the v14 patch. -- ___ Python tracker <http://bugs.python.org/issue12067> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
