[issue41269] Wrong subtraction calculations

[Ivan]

New submission from Ivan :

I've started to learn python and tried command:
print(-2.989 + 2)
it gives me result of -0.9889
same error can be observed with numbers from 4 and below like:
print(-2.989 + 4)
1.0111

print(-2.989 + 3)
0.01112

print(-2.989 + 1)
-1.9889

Numbers above 4 seam to work fine

--
components: Windows
files: python error.jpg
messages: 373465
nosy: Svabo, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Wrong subtraction calculations
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file49313/python error.jpg

___
Python tracker 
<https://bugs.python.org/issue41269>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1256] subprocess Popen wait() function hangs when stdout is > 20480

[Ivan Pozdeev]

Ivan Pozdeev added the comment:

I suggest adding this as a note to the subprocess module documentation instead. 
The "17.1.2 Popen Objects" section seems to be the right place.

--
nosy: +Vano

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1256>
__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10259] Entry text not set if both 'Font' and 'fg' are set

[Ivan Razumov]

New submission from Ivan Razumov :

OS: Windows 7 x86
Python: 2.6.4

An Entry with both Font and Foreground properties changed (i.e. not OS-default) 
does not display text set with textvariable.set method. 

Attached an example of such behavior.

--
components: Tkinter
files: Project5.py
messages: 120030
nosy: iarspider
priority: normal
severity: normal
status: open
title: Entry text not set if both 'Font' and 'fg' are set
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file19441/Project5.py

___
Python tracker 
<http://bugs.python.org/issue10259>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10259] Entry text not set if all of 'Font', 'Foreground' and 'Align' are set

[Ivan Razumov]

Changes by Ivan Razumov :


--
title: Entry text not set if both 'Font' and 'fg' are set -> Entry text not set 
if all of 'Font', 'Foreground' and 'Align' are set

___
Python tracker 
<http://bugs.python.org/issue10259>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10259] Entry text not set if all of 'Font', 'Foreground' and 'Align' are set

[Ivan Razumov]

Ivan Razumov  added the comment:

The bug only appears if "Align" is not "Left".

--

___
Python tracker 
<http://bugs.python.org/issue10259>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10259] Entry text not set if all of 'Font', 'Foreground' and 'Justify' are set

[Ivan Razumov]

Changes by Ivan Razumov :


--
title: Entry text not set if all of 'Font', 'Foreground' and 'Align' are set -> 
Entry text not set if all of 'Font', 'Foreground' and 'Justify' are set

___
Python tracker 
<http://bugs.python.org/issue10259>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10259] Entry text not set if all of 'Font', 'Foreground' and 'Justify' are set

[Ivan Razumov]

Ivan Razumov  added the comment:

Typo: align -> Justify

--

___
Python tracker 
<http://bugs.python.org/issue10259>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10259] Entry text not set if all of 'Font', 'Foreground' and 'Justify' are set

[Ivan Razumov]

Ivan Razumov  added the comment:

The bug doesn't seem to be Windows-specific - tested on Ubuntu 10.10 (Python 
2.6.6)

--

___
Python tracker 
<http://bugs.python.org/issue10259>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11703] Bug in python >= 2.7 with urllib2 fragment

[Ivan Ivanenko]

New submission from Ivan Ivanenko :

result = urllib.urlopen("http://docs.python.org/library/urllib.html#OK";)
print result.geturl()

result = urllib2.urlopen("http://docs.python.org/library/urllib.html#OK";)
print result.geturl()

Python 2.6 returns:
"http://docs.python.org/library/urllib.html#OK";
"http://docs.python.org/library/urllib.html#OK";

Python 2.7 returns:
"http://docs.python.org/library/urllib.html#OK";
"http://docs.python.org/library/urllib.html";

2to3 -w test.py
Python 3 returns:
"http://docs.python.org/library/urllib.html";
"http://docs.python.org/library/urllib.html";

I expect geturl() result with "#OK" in all cases

--
components: Library (Lib)
messages: 132423
nosy: Ivan.Ivanenko
priority: normal
severity: normal
status: open
title: Bug in python >= 2.7 with urllib2 fragment
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

___
Python tracker 
<http://bugs.python.org/issue11703>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11703] Bug in python >= 2.7 with urllib2 fragment

[Ivan Ivanenko]

Ivan Ivanenko  added the comment:

Santa4nt, I think you also need to check case with Redirect Response URL:

print urllib2.urlopen("http://16.foobnix-cms.appspot.com/test_base";).geturl()

python 2.6 returns OK
http://16.foobnix-cms.appspot.com/test_redirect#json={value:'OK'}

python 2.7 returns KO
http://16.foobnix-cms.appspot.com/test_redirect

--

___
Python tracker 
<http://bugs.python.org/issue11703>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11050] email.utils.getaddresses behavior contradicts RFC2822

[Ivan Egorov]

New submission from Ivan Egorov :

email.utils.getaddresses behaves wrong in following folding cases (outer single 
quote is not a part of value): 
'"A\r\n (B)" '
'(A\r\n C) '

The misbehavior occurs in at least 2.6, 2.7 and branches/py3k.

Both these strings are RFC 2822 compliant, but current getaddresses() 
implementation misbehaves on 'quoted-string' and 'comment' containing CRLF.

Following references the related RFC sections:
http://tools.ietf.org/html/rfc2822#section-3.4
http://tools.ietf.org/html/rfc2822#section-3.2.5

Attachment contains tests and patch for the case.

--
components: Library (Lib)
files: email.utils.getaddresses.patch
keywords: patch
messages: 127357
nosy: Ivan.Egorov
priority: normal
severity: normal
status: open
title: email.utils.getaddresses behavior contradicts RFC2822
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file20590/email.utils.getaddresses.patch

___
Python tracker 
<http://bugs.python.org/issue11050>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37838] typing.get_type_hints not working with forward-declaration and decorated functions

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

> Using `__wrapped__` if present sounds like a good idea.

