[issue38431] dataclasses.InitVar breaks with typing.Optional
New submission from Samuel Colvin :
The following code works fine with python 3.7 but breaks with 3.8:
```
import dataclasses
from typing import Optional
@dataclasses.dataclass
class TestingDataclass:
base_path: dataclasses.InitVar[Optional[str]] = None
```
Exception traceback:
```
Traceback (most recent call last):
File "test.py", line 6, in
class TestingDataclass:
File "/usr/local/lib/python3.8/dataclasses.py", line 995, in dataclass
return wrap(cls)
File "/usr/local/lib/python3.8/dataclasses.py", line 987, in wrap
return _process_class(cls, init, repr, eq, order, unsafe_hash, frozen)
File "/usr/local/lib/python3.8/dataclasses.py", line 967, in _process_class
str(inspect.signature(cls)).replace(' -> None', ''))
File "/usr/local/lib/python3.8/inspect.py", line 3050, in __str__
formatted = str(param)
File "/usr/local/lib/python3.8/inspect.py", line 2568, in __str__
formatannotation(self._annotation))
File "/usr/local/lib/python3.8/inspect.py", line 1202, in formatannotation
return repr(annotation)
File "/usr/local/lib/python3.8/dataclasses.py", line 213, in __repr__
return f'dataclasses.InitVar[{self.type.__name__}]'
File "/usr/local/lib/python3.8/typing.py", line 757, in __getattr__
raise AttributeError(attr)
AttributeError: __name__
```
The code runs fine with `str` instead of `Optional[str]`.
Tested locally with `Python 3.8.0rc1 (tags/v3.8.0rc1:34214de6ab, Oct 10 2019,
16:15:14)`. The same error can be seen (in a more involved context) on travis
[here](https://travis-ci.org/samuelcolvin/pydantic/jobs/596131963)
--
components: Library (Lib)
messages: 354388
nosy: samuelcolvin
priority: normal
severity: normal
status: open
title: dataclasses.InitVar breaks with typing.Optional
type: behavior
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue38431>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38431] dataclasses.InitVar breaks with typing.Optional
Samuel Colvin added the comment: This is a bug with the `__repr__` method on `InitVar`. I'm working on a PR now. -- ___ Python tracker <https://bugs.python.org/issue38431> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38431] dataclasses.InitVar breaks with typing.Optional
Change by Samuel Colvin : -- keywords: +patch pull_requests: +16286 stage: -> patch review pull_request: https://github.com/python/cpython/pull/16700 ___ Python tracker <https://bugs.python.org/issue38431> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38431] dataclasses.InitVar breaks with typing.Optional
Change by Samuel Colvin : -- pull_requests: +16288 pull_request: https://github.com/python/cpython/pull/16702 ___ Python tracker <https://bugs.python.org/issue38431> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45108] frame.f_lasti points at DICT_MERGE instead of CALL_FUNCTION_EX in Windows only
Samuel Colvin added the comment: Perhaps worth adding that the tests don't fail on python 3.6, 3.7 or 3.8. -- nosy: +samuelcolvin ___ Python tracker <https://bugs.python.org/issue45108> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31241] ast col_offset wrong for list comprehensions, generators and tuples
New submission from Samuel Colvin:
With Python 3.5 and 3.6 list comprehensions, generators and tuples have the
col_offset for their ast nodes off by 1:
```
import ast
ast.parse('{a for a in range(3)}').body[0].value.col_offset
>> 0 # set comprehension correct
ast.parse('{a: 1 for a in range(3)}').body[0].value.col_offset
>> 0 # dict comprehension correct
ast.parse('[a for a in range(3)]').body[0].value.col_offset
>> 1 # list comprehension wrong!
ast.parse('(a for a in range(3))').body[0].value.col_offset
>> 1 # generator comprehension wrong!
ast.parse('[1, 2, 3]').body[0].value.col_offset
>> 0 # list correct
ast.parse('{1, 2, 3}').body[0].value.col_offset
>> 0 # set correct
ast.parse('{1: 1, 2: 2, 3: 3}').body[0].value.col_offset
>> 0 # dict correct
ast.parse('(1, 2, 3)').body[0].value.col_offset
>> 1 # tuple wrong!
```
I haven't tried 3.4, the issue could be there too.
There are some other related issues #16806 and #21295 but they don't seem quite
the same.
--
components: Interpreter Core
messages: 300606
nosy: samuelcolvin
priority: normal
severity: normal
status: open
title: ast col_offset wrong for list comprehensions, generators and tuples
versions: Python 3.5, Python 3.6
___
Python tracker
<http://bugs.python.org/issue31241>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35788] smtpd.PureProxy and smtpd.MailmanProxy broken by extra kwargs, bytes and more
New submission from Samuel Colvin : smtpd.PureProxy.process_message and smtpd.MailmanProxy.process_message are defined to not receive the extra kwargs which they're called with. They both also expect "data" to be str when it's actually bytes. Thus they're completed broken at the moment. I'd like to submit a PR to fix these two bugs. There are a number of other issues/potential improvements to smtpd which are not critical but I guess should be fixed: * no support for starttls * use of print(..., file=DEBUGSTREAM) instead of logger.debug * no type hints * PureProxy's forwarding doesn't try starttls Should I create a new issue(s) for these problems or is there some agreement that only actual bugs will be fixed in little-used modules like this? -- components: email messages: 334083 nosy: barry, r.david.murray, samuelcolvin priority: normal severity: normal status: open title: smtpd.PureProxy and smtpd.MailmanProxy broken by extra kwargs, bytes and more type: crash versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue35788> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35788] smtpd.PureProxy and smtpd.MailmanProxy broken by extra kwargs, bytes and more
Change by Samuel Colvin : -- keywords: +patch pull_requests: +11381 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue35788> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35788] smtpd.PureProxy and smtpd.MailmanProxy broken by extra kwargs, bytes and more
Change by Samuel Colvin : -- keywords: +patch, patch, patch, patch pull_requests: +11381, 11382, 11383, 11384 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue35788> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35788] smtpd.PureProxy and smtpd.MailmanProxy broken by extra kwargs, bytes and more
Change by Samuel Colvin : -- keywords: +patch, patch, patch pull_requests: +11381, 11382, 11383 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue35788> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35788] smtpd.PureProxy and smtpd.MailmanProxy broken by extra kwargs, bytes and more
Change by Samuel Colvin : -- keywords: +patch, patch pull_requests: +11381, 11382 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue35788> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35788] smtpd.PureProxy and smtpd.MailmanProxy broken by extra kwargs, bytes and more
Samuel Colvin added the comment: Thanks for the explanation David. It would be really useful if this was prominently noted in smtpd, it would have saved me spending my morning fixing these things. There's also (AFAIK) nothing about this being deprecated in the docs. More generally I understand the idea of deprecated code that doesn't get updated to conform to latest conventions, but surely if the code exists in the standard lib. it should at least work as it was originally intended or be removed? Since the PR is done and passing surely it would be better to merge it than leave PureProxy completely broken. By the way, aiosmtpd is not in good shape: 1. Its proxy handler is blocking https://github.com/aio-libs/aiosmtpd/blob/master/aiosmtpd/handlers.py#L119 2. Its proxy handler appears to be broken in some other way, I couldn't get it to forward emails which is why I resorted to using standard smtpd. 3. It's built in a very odd way, it appears to use threading not asyncio to run the main controller https://github.com/aio-libs/aiosmtpd/blob/master/aiosmtpd/controller.py#L54 -- ___ Python tracker <https://bugs.python.org/issue35788> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35788] smtpd.PureProxy and smtpd.MailmanProxy broken by extra kwargs, bytes and more
Samuel Colvin added the comment: Thanks for the response. I've created issues on aiosmtpd for both these things. There are much better ways of running the controller than threading, but that's a discussion for https://github.com/aio-libs/aiosmtpd/issues/160. I'll try and work on aiosmtpd in the future. Regarding smtpd, please could you respond to: > More generally I understand the idea of deprecated code that doesn't get > updated to conform to latest conventions, but surely if the code exists in > the standard lib. it should at least work as it was originally intended or be > removed? Of course, I know part of this is my wish to get my PR merged into cpython, but I really don't see any argument for leaving completely broken code in the standard library. Surely either it should be removed before the next minor release or fixed? I would say PureProxy could still be useful and should be left in place while MailmanProxy should be removed. -- ___ Python tracker <https://bugs.python.org/issue35788> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35788] smtpd.PureProxy and smtpd.MailmanProxy broken by extra kwargs, bytes and more
Samuel Colvin added the comment: Ok. Thanks for your explanation. Makes sense. -- ___ Python tracker <https://bugs.python.org/issue35788> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35799] fix or remove smtpd.PureProxy
New submission from Samuel Colvin : smtpd.PureProxy.process_message is defined to not receive the extra kwargs which it is called with. It also expects "data" to be str when it's actually bytes. PureProxy should either be removed for fixed. Personally, I think it should be fixed as the fix is pretty simple and PureProxy can be very useful. Created from https://bugs.python.org/issue35788 Happy to create a PR if this is agreed. -- components: email messages: 334156 nosy: barry, r.david.murray, samuelcolvin priority: normal severity: normal status: open title: fix or remove smtpd.PureProxy type: crash versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue35799> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35800] remove smtpd.MailmanProxy
New submission from Samuel Colvin : smtpd.MailmanProxy is completely broken, it takes the wrong arguments but also assumes the existence of a "Mailman" module which doesn't exist. It should be removed in 3.8 or 3.9. Created from https://bugs.python.org/issue35788 Happy to create a PR if this is agreed. -- components: email messages: 334157 nosy: barry, r.david.murray, samuelcolvin priority: normal severity: normal status: open title: remove smtpd.MailmanProxy versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue35800> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35788] smtpd.PureProxy and smtpd.MailmanProxy broken by extra kwargs, bytes and more
Samuel Colvin added the comment: Great, https://bugs.python.org/issue35799 and https://bugs.python.org/issue35800 created. -- ___ Python tracker <https://bugs.python.org/issue35788> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35800] remove smtpd.MailmanProxy
Samuel Colvin added the comment: Ok, if I create a PR, should it just remove MailmanProxy completely or mark it as deprecated in the docs to be removed in 3.9? Personally, I think it should be ok to remove it completely since it hasn't been working at all for the last 4 minor versions. -- ___ Python tracker <https://bugs.python.org/issue35800> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35800] remove smtpd.MailmanProxy
Change by Samuel Colvin : -- keywords: +patch pull_requests: +11494 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue35800> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35800] remove smtpd.MailmanProxy
Change by Samuel Colvin : -- keywords: +patch, patch pull_requests: +11494, 11495 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue35800> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35800] remove smtpd.MailmanProxy
Change by Samuel Colvin : -- keywords: +patch, patch, patch pull_requests: +11494, 11495, 11496 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue35800> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35837] smtpd PureProxy breaks on mail_options keyword argument
Samuel Colvin added the comment: Hi, did you see https://bugs.python.org/issue35788#msg334155 later in the issue? -- ___ Python tracker <https://bugs.python.org/issue35837> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30556] asyncio.wait very slow with FIRST_COMPLETED
New submission from Samuel Colvin: This is best described the script at https://gist.github.com/samuelcolvin/00f01793c118bf9aafae886ffbc81a58. Basically, completing a set of tasks using asyncio.wait(...return_when=asyncio.FIRST_COMPLETED) in a loop to wait for them to finish is much much slower than completing the same set of tasks using just asyncio.wait(pending_tasks, loop=loop, return_when=asyncio.ALL_COMPLETED). In my example, the ALL_COMPLETED case takes ~5s, but the FIRST_COMPLETED case takes 18 - 47s. The screenshot on the gist shows network usage with a very long tail, in other words very few tasks are taking a long time to complete. This example uses aiohttp get a url as the test case but I'm pretty sure this isn't an issue with aiohttp. I tried the same thing with uvloop but got broadly the same result. -- components: asyncio files: asyncio_wait_test.py messages: 295045 nosy: samuelcolvin, yselivanov priority: normal severity: normal status: open title: asyncio.wait very slow with FIRST_COMPLETED type: performance versions: Python 3.6 Added file: http://bugs.python.org/file46920/asyncio_wait_test.py ___ Python tracker <http://bugs.python.org/issue30556> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28904] add more format conversion flags eg. "len" and "id"
New submission from Samuel Colvin:
(The "Components" selection might be wrong, I wasn't sure what to use)
As https://docs.python.org/3.6/library/string.html
> Three conversion flags are currently supported: '!s' which calls str() on the
> value, '!r' which calls repr() and '!a' which calls ascii().
It would be great if further conversation flags were added for more built-in
methods. In particular:
* '!l' for len()
* '!i' for id()
(There might be others but these are the two I would find most useful.)
format() is now very powerful, but it's very common for strings, lists, dicts,
sets etc. to want to include their length in strings. This is currently ugly.
This enhancement will be even more sought after with string literals in python
3.6.
Example of when this would be very useful:
v = {'type': 'whatever, 'items': ['foo', 'bar', 'spam']}
'{type}{items!l}'.format(**v)
Would also be very useful with getattr, and getitem usage.
--
components: Library (Lib)
messages: 282707
nosy: Samuel Colvin
priority: normal
severity: normal
status: open
title: add more format conversion flags eg. "len" and "id"
type: enhancement
versions: Python 3.7
___
Python tracker
<http://bugs.python.org/issue28904>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28904] add more format conversion flags eg. "len" and "id"
Samuel Colvin added the comment: I know contributing to python is currently a pain (bring on github!) but I'd be happy to attempt a patch if others agree this would be useful. -- ___ Python tracker <http://bugs.python.org/issue28904> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28904] add more format conversion flags eg. "len" and "id"
Samuel Colvin added the comment:
I see, I hadn't appreciated fstrings where entirely different and more powerful
than format(), I'll close this.
For anyone else coming to this, with fstrings in >=3.6 you can do:
In [4]: value = [1,2, 3]
In [5]: f'The value is {value}.'
Out[5]: 'The value is [1, 2, 3].'
In [6]: f'The value is {len(value)}.'
Out[6]: 'The value is 3.'
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue28904>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26479] Init documentation typo "may be return" > "may NOT be returned"
New submission from Samuel Colvin: https://docs.python.org/3/reference/datamodel.html#object.__init__ "no non-None value may be returned by __init__();" should read "no non-None value may *not* be returned by __init__();" -- assignee: docs@python components: Documentation messages: 261185 nosy: Samuel Colvin, docs@python priority: normal severity: normal status: open title: Init documentation typo "may be return" > "may NOT be returned" versions: Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue26479> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26479] Init documentation typo "may be return" > "may NOT be returned"
Samuel Colvin added the comment: Sorry, I'm going mad, misread it. -- resolution: -> not a bug status: open -> closed ___ Python tracker <http://bugs.python.org/issue26479> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28206] signal.Signals not documented
New submission from Samuel Colvin: As per discussion on typeshed pull request discussion (https://github.com/python/typeshed/pull/555) the "signal.Signals" enum is not documented but should be. See https://docs.python.org/3.5/library/signal.html. -- assignee: docs@python components: Documentation messages: 276979 nosy: Samuel Colvin, docs@python priority: normal severity: normal status: open title: signal.Signals not documented versions: Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue28206> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
