[issue36643] Forward reference is not resolved by dataclasses.fields()
Paolo Lammens added the comment: I was about to create the exact same ticket; I'm nudging this. -- nosy: +plammens ___ Python tracker <https://bugs.python.org/issue36643> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42795] Asyncio loop.create_server doesn't bind to any interface if host is a sequence with just the empty string
Change by Paolo Lammens : -- title: Asyncio loop.create_server doesn't bind to any interface if host is a sequence with jus the empty string -> Asyncio loop.create_server doesn't bind to any interface if host is a sequence with just the empty string ___ Python tracker <https://bugs.python.org/issue42795> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42795] Asyncio loop.create_server doesn't bind to any interface if host is a sequence with jus the empty string
New submission from Paolo Lammens :
When a sequence containing just the empty string (e.g. `['']`) is passed as the
`host` parameter of `loop.create_server`, the server seems not to bind to any
network interface. Since, per the
[documentation](https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.loop.create_server)
for `create_server`, the empty string means "bind to all interfaces",
> If host is an empty string or None all interfaces are assumed and a list of
> multiple
> sockets will be returned (most likely one for IPv4 and another one for IPv6).
and also
> The host parameter can also be a sequence (e.g. list) of hosts to bind to.
I would have expected a list containing the empty string to also work as
expected, i.e. "binding to all hosts in the sequence", so binding to "" and
thus to every interface.
Example:
Server script:
```python
import asyncio
async def server():
async def connection_callback(reader, writer: asyncio.StreamWriter):
print(f"got connection from {writer.get_extra_info('peername')}")
writer.close()
await writer.wait_closed()
s = await asyncio.start_server(connection_callback, host=[''], port=4567)
async with s:
print("starting server")
await s.serve_forever()
asyncio.run(server())
```
Client script:
```python
import asyncio
async def client():
reader, writer = await asyncio.open_connection("127.0.0.1", 4567)
print(f"connected to {writer.get_extra_info('peername')}")
writer.close()
await writer.wait_closed()
asyncio.run(client())
```
Expected:
- Server:
```
starting server
got connection from ('127.0.0.1', x)
```
- Client:
```
connected to ('127.0.0.1', x)
```
Actual:
- Server:
```
starting server
```
- Client: a ConnectionError is raised (the host machine refused the connection)
--
components: asyncio
messages: 384109
nosy: asvetlov, plammens, yselivanov
priority: normal
severity: normal
status: open
title: Asyncio loop.create_server doesn't bind to any interface if host is a
sequence with jus the empty string
type: behavior
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue42795>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42760] inspect.iscoroutine returns False for asynchronous generator methods
Change by Paolo Lammens : -- title: inspect.iscoroutine returns False for asynchronous generator functions -> inspect.iscoroutine returns False for asynchronous generator methods ___ Python tracker <https://bugs.python.org/issue42760> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42760] inspect.iscoroutine returns False for asynchronous generator functions
Change by Paolo Lammens : -- versions: +Python 3.9 ___ Python tracker <https://bugs.python.org/issue42760> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42785] Support operator module callables in inspect.signature
Paolo Lammens added the comment:
Correction:
```
ValueError: callable operator.attrgetter('spam') is not supported by signature
```
--
___
Python tracker
<https://bugs.python.org/issue42785>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42785] Support operator module callables in inspect.signature
New submission from Paolo Lammens :
Currently, `inspect.signature` doesn't support all callables from the
`operator` module, e.g. `operator.attrgetter`:
```python
>>> import inspect
>>> import operator
>>> inspect.signature(operator.attrgetter("spam"))
ValueError: callable operator.attrgetter('is_host') is not supported by
signature
```
Support for this could be added either directly to `inspect.signature` or by
adding `__signature__` attributes to `operator`'s classes.
--
components: Library (Lib)
messages: 384061
nosy: plammens
priority: normal
severity: normal
status: open
title: Support operator module callables in inspect.signature
type: enhancement
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue42785>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42760] inspect.iscoroutine returns False for asynchronous generator functions
New submission from Paolo Lammens : The `inspect.iscoroutinefunction` and `inspect.iscoroutine` functions return `False` for the `asend`, `athrow` and `aclose` methods of asynchronous generators (PEP 525). These are coroutine functions (i.e. one does e.g. `await gen.asend(value)`) so I would have expected these to return `True`. Example: ```python async def generator(): return yield ``` ```python >>> import inspect >>> g = generator() >>> inspect.iscoroutinefunction(g.asend) False >>> inspect.iscoroutine(g.asend(None)) False ``` -- components: Library (Lib), asyncio messages: 383862 nosy: asvetlov, plammens, yselivanov priority: normal severity: normal status: open title: inspect.iscoroutine returns False for asynchronous generator functions type: behavior ___ Python tracker <https://bugs.python.org/issue42760> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Delegating to part of a subgenerator
Dear all, I've been struggling with the following problem, and I thought maybe there is someone here in python-list who could shine some light on this. Suppose we have a generator function `subgen`, and we want to wrap this in another generator function, `gen`. For clarity, these are "full" generators, i.e. they make use of .send, .throw, .close, etc. The purpose of `gen` is to intercept the first value yielded by `subgen`, transforming it in some form, and forwarding it on to the caller; after that, it should just delegate to the rest of the generator iterator with `yield from`. The problem is, the semantics of `yield from` expect a "fresh" generator iterator, not a partially consumed generator. Indeed, the first value that `yield from` will send to the iterator will be `None`, to start the execution of the generator. But in this case we have already started the generator, and to continue its execution we should really send whatever we received after yielding the first value. However there's no way to specify this with the `yield from` syntax. A solution would be to re-implement the semantics of `yield from`, but with an optional starting value (other than None) that will be sent to the iterator as the initial value. However this means, as I said, re-implementing the whole of `yield from`, i.e. handling .send(), .throw(), .close(), etc., which is not ideal. So that would not be a good solution. Am I asking for the impossible? More details and an example in my original stackoverflow question: https://stackoverflow.com/q/65369447/6117426 Best, -- https://mail.python.org/mailman/listinfo/python-list
[issue42483] Way working directory is added to sys.path differs between using -c or -m
Paolo Lammens added the comment: Hmm I think that’s unrelated; it’s a discussion about whether to add or not the working directory at all. Here the issue is that the way it *is* added differs between -c and -m (which isn’t documented). In both cases it is added (I’m not discussing that) but with -c it is added as an empty string while with -m it’s expanded to the full path beforehand, which results in different behaviour. On Fri, 27 Nov 2020 at 20:33, STINNER Victor wrote: > > STINNER Victor added the comment: > > See > https://discuss.python.org/t/python-flag-envvar-not-to-put-current-directory-to-sys-path-but-dont-ignore-pythonpath/4235 > discussion. > > -- > nosy: +vstinner > > ___ > Python tracker > <https://bugs.python.org/issue42483> > ___ > -- ___ Python tracker <https://bugs.python.org/issue42483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42483] Way working directory is added to sys.path differs between using -c or -m
New submission from Paolo Lammens :
Tested on:
- Python 3.8.6 for Windows 10 64 bit
- Python 3.9.0 for Windows 10 64 bit
- Python 3.8.6 for Ubuntu 20.04
- Python 3.9.0 for Ubuntu 20.04
Originally asked here: https://stackoverflow.com/q/65024647/6117426
-
If you launch a Python process either as a single command from the command line
(with the `-c` flag) or by specifying a module path (with the `-m` flag), the
working directory is prepended to `sys.path`. From the
[docs](https://docs.python.org/3/using/cmdline.html#cmdoption-c) (emphases
mine):
> - **-c \**
>
>[...]
>
>If this option is given, the first element of `sys.argv` will be
>`"-c"` and **the current directory will be added to the start of
>`sys.path`** (allowing modules in that directory to be imported as top
> level
>modules).
>
> [...]
>
> - **-m \**
>
>[...]
>
>If this option is given, the first element of `sys.argv` will be
>thefull path to the module file (while the module file is being
>located, the first element will be set to `"-m"`). As with the
>`-c` option, **the current directory will be added to the start of
>`sys.path`**.
>
>[...]
But it seems the way this is done is different for each option:
```none
$ python -c "import sys; print sys.path"
['', '/usr/lib/python38.zip', '/usr/lib/python3.8',
'/usr/lib/python3.8/lib-dynload',
'/home/plammens/.local/lib/python3.8/site-packages',
'/usr/local/lib/python3.8/dist-packages', '/usr/lib/python3/dist-packages']
$ python -m script # script.py does the same as the command above
['/mnt/c/Users/Paolo/Desktop/Code Sandbox/Python/clean',
'/usr/lib/python38.zip', '/usr/lib/python3.8',
'/usr/lib/python3.8/lib-dynload',
'/home/plammens/.local/lib/python3.8/site-packages',
'/usr/local/lib/python3.8/dist-packages', '/usr/lib/python3/dist-packages']
```
Notice how the first option uses an empty string to denote the current working
directory while the second explicitly adds the path to the directory I ran the
command in.
The empty string is always interpreted dynamically to denote the current
working directory during execution, as per the [docs on the import
system](https://docs.python.org/3/reference/import.html):
> The current working directory – denoted by an empty string – is
> handled slightly differently from other entries on `sys.path`. First, if
> the current working directory is found to not exist, no value is
> stored in `sys.path_importer_cache`. Second, **the value for the current
> working directory is looked up fresh for each module lookup**. Third,
> the path used for `sys.path_importer_cache` and returned by
> `importlib.machinery.PathFinder.find_spec()` will be the actual current
> working directory and not the empty string.
So this means that the `-c` version will always use the current working
directory of the Python process, not the directory that it was originally
launched in.
Indeed, we can make an example to show this. Consider the following file tree,
```none
.
├── script.py
└── secret-folder
└── findme.py
```
with `findme.py` just containing the one statement `print("you found me!")`. If
we run the following
```python
import os
os.chdir('secret-folder')
import findme
```
both as a command (`-c`) and as a script (in `script.py`), we get:
```none
$ python -c "import os; os.chdir('secret-folder'); import findme"
you found me!
$ python -m script
Traceback (most recent call last):
File "/usr/lib/python3.8/runpy.py", line 194, in _run_module_as_main
return _run_code(code, main_globals, None,
File "/usr/lib/python3.8/runpy.py", line 87, in _run_code
exec(code, run_globals)
File "/.../script.py", line 5, in
import findme
ModuleNotFoundError: No module named 'findme'
```
This is because `-m` is using the "hardcoded" working directory while `-c` is
using the "dynamically interpreted" current directory.
By how it's phrased in the documentation for `-c` and `-m` though, one would
think these two should behave identically.
Is this intended? If so, it isn't documented.
--
assignee: docs@python
components: Documentation, Interpreter Core
messages: 381942
nosy: docs@python, plammens
priority: normal
severity: normal
status: open
title: Way working directory is added to sys.path differs between using -c or -m
type: behavior
versions: Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue42483>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41813] Clarify specification of object.__await__
Paolo Lammens added the comment: The proposed addition (see attached PR) is the following note: .. note:: The language doesn't place any restriction on the type or value of the objects yielded by the iterator returned by :meth:`__await__`, as this is specific to the implementation of the event loop that will be managing the :term:`awaitable` object. In the case of :mod:`asyncio`, user code should always be using other :term:`coroutines `, :mod:`asyncio` Tasks, Futures, and other :mod:`asyncio` objects to implement :meth:`__await__`, yielding objects from these, and never yielding objects directly—as the kind of objects that the event loop expects are considered a private implementation detail of :mod:`asyncio`. -- ___ Python tracker <https://bugs.python.org/issue41813> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41813] Clarify specification of object.__await__
Change by Paolo Lammens : -- keywords: +patch pull_requests: +21365 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22320 ___ Python tracker <https://bugs.python.org/issue41813> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41813] Clarify specification of object.__await__
New submission from Paolo Lammens : The current specification of object.__await__ is just: > `object.__await__(self)` > > Must return an iterator. Should be used to implement awaitable objects. For > instance, `asyncio.Future` implements this method to be compatible with the > await expression. This is pretty vague leaves the doubt of *what* objects is the iterator expected to yield (and how the value of the yielded object affects the management of the awaitable object). Although the vagueness is probably on purpose (since this isn't tied to any particular event loop implementation, so it can be an arbitrary iterable), I think it's worthwhile adding a note clarifying this aspect. I originally posed this question on StackOverflow: https://stackoverflow.com/q/63964011/6117426 -- assignee: docs@python components: Documentation messages: 377166 nosy: docs@python, plammens priority: normal severity: normal status: open title: Clarify specification of object.__await__ ___ Python tracker <https://bugs.python.org/issue41813> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