Yeah, I like this idea, this will likely cover most use cases (since most 
people actually do use @wraps).

--

___
Python tracker 
<https://bugs.python.org/issue37838>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37838] typing.get_type_hints not working with forward-declaration and decorated functions

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


--
keywords: +newcomer friendly

___
Python tracker 
<https://bugs.python.org/issue37838>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37835] typing.get_type_hints wrong namespace for forward-declaration of inner class

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


--
nosy: +levkivskyi

___
Python tracker 
<https://bugs.python.org/issue37835>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37835] typing.get_type_hints wrong namespace for forward-declaration of inner class

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

Thanks for reporting!

I spent some time thinking about this and I can't find any reasonable way of 
doing this, sorry. Anyway, let's keep this open, maybe someone will come up 
with a proposal.

--

___
Python tracker 
<https://bugs.python.org/issue37835>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28556] typing.py upgrades

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


--
pull_requests: +15104
pull_request: https://github.com/python/cpython/pull/15396

___
Python tracker 
<https://bugs.python.org/issue28556>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37920] Support subscripting os.PathLike and make it valid at runtime

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

There is an (old) similar proposal https://github.com/python/typing/issues/402 
btw.

Taking into account that this can be made only in 3.9, what is the benefit over 
``from __future__ import annotations`` (that one can use already) do you see?

IMO there are only rare cases of type aliases and base classes, so I don't see 
much benefit. Also making it generic will require importing ``typing`` from 
``os`` which may make it slower to import (``typing`` is a really heavy module, 
in particular because it imports many other modules).

--

___
Python tracker 
<https://bugs.python.org/issue37920>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37923] Combining typing.get_type_hints and inspect.signature

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

Somewhat related to https://bugs.python.org/issue37496

--
nosy: +eric.snow, yselivanov

___
Python tracker 
<https://bugs.python.org/issue37923>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37948] get_type_hints fails if there are un-annotated fields in a dataclass

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

It looks like https://github.com/python/cpython/pull/9518 will fix also this 
one.

--
nosy: +levkivskyi

___
Python tracker 
<https://bugs.python.org/issue37948>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37835] typing.get_type_hints wrong namespace for forward-declaration of inner class

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

> Maybe any upcoming python version could store this information in __local__ ? 
> So maybe we could clone this ticket to the python core in order to address 
> this?

I would say it is a too big change, and it is unlikely to happen only for the 
reason like this issue.

> Why is the own class not always inside the __globals__ list of the methods? 
> Is there a reason? Or is this just a missing feature of the python-core?

Because this is a reference to the actual module global namespace. If the class 
defined inside another function, it is not the module namespace.

You can probably use the metaclass workaround, but note that it will actually 
modify the module globals (since __globals__ is not a copy).

--

___
Python tracker 
<https://bugs.python.org/issue37835>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37835] typing.get_type_hints wrong namespace for forward-declaration of inner class

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


--
Removed message: https://bugs.python.org/msg350980

___
Python tracker 
<https://bugs.python.org/issue37835>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37835] typing.get_type_hints wrong namespace for forward-declaration of inner class

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

(Sorry for typos, fixed now.)

> Maybe any upcoming python version could store this information in __local__ ? 
> So maybe we could clone this ticket to the python core in order to address 
> this?

I would say it is a too big change, and it is unlikely to happen only for the 
reason like this issue.

> Why is the own class not always inside the __globals__ list of the methods? 
> Is there a reason? Or is this just a missing feature of the python-core?

Because this is a reference to the actual module global namespace. If the class 
is defined inside another function, it is not in the module namespace.

You can probably use the metaclass workaround, but note that it will actually 
modify the module globals (since __globals__ is not a copy).

--

___
Python tracker 
<https://bugs.python.org/issue37835>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38008] ContextManager and AsyncContextManager protocols can't be subclassed

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

> I'd like to take a stab at putting up a patch for this

Great, thanks! Go ahead and try it.

--
nosy: +levkivskyi

___
Python tracker 
<https://bugs.python.org/issue38008>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37835] typing.get_type_hints wrong namespace for forward-declaration of inner class

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

> I anyway always wonder, why functions, which are methods, do not hold a 
> reference to the class, which they belong to.

This may indeed be a useful feature on its own, but it will also require a much 
more wider discussion.

--

___
Python tracker 
<https://bugs.python.org/issue37835>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38008] ContextManager and AsyncContextManager protocols can't be subclassed

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:


New changeset 692a0dc91597b7fb350383b633dc4d044cbd360e by Ivan Levkivskyi 
(Divij Rajkumar) in branch 'master':
bpo-38008: Move builtin protocol whitelist to mapping instead of list (GH-15647)
https://github.com/python/cpython/commit/692a0dc91597b7fb350383b633dc4d044cbd360e


--

___
Python tracker 
<https://bugs.python.org/issue38008>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38008] ContextManager and AsyncContextManager protocols can't be subclassed

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


--
components: +Library (Lib)
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 2.7, Python 3.5, Python 3.6, Python 3.7

___
Python tracker 
<https://bugs.python.org/issue38008>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37953] Fix ForwardRef equality checks

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:


New changeset e082e7cbe4a934b86f7a07354d97d4e14a9dd46a by Ivan Levkivskyi 
(plokmijnuhby) in branch 'master':
bpo-37953: Fix ForwardRef hash and equality checks (GH-15400)
https://github.com/python/cpython/commit/e082e7cbe4a934b86f7a07354d97d4e14a9dd46a


--

___
Python tracker 
<https://bugs.python.org/issue37953>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37953] Fix ForwardRef equality checks

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue37953>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28556] typing.py upgrades

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


--
pull_requests: +15808
pull_request: https://github.com/python/cpython/pull/16204

___
Python tracker 
<https://bugs.python.org/issue28556>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28556] typing.py upgrades

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:


