[issue30831] Inconsistent or wrong documentation around Asynchronous Context Manager
New submission from Daisuke Miyakawa:
I was reading the following doc and got confused.
https://docs.python.org/3.7/reference/datamodel.html#object.__aenter__
According to the API doc itself (and original PEP 492), __aenter__() "is
semantically similar to the __enter__(), with only difference that it must
return an awaitable." __aexit__() has similar sentence that confuses me too.
PEP 492 also implies the (awaitable) object returned from obj.__aenter__() will
be awaited immediately. In same manner, the (awaitable) object returned from
obj.__aexit__() will be awaited too.
(From PEP 492)
> async with EXPR as VAR:
> BLOCK
>
> which is semantically equivalent to:
>
> mgr = (EXPR)
> aexit = type(mgr).__aexit__
> aenter = type(mgr).__aenter__(mgr)
> exc = True
>
> VAR = await aenter
> try:
> BLOCK
> except:
> if not await aexit(mgr, *sys.exc_info()):
> raise
> else:
> await aexit(mgr, None, None, None)
On the other hand, actual CPython implementation won't do that; it won't await
the returned objects.
Moreover, the example shown in the API doc (AsyncContextManager) does NOT
return awaitable as the doc itself suggests, but just await inside __aenter__()
(and __aexit__()).
> class AsyncContextManager:
>async def __aenter__(self):
>await log('entering context')
>
>async def __aexit__(self, exc_type, exc, tb):
>await log('exiting context')
I'm not sure which is true; the doc saying "__aenter__() must return awaitable"
is just incorrect, or CPython implementation has a bug. Actual source implies
former. _ContextManagerMixin in asyncio.locks does not return awaitable at all,
for example.
Anyway, I believe there are inconsistencies around here.
--
assignee: docs@python
components: Documentation
messages: 297542
nosy: dmiyakawa, docs@python
priority: normal
severity: normal
status: open
title: Inconsistent or wrong documentation around Asynchronous Context Manager
versions: Python 3.6, Python 3.7
___
Python tracker
<http://bugs.python.org/issue30831>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31567] Inconsistent documentation around decorators
New submission from Daisuke Miyakawa: I can see inconsistency in library documentation around functions that are suitable for decorators. I'd like to clarify if it is based on my misunderstanding, or a real documentation problem. Examples: - https://docs.python.org/3/library/functions.html#staticmethod - https://docs.python.org/3/library/functools.html#functools.lru_cache Both staticmethod() and functools.lru_cache() are used with decorator expressions, while they have slightly different explanations. The first one looks like just a usual function while the detailed explanations say it is used with decorator expression. The second one is what I don't understand; it says "@functools.lru_cache()", where the function name is "decorated" with @ in the doc. What does @ mean here? If there's some meaning, the next question is, why doc for staticmethod() (and classmethod() in the same page) does not have it? I don't know which is better, but I believe consistency is good. Some other examples : - https://docs.python.org/3/library/contextlib.html?highlight=decorator -> @ here - https://docs.python.org/3/library/unittest.mock.html#unittest.mock.patch -> no @ here - https://docs.python.org/2.7/library/functools.html#functools.lru_cache -> Old functools does not have @ -- assignee: docs@python components: Documentation messages: 302830 nosy: dmiyakawa, docs@python priority: normal severity: normal status: open title: Inconsistent documentation around decorators type: behavior versions: Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue31567> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31567] Inconsistent documentation around decorators
Change by Daisuke Miyakawa : -- keywords: +patch pull_requests: +3935 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue31567> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27724] PEP3119 inconsintent with actual CPython impl
New submission from Daisuke Miyakawa: Python 3.5.2 (and Python 2.7.12) uses Py_TPFLAGS_IS_ABSTRACT while PEP 3119 menttions "Py_TPFLAGS_ABSTRACT" for it. At some point had the name of the flag been changed without modifying PEP? -- assignee: docs@python components: Documentation messages: 272321 nosy: Daisuke Miyakawa, docs@python priority: normal severity: normal status: open title: PEP3119 inconsintent with actual CPython impl versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue27724> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28630] setup.py bdist_egg --without-source-files does not allow console_script to run as expected
New submission from Daisuke Miyakawa:
I'm trying to prepare an egg file "without source code".
I works mostly, while console_script does not.
Here's a sample project for it, in which the function
"greeting.greeting.greeting()" prints "Greeting!".
https://github.com/dmiyakawa/python_greeting
First, I tried creating an egg with source code, which worked perfectly as a
standalone script (console_script).
--
$ python --version
Python 3.5.2
$ python setup.py bdist_egg
..
$ easy_install dist/greeting-1.0.0-py3.5.egg
..
$ greeting
Greeting!
$ pip unistnall greeting
(it uninstalls, but with some exception..)
--
Next, I tried creating an egg without source code, which is what I want to do.
The package was installed but did not work as a standalone script
(console_script).
Note that I can use it from interactive shell.
--
$ python setup.py bdist_egg --exclude-source-files
..
$ easy_install dist/greeting-1.0.0-py3.5.egg
..
$ greeting
Traceback (most recent call last):
File "/Users/dmiyakawa/.pyenv/versions/3.5.2/bin/greeting", line 9, in
load_entry_point('greeting==1.0.0', 'console_scripts', 'greeting')()
File
"/Users/dmiyakawa/.pyenv/versions/3.5.2/lib/python3.5/site-packages/pkg_resources/__init__.py",
line 542, in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
File
"/Users/dmiyakawa/.pyenv/versions/3.5.2/lib/python3.5/site-packages/pkg_resources/__init__.py",
line 2569, in load_entry_point
return ep.load()
File
"/Users/dmiyakawa/.pyenv/versions/3.5.2/lib/python3.5/site-packages/pkg_resources/__init__.py",
line 2229, in load
return self.resolve()
File
"/Users/dmiyakawa/.pyenv/versions/3.5.2/lib/python3.5/site-packages/pkg_resources/__init__.py",
line 2235, in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
ImportError: No module named 'greeting'
$ python
Python 3.5.2 (default, Oct 24 2016, 21:47:12)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.38)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from greeting.greeting import greeting
>>> greeting()
Greeting!
--
I saw this behavior both on Mac (Siera), Windows (64bits), and Linux (Debian
Jessie).
With pyenv, I tried the same thing with Python 3.6.0b3 (on Mac). Same there.
--
components: Build
messages: 280190
nosy: Daisuke Miyakawa
priority: normal
severity: normal
status: open
title: setup.py bdist_egg --without-source-files does not allow console_script
to run as expected
type: behavior
versions: Python 3.5, Python 3.6
___
Python tracker
<http://bugs.python.org/issue28630>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28713] Recent tutorial for recent Python3 still uses IOError.
New submission from Daisuke Miyakawa:
https://docs.python.org/3.5/tutorial/errors.html
for arg in sys.argv[1:]:
try:
f = open(arg, 'r')
except IOError:
print('cannot open', arg)
else:
print(arg, 'has', len(f.readlines()), 'lines')
f.close()
Although IOError is still available as an alias to OSError, it should not be
used in the tutorial, I believe.
--
assignee: docs@python
components: Documentation
messages: 280924
nosy: dmiyakawa, docs@python
priority: normal
severity: normal
status: open
title: Recent tutorial for recent Python3 still uses IOError.
versions: Python 3.5
___
Python tracker
<http://bugs.python.org/issue28713>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28713] Recent tutorial for recent Python3 still uses IOError.
Changes by Daisuke Miyakawa : -- versions: +Python 3.6 ___ Python tracker <http://bugs.python.org/issue28713> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
