[issue43893] typing.get_type_hints does not accept type annotations with leading whitespaces

[Jarry Shaw]

Jarry Shaw  added the comment:

Apparently static checkers like mypy doesn't rely on the 
`typing.get_type_hints` function to implement its type checking functions (as I 
had browsed through the code repo).

$ cat test.py
def foo(arg) -> ' str': ...
$ mypy test.py
Success: no issues found in 1 source file

If type checkers *think* this is acceptable, but the standard library doesn't, 
this can be some sort of inconsistency in my perspective.

As Saiyang Gou had suggested, I would rather prefer to change the behaviour of 
`compile` in `eval` mode to preserve the internal consistency of builtin 
functions and therefore to eliminate this *buggy* behaviour of 
`typing.get_type_hints`.

--

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

[issue43893] typing.get_type_hints does not accept type annotations with leading whitespaces

[Jarry Shaw]

Jarry Shaw  added the comment:

To me, I discovered this issue because of a typo in my code. And apparently, I 
do not suggest people will write their type annotations with leading 
whitespaces purposely.

Here’s another thing though: aligning the behaviour of the two builtin 
functions is good for us users, since logically, ``compile`` is just one 
*execution* step away from ``eval`` to my understanding.

--

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

[issue43893] typing.get_type_hints does not accept type annotations with leading whitespaces

[Jarry Shaw]

Jarry Shaw  added the comment:

> as discussed in https://bugs.python.org/issue41887

After some additional thoughts, I am thinking that changing the behaviour of 
``compile`` in ``'eval'`` mode directly might be a better idea, for consistency 
all over the builtin functions. 

Especially that it is a bit complex to decide if ``compile`` is called in 
``'eval'`` mode all over the code base which may need to patch with ``lstrip`` 
sanitisation.

--

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

[issue43893] typing.get_type_hints does not accept type annotations with leading whitespaces

[Jarry Shaw]

Change by Jarry Shaw :


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

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

[issue43893] typing.get_type_hints does not accept type annotations with leading whitespaces

[Jarry Shaw]

New submission from Jarry Shaw :

`typing.get_type_hints` does not accept type annotations (in string capsulated 
form) with leading whitespaces.

```
>>> def foo(arg) -> ' str': ...
>>> typing.get_type_hints(foo)
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/typing.py", line 519, in __init__
code = compile(arg, '', 'eval')
  File "", line 1
str
IndentationError: unexpected indent

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/local/lib/python3.9/typing.py", line 1448, in get_type_hints
value = ForwardRef(value)
  File "/usr/local/lib/python3.9/typing.py", line 521, in __init__
raise SyntaxError(f"Forward reference must be an expression -- got {arg!r}")
SyntaxError: Forward reference must be an expression -- got ' str'
```

When elaborating on this issue, an inconsistency of hevaiour between ``eval`` 
function call and ``compile`` in ``'eval'`` mode was also noticed, where the 
former accepts leading whitespaces and the latter does not.

However, as discussed in https://bugs.python.org/issue41887 , I would then 
propose manually ``lstrip`` whitespaces from the type annotations:

```
519c519
< code = compile(arg.lstrip(' \t'), '', 'eval')
---
> code = compile(arg, '', 'eval')
```

--
components: Library (Lib)
messages: 391434
nosy: jarryshaw
priority: normal
severity: normal
status: open
title: typing.get_type_hints does not accept type annotations with leading 
whitespaces
type: behavior
versions: Python 3.10

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

[issue26228] pty.spawn hangs on FreeBSD 9.3, 10.x

[Jarry Shaw]

Jarry Shaw  added the comment:

Chris' patch works on macOS 10.14 (Mojave); but after it terminates, tty 
attributes are not restored (new-lines are missing). btw, I've implemented a 
workaround library with solution through either `ps` command or `psutil` 
package, see `ptyng` on PyPI.

--
nosy: +jarryshaw

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

[issue34785] pty.spawn -- auto-termination after child process is dead (a zombie)

[Jarry Shaw]

Jarry Shaw  added the comment:

This issue is duplicated with issue26228, sorry.

--
stage: patch review -> resolved
status: pending -> closed

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

[issue34785] pty.spawn -- auto-termination after child process is dead (a zombie)

[Jarry Shaw]

Change by Jarry Shaw :


--
pull_requests: +8930
stage:  -> patch review

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

[issue34785] pty.spawn -- auto-termination after child process is dead (a zombie)

[Jarry Shaw]

New submission from Jarry Shaw :

As in pty.spawn, once started, the parent process will be hanged, even if the 
child process is already dead (or a zombie), and must wait for a 
KeyboardInterrupt or else to terminate the whole process.

Thus, I propose to revise `_copy` function, where the parent process hung, to 
check if the child process is dead periodically and if so, terminate the whole 
process then return as shown in the patch file.

--
components: Library (Lib)
files: pty-diff.patch
keywords: patch
messages: 326206
nosy: jarryshaw
priority: normal
severity: normal
status: open
title: pty.spawn -- auto-termination after child process is dead (a zombie)
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file47820/pty-diff.patch

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