New changeset 81528ba2e81c39f4d6bca5b785e818c7d08b8501 by Ivan Levkivskyi in 
branch 'master':
bpo-28556: Update the opening note in typing docs (GH-16204)
https://github.com/python/cpython/commit/81528ba2e81c39f4d6bca5b785e818c7d08b8501


--

___
Python tracker 
<https://bugs.python.org/issue28556>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38166] ast identifies incorrect column for compound attribute lookups

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

As Serhiy explained, there is no bug here, _potentially_ we could change AST so 
that attribute name (i.e. "b" in "a.b") is wrapped in a special node holding 
the position info (similar to ``ast.arg``), but it is a breaking change and is 
not worth it. You can re-open your issue on PyLint tracker.

--
nosy: +levkivskyi
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue38166>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38290] cleanup ababstractproperty in typing.py

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8

___
Python tracker 
<https://bugs.python.org/issue38290>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38291] Unclear status of the typing.io and typing.re pseudo-modules in docs and runtime

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

Guido, what is your final opinion on this?

--
nosy: +gvanrossum, levkivskyi

___
Python tracker 
<https://bugs.python.org/issue38291>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38298] Base class of generic type has wrong `cls` argument in classmethods

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

Yes, it is unfortunately hard to support with the new design. Also note that 
this was previously discussed at https://github.com/python/typing/issues/629. I 
think we can close this, since the other issue has more context.

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue38298>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38352] In typing docs, note explicit import needed for IO and Pattern/Match

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

> So, my request is: In the sections for the IO/TextIO/BinaryIO and 
> Pattern/Match classes, include text warning the user that these types are not 
> imported when you do `from typing import *`.

I don't think this should really be a warning, probably just a note, but 
otherwise I totally agree. Would you like to make a PR?

--

___
Python tracker 
<https://bugs.python.org/issue38352>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38348] Make python -m ast more configurable

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


--
nosy: +levkivskyi

___
Python tracker 
<https://bugs.python.org/issue38348>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38396] ast.literal_eval doesn't give information about node except the type of it

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

The downside however is that exception messages can become very long. So I am 
not sure we should change this.

--
nosy: +serhiy.storchaka

___
Python tracker 
<https://bugs.python.org/issue38396>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32996] Improve What's New in 3.7

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:


New changeset d47f0dd2e85ce032aebfedbde18cdb2e728fa79f by Ivan Levkivskyi (M. 
Eric Irrgang) in branch 'master':
bpo-32996: Documentation fix-up. (GH-16646)
https://github.com/python/cpython/commit/d47f0dd2e85ce032aebfedbde18cdb2e728fa79f


--
nosy: +levkivskyi

___
Python tracker 
<https://bugs.python.org/issue32996>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38348] Make python -m ast more configurable

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

I don't have any strong opinion either way, so it looks like we need to wait 
until someone else will ask for this.

--

___
Python tracker 
<https://bugs.python.org/issue38348>
___
___
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

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


--
nosy: +levkivskyi

___
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

[issue38424] typing.Generator shorthand

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


--
nosy: +levkivskyi

___
Python tracker 
<https://bugs.python.org/issue38424>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38446] Ambiguous signature for builtins.__build_class__

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


--
assignee:  -> docs@python
components: +Documentation
nosy: +docs@python

___
Python tracker 
<https://bugs.python.org/issue38446>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38424] typing.Generator shorthand

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

If you would like to propose a doc fix, then please go ahead and make a PR.

--

___
Python tracker 
<https://bugs.python.org/issue38424>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38424] typing.Generator shorthand

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


--
assignee:  -> docs@python
components: +Documentation -Library (Lib)
nosy: +docs@python

___
Python tracker 
<https://bugs.python.org/issue38424>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38424] typing.Generator shorthand

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

Actually Serhiy is right, I just checked and found this sentence:
```
Alternatively, annotate your generator as having a return type of either 
Iterable[YieldType] or Iterator[YieldType]
```

--
resolution:  -> works for me
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue38424>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38459] typing: Classes that inherit `Generic[...]` indirectly aren't considered generic.

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

The docs for typing module are clear about this:
```
Using a generic class without specifying type parameters assumes Any for each 
position.
```
There is also an example involving a base class.

--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue38459>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28556] typing.py upgrades

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


--
pull_requests: +16320
pull_request: https://github.com/python/cpython/pull/16743

___
Python tracker 
<https://bugs.python.org/issue28556>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38467] Misspelled argument names for typing.get_origin and get_args

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

I think adjusting the docs would be less disruptive than changing 
implementation. Would you like to make a PR?

--

___
Python tracker 
<https://bugs.python.org/issue38467>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38467] Misspelled argument names for typing.get_origin and get_args

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:


New changeset fdfe2833ace93021278fe4c41c40e1d08d70abf9 by Ivan Levkivskyi 
(Sebastian Rittau) in branch 'master':
bpo-38467: Fix argument name of typing functions (GH-16753)
https://github.com/python/cpython/commit/fdfe2833ace93021278fe4c41c40e1d08d70abf9


--

___
Python tracker 
<https://bugs.python.org/issue38467>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38467] Misspelled argument names for typing.get_origin and get_args

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue38467>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38525] Strange reversed dict behavior

[Ivan Bykov]

New submission from Ivan Bykov :

Python 3.8.0 (tags/v3.8.0:fa919fd, Oct 14 2019, 19:37:50) [MSC v.1916 64 bit 
(AMD64)] on win32
Type "help", "copyright", "credits" or "license()" for more information.
>>> list(reversed({1: 1}))
[1]
>>> list(reversed({}))

 RESTART: Shell 
>>>

--
components: Interpreter Core
messages: 354931
nosy: ivb
priority: normal
severity: normal
status: open
title: Strange reversed dict behavior
type: behavior
versions: Python 3.8

___
Python tracker 
<https://bugs.python.org/issue38525>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38605] [typing] PEP 563: Postponed evaluation of annotations: enable it by default before Python 4.0

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

