New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA(a)GMail.Com>:
It's undocumented that imp.find_module("") and imp.find_module(".") try to find __init__.py.
There is also a small difference in behavior between them.
sys.path by default contains "" as the first element, which is sufficient for imp.find_module("."), but not for imp.find_module(""):
$ mkdir /tmp/imp_tests
$ cd /tmp/imp_tests
$ touch __init__.py
$ python3.3 -c 'import imp, sys; print(repr(sys.path[0])); print(imp.find_module("."))'
''
(None, '.', ('', '', 5))
$ python3.3 -c 'import imp, sys; print(repr(sys.path[0])); print(imp.find_module(""))'
''
Traceback (most recent call last):
File "<string>", line 1, in <module>
ImportError: No module named ''
If sys.path contains path (e.g. "." or absolute path) to directory with __init__.py file, then imp.find_module("") will succeed:
$ PYTHONPATH="." python3.3 -c 'import imp, sys; print(repr(sys.path[0:2])); print(imp.find_module("."))'
['', '/tmp/imp_tests']
(None, '.', ('', '', 5))
$ PYTHONPATH="." python3.3 -c 'import imp, sys; print(repr(sys.path[0:2])); print(imp.find_module(""))'
['', '/tmp/imp_tests']
(None, '/tmp/imp_tests/', ('', '', 5))
$ python3.3 -c 'import imp, sys; sys.path.insert(1, "."); print(repr(sys.path[0:2])); print(imp.find_module("."))'
['', '.']
(None, '.', ('', '', 5))
$ python3.3 -c 'import imp, sys; sys.path.insert(1, "."); print(repr(sys.path[0:2])); print(imp.find_module(""))'
['', '.']
(None, './', ('', '', 5))
I think that imp.find_module(".") and imp.find_module("") should have the same behavior, and this behavior should be documented.
----------
assignee: docs@python
components: Documentation, Interpreter Core
messages: 144531
nosy: Arfrever, docs@python
priority: normal
severity: normal
status: open
title: imp.find_module("") and imp.find_module(".")
versions: Python 2.7, Python 3.2, Python 3.3
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue13047>
_______________________________________
New submission from anatoly techtonik <techtonik(a)gmail.com>:
http://docs.python.org/library/pdb.html#pdb.Pdb
Documentation for pdb says: "The debugger is extensible — it is actually defined as the class Pdb. This is currently undocumented but easily understood by reading the source."
There should a link to the source.
----------
assignee: docs@python
components: Documentation, Library (Lib)
messages: 162074
nosy: docs@python, techtonik
priority: normal
severity: normal
status: open
title: pdb: Link to source
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue14979>
_______________________________________
New submission from mpb:
types.NoneType seems to have disappeared in Python 3. This is probably intentional, but I cannot figure out how to test if a variable is of type NoneType in Python 3.
Specifically, I want to write:
assert type (v) in ( bytes, types.NoneType )
Yes, I could write:
assert v is None or type (v) is bytes
But the first assert statement is easier to read (IMO).
Here are links to various Python 3 documentation about None:
[1] http://docs.python.org/3/library/stdtypes.html#index-2
[2] http://docs.python.org/3/library/constants.html#None
Link [2] says: "None The sole value of the type NoneType." However, NoneType is not listed in the Python 3 documentation index. (As compared with the Python 2 index, where NoneType is listed.)
[3] http://docs.python.org/3/library/types.html
If NoneType is gone in Python 3, mention of NoneType should probably be removed from link [2]. If NoneType is present in Python 3, the docs (presumably at least one of the above links, and hopefully also the index) should tell me how to use it.
Here is another link:
[4] http://docs.python.org/3/library/stdtypes.html#bltin-type-objects
"The standard module types defines names for all standard built-in types." (Except <class 'NoneType'> ???)
None is a built-in constant. It has a type. If None's type is not considered to be a "standard built-in type", then IMO this is surprising(!!) and should be documented somewhere (for example, at link [4], and possibly elsewhere as well.)
Thanks!
----------
assignee: docs@python
components: Documentation
messages: 201666
nosy: docs@python, mpb
priority: normal
severity: normal
status: open
title: Where is NoneType in Python 3?
versions: Python 3.3
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue19438>
_______________________________________
New submission from Christian Heimes:
>From #31431, the documentation of CERT_OPTIONAL and CERT_REQUIRED are misleading. For client side sockets, CERT_OPTIONAL does **NOT** mean that no certificates will be required from the other side of the socket connection. The server **must** provide a cert and the client **requires** the cert to be valid and trusted by trusted CA.
Internally, the _ssl.c extension module sets:
CERT_NONE: SSL_CTX_set_verify(ctx, SSL_VERIFY_NONE, verify_cb)
CERT_OPTIONAL: SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, verify_cb)
CERT_REQUIRED: SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT, verify_cb)
According to https://www.openssl.org/docs/man1.0.2/ssl/SSL_CTX_set_verify.html SSL_VERIFY_FAIL_IF_NO_PEER_CERT is ignored in client mode.
This means for client-side sockets:
CERT_NONE: server must provide any cert, verification error does not prevent handshake
CERT_OPTIONAL == CERT_REQUIRED
CERT_REQUIRED: server must provide a correct certificate that is trusted by a root CA in the trust store of the client
For server-side sockets:
CERT_NONE: Don't ask client for a TLS client auth cert
CERT_OPTIONAL: Ask client for a TLS client auth cert, don't fail if the client does not provide one. IIRC the cert must validate and be trusted by a CA in the trust store of the server (TODO: verify this)
CERT_REQUIRED: Ask client for TLS client auth cert, fail if client does not provide a certificate during the handshake.
----------
assignee: docs@python
components: Documentation, SSL
messages: 301970
nosy: christian.heimes, docs@python
priority: normal
severity: normal
status: open
title: Documention for CERT_OPTIONAL is misleading
type: behavior
versions: Python 2.7, Python 3.6, Python 3.7
_______________________________________
Python tracker <report(a)bugs.python.org>
<https://bugs.python.org/issue31432>
_______________________________________
New submission from Christian Ullrich:
In 3.6.1, the manual, section 3.1.3, has this to say:
"Your administrator will need to activate the “Enable Win32 long paths” group policy, or set the registry value HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem@LongPathsEnabled to 1."
Separating a value name from the key path with an @-sign, which is what the above is doing, is something I have never before seen anywhere. I suggest changing it by either:
- replacing the instructions for the manual change with a link to <https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).…> or a more suitable reference (I could not find a KB article when I looked)
- rewording it as, e.g.,
... in the registry key HKEY_...FileSystem, set the REG_DWORD value LongPathsEnabled to 1
The value type could be left out; the value is predefined on all platforms where it will be effective.
----------
assignee: docs@python
components: Documentation
messages: 295505
nosy: Christian.Ullrich, docs@python
priority: normal
severity: normal
status: open
title: Unusual Windows registry path syntax
type: enhancement
versions: Python 3.6
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue30612>
_______________________________________
New submission from Devin Jeanpierre:
am not sure when TypeError is the right choice. Definitely, most of the time I've seen it done, it causes trouble, and NotImplemented usually does something better.
For example, see the work in https://bugs.python.org/issue8743 to get set to interoperate correctly with other set-like classes --- a problem caused by the use of TypeError instead of returning NotImplemented (e.g. https://hg.python.org/cpython/rev/3615cdb3b86d).
This advice seems to conflict with the usual and expected behavior of objects from Python: e.g. object().__lt__(1) returns NotImplemented rather than raising TypeError, despite < not "making sense" for object. Similarly for file objects and other uncomparable classes. Even complex numbers only return NotImplemented!
>>> 1j.__lt__(1j)
NotImplemented
If this note should be kept, this section could use a decent explanation of the difference between "undefined" (should return NotImplemented) and "nonsensical" (should apparently raise TypeError). Perhaps a reference to an example from the stdlib.
----------
assignee: docs@python
components: Documentation
messages: 291144
nosy: Devin Jeanpierre, docs@python
priority: normal
pull_requests: 1167
severity: normal
status: open
title: Documentation recommends raising TypeError from tp_richcompare
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue29986>
_______________________________________
New submission from July Tikhonov:
A note just below object.__setstate__() documentation
https://docs.python.org/3.6/library/pickle.html#object.__setstate__
says that
"""
… the type should implement __getnewargs__() or __getnewargs_ex__() to establish such an invariant; otherwise, neither __new__() nor __init__() will be called.
"""
I believe that note about not calling __new__() was relevant in python2. I could not find case in python3 in which __new__() would not be called. And __init__() is not called anyway, as far as I understand (unless explicitly by __setstate__() or something).
Python 3.6.0a3+ (default:da9898e7e90d, Jul 27 2016, 19:51:12)
[GCC 4.9.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> class C:
... def __getstate__(self): return {'foo' : self.foo}
... def __setstate__(self, state): self.foo = state['foo']
... def __new__(cls):
... print('__new__ is called'); return super().__new__(cls)
... def __init__(self):
... print('__init__ is called'); self.foo = None; super().__init__()
...
>>> c = C(); c.foo = 'bar'
__new__ is called
__init__ is called
>>> import pickle
>>> c2 = pickle.loads(pickle.dumps(c))
__new__ is called
>>> c2.foo
'bar'
----------
assignee: docs@python
components: Documentation
messages: 271465
nosy: docs@python, july
priority: normal
severity: normal
status: open
title: pickle documentation says that unpickling may not call __new__
versions: Python 3.4, Python 3.5, Python 3.6
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue27635>
_______________________________________
New submission from Olav Morken:
The documentation for the `-u`-flag (https://docs.python.org/3/using/cmdline.html#cmdoption-u) contains:
> The text I/O layer will still be line-buffered if writing to the console, or block-buffered if redirected to a non-interactive file.
This does not appear to be the case -- instead it is always line-buffered:
https://hg.python.org/cpython/file/v3.5.1/Python/pylifecycle.c#l1041
Attached is a trivial patch that simply removes everything after "line-buffered".
----------
assignee: docs@python
components: Documentation
files: fix-doc-unbuffered.patch
keywords: patch
messages: 264910
nosy: docs@python, olavmrk
priority: normal
severity: normal
status: open
title: Incorrect documentation for `-u`-flag
Added file: http://bugs.python.org/file42736/fix-doc-unbuffered.patch
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue26964>
_______________________________________
New submission from bjonnh:
in
https://docs.python.org/3.5/howto/descriptor.html#static-methods-and-class-…
(same problem in all python 3.x documentations)
There is this example where the return of f function is printed and there is already a print in the function:
"""
>>> class E(object):
def f(x):
print(x)
f = staticmethod(f)
>>> print(E.f(3))
3
>>> print(E().f(3))
3
"""
It should probably be:
"""
def f(x):
return(x)
"""
or
"""
>> E.f(3)
3
>> E().f(3)
"""
----------
assignee: docs@python
components: Documentation
messages: 241312
nosy: bjonnh, docs@python
priority: normal
severity: normal
status: open
title: Documentation error: Descriptors
type: enhancement
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue23984>
_______________________________________
New submission from Nick Coghlan:
In issue 24342, the invocation of coroutine wrappers specified via sys.set_coroutine_wrapper was fixed to catch and report the case of infinite recursion, where the wrapper attempts to instantiate a nested coroutine (which would call the wrapper, which would attempt to instantiate the coroutine, etc, etc)
The docs for sys.set_coroutine_wrapper include an example of this failure case: https://docs.python.org/3/library/sys.html#sys.set_coroutine_wrapper
However, if you're not reading carefully, it looks like an example of how to *use* sys.set_coroutine_wrapper, rather than an example of a case that won't work.
It would be better to include an example that either doesn't wrap the coroutine at all, or else uses one of the non-native coroutine emulations to avoid the infinite recursion problem:
```
import asyncio, sys
def wrapper(coro):
@asyncio.coroutine
def wrap(coro):
print("Coroutine started")
result = yield from coro
print("Coroutine finished")
return result
return wrap(coro)
sys.set_coroutine_wrapper(wrapper)
async def foo():
print("Coroutine running")
return "Coroutine result"
import asyncio
asyncio.get_event_loop().run_until_complete(foo())
```
Also related: I discovered in writing this that "sys.set_coroutine_wrapper(None)" doesn't actually turn off coroutine wrapping. Instead, you still get this exception when attempting to recursively define an unwrapped one:
RuntimeError: coroutine wrapper <NULL> attempted to recursively wrap <code object wrap at 0x7eff31fbde40, file "<stdin>", line 2>)
That error was produced as follows:
```
import sys, contextlib
@contextlib.contextmanager
def disable_coroutine_wrapping():
wrapper = sys.get_coroutine_wrapper()
sys.set_coroutine_wrapper(None)
try:
yield
finally:
sys.set_coroutine_wrapper(wrapper)
def wrapper(coro):
async def wrap(coro):
print("Coroutine started")
result = await coro
print("Coroutine finished")
return result
with disable_coroutine_wrapping():
return wrap(coro)
sys.set_coroutine_wrapper(wrapper)
async def foo():
print("Coroutine running")
return "Coroutine result"
import asyncio
asyncio.get_event_loop().run_until_complete(foo())
```
----------
assignee: docs@python
components: Documentation
messages: 295231
nosy: docs@python, giampaolo.rodola, haypo, ncoghlan, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: Misleading example in sys.set_coroutine_wrapper docs
type: enhancement
versions: Python 3.6, Python 3.7
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue30578>
_______________________________________