IMO 3.10 would be better, since 3.9 would be too soon (it would be like a 
schedule for a normal deprecation).

Also if we are really doing this, I think it is better to announce this soon.

Also we should try to fix relevant issues related to string annotations (in 
typing and dataclasses), like https://github.com/python/typing/issues/508, 
https://github.com/python/typing/issues/574, 
https://bugs.python.org/issue37838, https://bugs.python.org/issue34776 and 
https://bugs.python.org/issue37948.

--
nosy: +gvanrossum

___
Python tracker 
<https://bugs.python.org/issue38605>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43528] "connect_read_pipe" raises errors on Windows for STDIN

[Ivan Kravets]

New submission from Ivan Kravets :

Hi there,

It seems that "connect_read_pipe" is not implemented in ProactorEventLoop. Does 
it make sense to update docs in these places?
- https://docs.python.org/3/library/asyncio-platforms.html#windows
- https://docs.python.org/3/library/asyncio-eventloop.html#working-with-pipes 

Or, this is a bug?

# The code to reproduce

```
import asyncio
import sys


async def read_stdin():
reader = asyncio.StreamReader()
protocol = asyncio.StreamReaderProtocol(reader)
await asyncio.get_running_loop().connect_read_pipe(lambda: protocol, 
sys.stdin)
while True:
line = await reader.readline()
print("stdin > ", line)


async def main():
task = asyncio.create_task(read_stdin())
await asyncio.sleep(5)
task.cancel()


if __name__ == "__main__":
asyncio.run(main())
```

P.S: The "loop.add_reader()" raises "NotImplementedError" which is clear 
according to the docs.

Thanks in advance!

# Log

```
C:\Users\USER>.platformio\python3\python.exe test.py
Exception in callback _ProactorReadPipeTransport._loop_reading()
handle: 
Traceback (most recent call last):
  File "C:\Users\USER\.platformio\python3\lib\asyncio\proactor_events.py", line 
299, in _loop_reading
self._read_fut = self._loop._proactor.recv(self._sock, 32768)
  File "C:\Users\USER\.platformio\python3\lib\asyncio\windows_events.py", line 
445, in recv
self._register_with_iocp(conn)
  File "C:\Users\USER\.platformio\python3\lib\asyncio\windows_events.py", line 
718, in _register_with_iocp
_overlapped.CreateIoCompletionPort(obj.fileno(), self._iocp, 0, 0)
OSError: [WinError 6] The handle is invalid

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Users\USER\.platformio\python3\lib\asyncio\events.py", line 80, in 
_run
self._context.run(self._callback, *self._args)
  File "C:\Users\USER\.platformio\python3\lib\asyncio\proactor_events.py", line 
309, in _loop_reading
self._fatal_error(exc, 'Fatal read error on pipe transport')
  File "C:\Users\USER\.platformio\python3\lib\asyncio\proactor_events.py", line 
131, in _fatal_error
self._force_close(exc)
  File "C:\Users\USER\.platformio\python3\lib\asyncio\proactor_events.py", line 
134, in _force_close
if self._empty_waiter is not None and not self._empty_waiter.done():
AttributeError: '_ProactorReadPipeTransport' object has no attribute 
'_empty_waiter'
Exception ignored in: 
Traceback (most recent call last):
  File "C:\Users\USER\.platformio\python3\lib\asyncio\proactor_events.py", line 
116, in __del__
self.close()
  File "C:\Users\USER\.platformio\python3\lib\asyncio\proactor_events.py", line 
108, in close
self._loop.call_soon(self._call_connection_lost, None)
  File "C:\Users\USER\.platformio\python3\lib\asyncio\base_events.py", line 
746, in call_soon
self._check_closed()
  File "C:\Users\USER\.platformio\python3\lib\asyncio\base_events.py", line 
510, in _check_closed
raise RuntimeError('Event loop is closed')
RuntimeError: Event loop is closed
```

--
components: asyncio
messages: 388919
nosy: asvetlov, ivankravets, yselivanov
priority: normal
severity: normal
status: open
title: "connect_read_pipe" raises errors on Windows for STDIN
versions: Python 3.9

___
Python tracker 
<https://bugs.python.org/issue43528>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39093] tkinter objects garbage collected from non-tkinter thread cause crash

[Ivan Naydonov]

Ivan Naydonov  added the comment:

I recently faced this problem and this bug was very helpful to understand whats 
going on. Especially the comment about a problem being a tkinter reference 
leaked to a thread.

Most of the discussions in google results doesn't mention it (or at least it's 
not easy to find).

I understand that fixing this problem on tkinter side won't be easy (if even 
possible), but I think it would be very useful for everyone to extend error 
message to explain the problem and ideally add some information that can help 
identify problematic reference - at least the name of the thread it was deleted 
from.

--
nosy: +samogot

___
Python tracker 
<https://bugs.python.org/issue39093>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39093] tkinter objects garbage collected from non-tkinter thread cause crash

[Ivan Naydonov]

Ivan Naydonov  added the comment:

I recently faced this problem and this bug was very helpful to understand whats 
going on. Especially the comment about a problem being a tkinter reference 
leaked to a thread.

Most of the discussions in google results doesn't mention it (or at least it's 
not easy to find).

I understand that fixing this problem on tkinter side won't be easy (if even 
possible), but I think it would be very useful for everyone to extend error 
message to explain the problem and ideally add some information that can help 
identify problematic reference - at least the name of the thread it was deleted 
from.

--
nosy: +samogot

___
Python tracker 
<https://bugs.python.org/issue39093>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39093] tkinter objects garbage collected from non-tkinter thread cause crash

[Ivan Naydonov]

Ivan Naydonov  added the comment:

I recently faced this problem and this bug was very helpful to understand whats 
going on. Especially the comment about a problem being a tkinter reference 
leaked to a thread.

Most of the discussions in google results doesn't mention it (or at least it's 
not easy to find).

I understand that fixing this problem on tkinter side won't be easy (if even 
possible), but I think it would be very useful for everyone to extend error 
message to explain the problem and ideally add some information that can help 
identify problematic reference - at least the name of the thread it was deleted 
from.

--
nosy: +samogot

___
Python tracker 
<https://bugs.python.org/issue39093>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39093] tkinter objects garbage collected from non-tkinter thread cause crash

[Ivan Naydonov]

Ivan Naydonov  added the comment:

I recently faced this problem and this bug was very helpful to understand whats 
going on. Especially the comment about a problem being a tkinter reference 
leaked to a thread.

Most of the discussions in google results doesn't mention it (or at least it's 
not easy to find).

I understand that fixing this problem on tkinter side won't be easy (if even 
possible), but I think it would be very useful for everyone to extend error 
message to explain the problem and ideally add some information that can help 
identify problematic reference - at least the name of the thread it was deleted 
from.

--
nosy: +samogot

___
Python tracker 
<https://bugs.python.org/issue39093>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44293] PEP 585 breaks inspect.isclass

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

Btw this reminds me I should make a PyPI release of typing_inspect (last 
release was May 2020), hopefully will make a release on this weekend.

--

___
Python tracker 
<https://bugs.python.org/issue44293>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44293] PEP 585 breaks inspect.isclass

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

Uploaded typing_inspect 0.7.0 to PyPI (it should work with Python 3.9 hopefully)

--

___
Python tracker 
<https://bugs.python.org/issue44293>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44659] Remove Ivan from list of typing experts

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

You can remove me from both.

--

___
Python tracker 
<https://bugs.python.org/issue44659>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44659] Remove Ivan from list of typing experts

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

Thank you everyone! I hope our paths will cross someday.

--

___
Python tracker 
<https://bugs.python.org/issue44659>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38902] image/webp support in mimetypes

[Ivan Borshchov]

Ivan Borshchov  added the comment:

Very uncomfortable to work with webp without it And webp is now pretty hyped 
due to Google's Core Web Vitals update. 
E.g. pretty popular Django Storages relies on python native mimetype module, so 
because of this bug it always sets default application/octet-stream to AWS 
headers, so in the end when users click Open Image on new tab they get webp 
downloaded 🤣🤣🤣
 

https://github.com/jschneier/django-storages/blob/6071ac3410ee6ecd498b5691f1b45d376374bffc/storages/backends/s3boto.py#L391

--
nosy: +ivan2

___
Python tracker 
<https://bugs.python.org/issue38902>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40469] TimedRotatingFileHandler rotating on use not time

[Ivan Marton]

Ivan Marton  added the comment:

The assumed behaviour of TimedRotatingFileHandler is to rotate log files older 
than configured. Even when the script is executed multiple times.

self.rolloverAt (the variable that defines when the rollover should be 
performed) is set after each rollover and right after initializing the file 
handler instance.

If the instance is initialized once (like in your script) and a rollover is 
performed without having the object destroyed, the logger works fine, the 
rollover is done and the next round is scheduled properly.

The case is not so lucky if the script runs multiple time or the logger itself 
is initialized multiple times during one execution. In this case, since the 
MTIME is read each time when the TimedRotatingFileHandler's init is called, and 
the file is modified (by having a new line added to the end of the file). The 
next execution will read the new MTIME and will never perform any rollover.

I've slightly modified your example script to demonstrate these use-cases.

Example 1: Log a single line with the script, but execute it multiple times 
with delays between the execution!
In bash: for i in {1..101}; do python log_40469_single.py $i; sleep 30; done

Example 2: Log multiple lines, but reinitiate the logger object between the 
events!
See log_40469_new_instance.py

--
Added file: https://bugs.python.org/file50208/log_40469_new_instance.py

___
Python tracker 
<https://bugs.python.org/issue40469>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40469] TimedRotatingFileHandler rotating on use not time

[Ivan Marton]

Change by Ivan Marton :


Added file: https://bugs.python.org/file50209/log_40469_single.py

___
Python tracker 
<https://bugs.python.org/issue40469>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40469] TimedRotatingFileHandler rotating on use not time

[Ivan Marton]

Ivan Marton  added the comment:

Well, there is nothing in the documentation that would say the logrotation can 
be only performed by continously running scripts, thats why. :)

There are scripts or even daemons written in Python that need to be restarted 
from time to time. If the logrotate period is greater than restart period the 
log files will never be rotated, however they could be.

We were looking for something that works like the logrotate do, but without 
involving any external logic, but the one written in python. And 
TimedLogrotateHandler appears to be one of those, unless it checks the MTIME of 
the files instead of the CTIME.

What is the logic behind checking the MTIME instead of CTIME when one is 
calculating the age of a file when tries to calculate whether it has to be 
rotated or not? If the only purpose of this initial rollover calculation would 
be to start a predefined long period (as you suggest), now() (time of 
execution) should used instead and no file attribute should be involved. From 
the code I have to assume that the original author also tried to prepare for 
the cases where the execution is interrupted and/or restarted and (s)he wanted 
the TimedLogrotateHandler to be resumed where it was during the previous 
execution. Dnn't you agree?

--

___
Python tracker 
<https://bugs.python.org/issue40469>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40469] TimedRotatingFileHandler rotating on use not time

[Ivan Marton]

Ivan Marton  added the comment:

> Well, what's the need to rotate based on time when you just run scripts 
> sporadically or they're very short-lived? Not trying to argue, just trying to 
> understand.
> Yes, but generally daemons are long-lived relative to the rotation interval, 
> aren't they? "From time to time" certainly implies that to me.

In one of our use-cases, where I faced with this bug/behaviour of 
TimedRotatingFileHandler, we are using it in a daemon for daily logrotate. The 
aim is to have the logs separated day by day, just like the majority of our 
other components running on a linux. We've just realized that some days are 
missing from the series of logs and the investigation led to the service 
restart and the MTIME checking that we are talking about here. When a logger is 
configured to rotate daily one just simply assume that it will rotate daily 
regardless the daemon restart. (As en extreme(?) example, when a the system - 
and the daemon of course - is restarted each day - or just never running for a 
whole day - and btw it logs often, the log file won't be ever rotated and can 
inrease over every limits.)

I've quickly googled around and found someone who execute some logic from cron 
and expects the loghandler to rotate his files, that wouldn't happened for the 
same reason:
https://stackoverflow.com/questions/30569164/logging-handler-timedrotatingfilehandler-never-rotates-the-log

> I just checked - the relevant code (using MTIME) was added in 2010, as a fix 
> for bpo-8117 - around the time that Python 2.6 was released.
As I understand bpo-8117, the goal was to do the rollover even after script 
restarts. (To be frank, only an extreme case was mentioned in the issue opener 
entry, when the rollover period had been reached when the script wasn't 
running.) I believe for this purpose MTIME wasn't the best choice, but using 
CTIME instead would make the script do what is expected to.

> I take it you mean TimedRotatingFileHandler. Certainly it assumes that the 
> script might be restarted, which is why it opens the file in append mode.

> If the computation using MTIME were changed to use CTIME, that would be a 
> behaviour change, which could conceivably break someone's code that relied on 
> current behaviour (unlikely, but you just never know). I've no other 
> objection to using CTIME rather than MTIME - perhaps I'm just being 
> hyper-cautious about breakage?

You are far better and more experienced in maintaining widely used opensource 
codebases so I wouldn't argue with you, but... :)

- In case of scripts that create the log file for themselves the change would 
have no effect.
- In case of scripts that are using already existing files for logging (by 
opening them for append) could change the behaviour, but just slighly. The 
first rollover would happen before adding the first new log line if the file 
age reached the configured time, and not when the age of last log line written 
to the file before having the script started reached the same value. No further 
rotation would be effected.

I _believe_ no one expects the current initial behaviour in case of resumed log 
files, and for sure, the documentation doesn't cover this part so I don't know 
how to proceed.

I _believe_ (again) that changing the behaviour wouldn't break the script 
outside, but rather would help them working the way how the developers 
originally assumed they did.

--

___
Python tracker 
<https://bugs.python.org/issue40469>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45519] Minor docstring improvement in __contains__

[Ivan Savov]

New submission from Ivan Savov :

Currently,

```
>>> help(list.__contains__)
```
returns
```
Help on wrapper_descriptor:
__contains__(self, key, /)
Return key in self.
```

Which is a conceptual circular reference,
since `in` is implemented by `__contains__`.

Changing the help string to

"Return True if key in self."

would fix this.

--
assignee: docs@python
components: Documentation
messages: 404236
nosy: Ivan.Savov, docs@python
priority: normal
severity: normal
status: open
title: Minor docstring improvement in __contains__
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 
3.9

___
Python tracker 
<https://bugs.python.org/issue45519>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45519] Minor docstring improvement in __contains__

[Ivan Savov]

Change by Ivan Savov :


--
keywords: +patch
pull_requests: +27314
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/29043

___
Python tracker 
<https://bugs.python.org/issue45519>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33838] Very slow upload with http.client on Windows when setting timeout

[Ivan Konovalov]

Change by Ivan Konovalov :


--
versions: +Python 3.10, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue33838>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45438] inspect not capturing type annotations created by __class_getitem__

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

> Was it mistake to make isinstance(list[int], type) returning True?

What was the motivation for this? At first glance returning True looks wrong.

--

___
Python tracker 
<https://bugs.python.org/issue45438>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43878] ./configure fails on Apple Silicon with coreutils uname

[Ivan Pozdeev]

Ivan Pozdeev  added the comment:

> Someone nonchalantly updated these in 
> https://github.com/python/cpython/commit/2fc857a5721a5b42bcb696c9cae1bbcc82a91b17
>  so this bug is now fixed

That PR only goes into 3.11. While this ticket claims to have fixed the problem 
for 3.10 as well.

Should that PR be backported? Alternatively, 
https://github.com/python/cpython/pull/25450 should be merged, but into `3.10` 
instead of `master`.

--
nosy: +ivan.pozdeev.gm

___
Python tracker 
<https://bugs.python.org/issue43878>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43799] OpenSSL 3.0.0: define OPENSSL_API_COMPAT 1.1.1

[Ivan Pozdeev]

Ivan Pozdeev  added the comment:

@christian.heimes https://github.com/python/cpython/pull/25481 also needs 
backporting to 3.9 and 3.8.

A Pyenv user has been affected by the "implicit declaration of function 
‘SSLv3_method’" compliation error that it fixes in 3.9.9: 
https://github.com/pyenv/pyenv/issues/2181

--
nosy: +ivan.pozdeev.gm

___
Python tracker 
<https://bugs.python.org/issue43799>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38756] Add generic versions of weakref types to typing module

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

We already have https://github.com/python/typing/issues/508 for "smart" 
`get_type_hints()` that would use LBYL. Also we had a similar discussion about 
PathLike, and ultimately decided not to make `typing` a place for generic 
versions of everything.

Finally, in view of PEP 585 some of these things may actually become 
subscriptable at runtime. So I propose to just close this issue.

--
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue38756>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37838] typing.get_type_hints not working with forward-declaration and decorated functions

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


--
pull_requests:  -16560

___
Python tracker 
<https://bugs.python.org/issue37838>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37838] typing.get_type_hints not working with forward-declaration and decorated functions

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


--
keywords:  -patch
stage: patch review -> needs patch

___
Python tracker 
<https://bugs.python.org/issue37838>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37838] typing.get_type_hints not working with forward-declaration and decorated functions

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

The PR was linked by mistake (it is for a different issue), so I unlinked it.

--

___
Python tracker 
<https://bugs.python.org/issue37838>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38782] Convert importlib.abc to use typing.Protocol

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


--
nosy: +levkivskyi

___
Python tracker 
<https://bugs.python.org/issue38782>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37948] get_type_hints fails if there are un-annotated fields in a dataclass

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

> I'm not sure what can be done with this. The problem is that the decorator 
> doesn't know what's in the caller's namespace. The type being added is 
> "typing.Any". If the caller doesn't import typing, then get_type_hints will 
> fail (as demonstrated here).

IIUC the main problem is that get_type_hints() fails even if typing is 
imported. I would expect this to work (just repeating the original example in a 
more compact form):

import dataclasses
import typing
A = dataclasses.make_dataclass('A', ['a_var'])
typing.get_type_hints(A)  # This currently crashes

Interestingly, if I use a very similar call that it works:

>>> typing.get_type_hints(A, globalns=globals())
{'a_var': typing.Any}

So the core of the issue is that the globals are identified incorrectly, and 
indeed if I look at the generated class it looks wrong:

>>> A.__module__
'types'  # Should be '__main__'

I think we should fix the ``__module__`` attribute of the dynamically generated 
dataclasses (for example the way it is done for named tuples).

Btw, https://github.com/python/cpython/pull/14166 may potentially fix the 
``__module__`` attribute here too.

--

___
Python tracker 
<https://bugs.python.org/issue37948>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38843] Document argparse behaviour when custom namespace object already has the field set

[Ivan Kurnosov]

New submission from Ivan Kurnosov :

At this moment it's impossible to explain the behaviour of this script using 
documentation.

Given it was explicitly coded to behave like that - it should be somehow noted 
in the documentation, that as long as a `CliArgs.foo` field has a default value 
set already - it won't be overwritten with a default argparse argument value.


```
import argparse

class CliArgs(object):
foo: str = 'not touched'


parser = argparse.ArgumentParser()
parser.add_argument('--foo', default='bar')

args = CliArgs()
parser.parse_args(namespace=args)
print(args.foo) # 'not touched'

print(parser.parse_args()) # 'bar'
```

--
assignee: docs@python
components: Documentation
messages: 356939
nosy: docs@python, zerkms
priority: normal
severity: normal
status: open
title: Document argparse behaviour when custom namespace object already has the 
field set

___
Python tracker 
<https://bugs.python.org/issue38843>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38843] Document argparse behaviour when custom namespace object already has the field set

[Ivan Kurnosov]

Ivan Kurnosov  added the comment:

> I have not seen many questions about the use of a preexisting namespace 
> object (here or on StackOverflow)

as typing was added to the language natively - it should become more and more 
frequently used.

I personally see no reason anymore to NOT use a custom namespace: typed 
arguments object is x100 times better than untyped one.

--

___
Python tracker 
<https://bugs.python.org/issue38843>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36287] Make ast.dump() not output optional default fields

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

No objections from me assuming you are going forward along the way proposed by 
Serhiy (i.e. only skip values for certain fields if value is the default, not a 
blanket skip for all Nones and empty lists).

--

___
Python tracker 
<https://bugs.python.org/issue36287>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38870] Expose ast.unparse in the ast module

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


--
nosy: +levkivskyi

___
Python tracker 
<https://bugs.python.org/issue38870>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37838] typing.get_type_hints not working with forward-declaration and decorated functions

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:


New changeset 0aca3a3a1e68b4ca2d334ab5255dfc267719096e by Ivan Levkivskyi 
(benedwards14) in branch 'master':
bpo-37838: get_type_hints for wrapped functions with forward reference 
(GH-17126)
https://github.com/python/cpython/commit/0aca3a3a1e68b4ca2d334ab5255dfc267719096e


--

___
Python tracker 
<https://bugs.python.org/issue37838>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37838] typing.get_type_hints not working with forward-declaration and decorated functions

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue37838>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38878] os.PathLike subclasshook causes subclass checks true on abstract implementation

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

> So why is it bad that in the example class B is considered a "subclass" of 
> os.PathLike by implementing the protocol?

This is not bad, my understanding of the problem is that currently B is 
considered a subclass of A, while the latter should not be structural.

To give an analogy with PEP 544 (sorry, this is my favourite one :-)) consider 
this:

class P(Protocol):
def some(self): ...

class C:
def some(self): ...

Here C is obviously a "subclass" of P, but:

class Bad(P):  # <- this is _no_ a protocol, just a nominal class
pass   # explicitly subclassing P

class Good(P, Protocol):  # <- this is a subprotocol that
pass  # happened to be identical to P

So here C is a "subclass" of Good, but not a "subclass" of Bad.

--

___
Python tracker 
<https://bugs.python.org/issue38878>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38834] TypedDict: no way to tell which (if any) keys are optional at runtime

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue38834>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38908] Troubles with @runtime_checkable protocols

[Ivan Levkivskyi]

New submission from Ivan Levkivskyi :

The PEP 544 specifies that:

A protocol can be used as a second argument in isinstance() and issubclass() 
only if it is explicitly opt-in by @runtime_checkable decorator.

It is not specified exactly whether this should be enforced by static type 
checkers or at runtime. Currently it is enforced in both cases: mypy flags this 
as error, and a TypeError is raised at runtime.

There is however a problem with current runtime implementation: abc and 
functools modules may call issubclass() on non-runtime checkable protocols if 
they appear as explicit superclasses. This is currently solved by a 
sys._getframe() hack in  typing module.

The problem is that current solution is incomplete. For example, the TypeError 
is not raised in the case of non-method protocols:

>>> class P(Protocol):
... x: int
... 
>>> 
>>> class C: ...
... 
>>> isinstance(C(), P)
False  # should be TypeError

I tried to fix it this morning but after an hour of attempts to tweak the 
existing hack I gave up. It looks like there are only two reasonable solutions:

* Don't enforce @typing.runtime_checkable at runtime, make it a 
type-checker-only feature (like @typing.final).
* Add a little helper to abc module that would skip classes in MRO for which 
C._is_protocol is True but C._is_runtime_protocol is False.

Any thoughts/preferences?

--
components: Library (Lib)
messages: 357400
nosy: gvanrossum, levkivskyi
priority: normal
severity: normal
status: open
title: Troubles with @runtime_checkable protocols
type: behavior
versions: Python 3.8, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue38908>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27501] Add typing.py class describing a PEP 3118 buffer object

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

Cross-ref to the typing issue https://github.com/python/typing/issues/593. It 
looks like there is some interest in this feature.

--

___
Python tracker 
<https://bugs.python.org/issue27501>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38978] Implement __class_getitem__ for Future, Task, Queue

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

I see the point in using ``__class_getitem__`` in Python classes too, we can 
probably start using a dummy method returning class object itself now. Also PEP 
585 already has a long list of candidates for "proper" ``__class_getitem__`` 
support. Maybe we can add these classes to that list? Maybe it would make sense 
to also have ``PathLike`` there?

--
nosy: +lukasz.langa

___
Python tracker 
<https://bugs.python.org/issue38978>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38979] ContextVar[str] should return ContextVar class, not None

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


--
keywords: +easy (C)

___
Python tracker 
<https://bugs.python.org/issue38979>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38947] dataclass defaults behave inconsistently for init=True/init=False when default is a descriptor

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


--
nosy: +levkivskyi

___
Python tracker 
<https://bugs.python.org/issue38947>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39035] Travis CI fail on backports: pyvenv not installed

[Ivan Pozdeev]

Ivan Pozdeev  added the comment:

I already diagnosed this in 
https://mail.python.org/archives/list/python-...@python.org/message/3Z4FNPEFTFTYDX6RYOQ54UKOVLQAWUEU/:

* https://travis-ci.org/python/cpython/jobs/616384134 looks for `pythonX.Y` but 
doesn't account for the fact that it could be Pyenv's stub
* https://travis-ci.org/python/cpython/builds/616384157 is trying to use Python 
version(s) that are not guaranteed to be preinstalled in the VM for all 
`language:`s.

I could fix this but I need to know what the hard requirements are to pick an 
optimal configuration.

* Is the (preinstalled only for `language: c`) `clang 7.0.0` required? Would 
3.4-4.0 (available from xenial distro) do?
* Is `xenial` required? Would `bionic` do? In bionic, clang 7 is available from 
distro.
* Which Python version needs to be preinstalled? Tools/ssl/multissltests.py 
says it's supposed to be compatible with 2.7 and 3.4-3.7. Options are, by 
decreasing "sum of flexibility+reliability":
  * use 3.5.1 or 2.7.12 from distro
  * hard require `language:python; python: 3.7` (then we cannot use custom 
`clang`)
  * use another pyenv-preinstalled version (there are also 3.6 and 2.7 that are 
supposed to be preinstalled but there might be none)

--
nosy: +__Vano

___
Python tracker 
<https://bugs.python.org/issue39035>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39035] Travis CI fail on backports: pyvenv not installed

[Ivan Pozdeev]

Ivan Pozdeev  added the comment:

> New changeset 94d2c8df1a7657015a2fcdb4c4d43392f91f8348 by Inada Naoki in 
> branch 'master':
bpo-39035: travis: Don't use beta group (GH-17602)

> INADA-san: do you want to close this issue since you pushed changes?

This may actually fix the problem.

`group: beta` is undocumented. It was required long ago once to try out a new 
feature but I've absolutely no idea what it does (and if it does anything) now. 
It's quite possible that it can give us some beta unsupported VM image.

--

___
Python tracker 
<https://bugs.python.org/issue39035>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39035] Travis CI fail on backports: pyvenv not installed

[Ivan Pozdeev]

Ivan Pozdeev  added the comment:

While we are at it, shall we enable build config validation 
(https://docs.travis-ci.com/user/build-config-validation)?

It would produce warnings for outdated keys like this.

--

___
Python tracker 
<https://bugs.python.org/issue39035>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39046] collections.abc.Reversible should not be a subclass of Hashable

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


--
nosy: +levkivskyi

___
Python tracker 
<https://bugs.python.org/issue39046>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39102] Increase Enum performance

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


--
nosy: +levkivskyi

___
Python tracker 
<https://bugs.python.org/issue39102>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38878] os.PathLike subclasshook causes subclass checks true on abstract implementation

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:


New changeset eae87e3e4e0cb9a0ce10c2e101acb6995d79e09c by Ivan Levkivskyi (Bar 
Harel) in branch 'master':
bpo-38878: Fix os.PathLike __subclasshook__ (GH-17336)
https://github.com/python/cpython/commit/eae87e3e4e0cb9a0ce10c2e101acb6995d79e09c


--

___
Python tracker 
<https://bugs.python.org/issue38878>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38878] os.PathLike subclasshook causes subclass checks true on abstract implementation

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:


New changeset 59d06b987db34cde8783e265709366d244c9e35b by Ivan Levkivskyi (Bar 
Harel) in branch '3.7':
[3.7] bpo-38878: Fix os.PathLike __subclasshook__ (GH-17336) (GH-17685)
https://github.com/python/cpython/commit/59d06b987db34cde8783e265709366d244c9e35b


--

___
Python tracker 
<https://bugs.python.org/issue38878>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38878] os.PathLike subclasshook causes subclass checks true on abstract implementation

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:


New changeset 0846e5d4603434c2bbf8a528677cf1ff3fe29b95 by Ivan Levkivskyi (Bar 
Harel) in branch '3.8':
[3.8] bpo-38878: Fix os.PathLike __subclasshook__ (GH-17336) (GH-17684)
https://github.com/python/cpython/commit/0846e5d4603434c2bbf8a528677cf1ff3fe29b95


--

___
Python tracker 
<https://bugs.python.org/issue38878>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38878] os.PathLike subclasshook causes subclass checks true on abstract implementation

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.6

___
Python tracker 
<https://bugs.python.org/issue38878>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com