[issue42644] logging.disable('WARN') breaks AsyncIO

2020-12-15 Thread Matthias Bussonnier


Change by Matthias Bussonnier :


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

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



[issue42644] logging.disable('WARN') breaks AsyncIO

2020-12-15 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

I should have been more careful in my explanation in the upstream issue to have 
a complete report in here. 

I think that patching logging.disable to raise a type error immediately would 
be welcome; as the effect of storing a wrong type make any asyncio application 
fails in place that can be relatively remote from the location of the erroneous 
value, and could be quite hard to debug in other circumstances.

--
nosy: +mbussonn

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



[issue42101] Allow inheritance of Venvs

2020-11-24 Thread Matthias Bussonnier


Change by Matthias Bussonnier :


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

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



[issue42101] Allow inheritance of Venvs

2020-10-20 Thread Matthias Bussonnier


New submission from Matthias Bussonnier :

Followup from Python Idea: 

https://mail.python.org/archives/list/python-id...@python.org/thread/KTIYUEYF6XBHOGOLV744RQXMTETVSTOF/

Goal would be to allow layering on virtualenv to speedup creation and use less 
disk space in the case of many large venv having the same base. 

This would be based on an private internal patch that would be upstreamed.

--
messages: 379164
nosy: mbussonn
priority: normal
severity: normal
status: open
title: Allow inheritance of Venvs
type: enhancement
versions: Python 3.10

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



[issue41520] codeop: 3.8.5 regression, warnings.simplefilter('error', SyntaxWarning) does not raise.

2020-08-12 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

> Thanks Matthias Bussonnier for the fix. 

Thank *YOU* for the fix, and the bug report is initially from tcaswell. 

At least on 3.8 branch this is fixed for me.

Just for completeness, this was discovered as in IPython we try to guess 
whether "enter"  is "insert new line" or "execute", and `1 is 1` would 
keep adding new lines.

Much love for the fast turnaround; looking fwd to 3.9

--

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



[issue41520] 3.8.5 regression, warnings.simplefilter('error', SyntaxWarning) does not raise.

2020-08-10 Thread Matthias Bussonnier


Change by Matthias Bussonnier :


--
versions: +Python 3.10, Python 3.9

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



[issue40807] Codeop: Show warnings once during _maybe_compile

2020-08-10 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

I think that might have introduce https://bugs.python.org/issue41520 where now 
`warnings.simplefilter('error', SyntaxWarning)` is silently ignored...

--
nosy: +mbussonn

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



[issue41520] 3.8.5 regression, warnings.simplefilter('error', SyntaxWarning) does not raise.

2020-08-10 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

Potentially due to 

https://bugs.python.org/issue40807
https://github.com/python/cpython/pull/20486

--

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



[issue41520] 3.8.5 regression, warnings.simplefilter('error', SyntaxWarning) does not raise.

2020-08-10 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

seem to affect 3.8.4 as well.

--

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



[issue41520] 3.8.5 regression, warnings.simplefilter('error', SyntaxWarning) does not raise.

2020-08-10 Thread Matthias Bussonnier


New submission from Matthias Bussonnier :

assuming 

$ cat foo.py
import warnings
from codeop import compile_command

warnings.simplefilter('error', SyntaxWarning)
res = compile_command('1 is 1\n', symbol='exec')
print('Res', res)

On 3.8.0...3.8.4 this correctly raises a SyntaxError:

 python  foo.py
Traceback (most recent call last):
  File "foo.py", line 5, in 
res = compile_command('1 is 1\n', symbol='exec')
  File "/Users/bussonniermatthias/miniconda3/envs/38/lib/python3.8/codeop.py", 
line 122, in compile_command
return _maybe_compile(_compile, source, filename, symbol)
  File "/Users/bussonniermatthias/miniconda3/envs/38/lib/python3.8/codeop.py", 
line 99, in _maybe_compile
raise err1
  File "/Users/bussonniermatthias/miniconda3/envs/38/lib/python3.8/codeop.py", 
line 87, in _maybe_compile
code1 = compiler(source + "\n", filename, symbol)
  File "/Users/bussonniermatthias/miniconda3/envs/38/lib/python3.8/codeop.py", 
line 102, in _compile
return compile(source, filename, symbol, PyCF_DONT_IMPLY_DEDENT)
  File "", line 1
SyntaxError: "is" with a literal. Did you mean "=="?



But will silently return None on 3.8.5

$ python  foo.py
Res None

--
components: Interpreter Core
messages: 375152
nosy: mbussonn
priority: normal
severity: normal
status: open
title: 3.8.5 regression, warnings.simplefilter('error', SyntaxWarning) does not 
raise.
type: behavior
versions: Python 3.8

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



[issue39562] Asynchronous comprehensions don't work in asyncio REPL

2020-07-06 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

Pablo, I see you reopened and marked as blocker, 

As the changes here has been released maybe you want to reclose and marked 
https://bugs.python.org/issue41218 as blocker it should also be fixed by
https://github.com/python/cpython/pull/21357

--

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



[issue41218] PyCF_ALLOW_TOP_LEVEL_AWAIT + list comprehension set .CO_COROUTINE falg.

2020-07-06 Thread Matthias Bussonnier


Change by Matthias Bussonnier :


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

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



[issue41218] PyCF_ALLOW_TOP_LEVEL_AWAIT + list comprehension set .CO_COROUTINE falg.

2020-07-06 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

https://bugs.python.org/issue39562 seem to have triggered that.

--

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



[issue39562] Asynchronous comprehensions don't work in asyncio REPL

2020-07-06 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

This make non-await list comprehension coroutine-code-objects as well: 

https://bugs.python.org/issue41218

import ast
import inspect
cell = '[x for x in l]'
code = compile(cell, "<>", "exec", 
flags=getattr(ast,'PyCF_ALLOW_TOP_LEVEL_AWAIT', 0x0))

inspect.CO_COROUTINE & code.co_flags == inspect.CO_COROUTINE  # this is now 
TRUE. 

This leads to weird things in Jupyter/IPython when we try to detect wether a 
block of code is, or os not async.

--
nosy: +mbussonn

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



[issue41218] PyCF_ALLOW_TOP_LEVEL_AWAIT + list comprehension set .CO_COROUTINE falg.

2020-07-06 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

(crossref https://github.com/ipython/ipython/issues/12422)

--

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



[issue41218] PyCF_ALLOW_TOP_LEVEL_AWAIT + list comprehension set .CO_COROUTINE falg.

2020-07-06 Thread Matthias Bussonnier


New submission from Matthias Bussonnier :

As far as I can tell sometime in 3.8.x (likely 3.8.3) the following snippet 
changed result:

import ast
import inspect
cell = '[x for x in l]'
code = compile(cell, "<>", "exec", 
flags=getattr(ast,'PyCF_ALLOW_TOP_LEVEL_AWAIT', 0x0))

inspect.CO_COROUTINE & code.co_flags == inspect.CO_COROUTINE


Use to be False in 3.8.2 I believe and is False after.

This is problematic when you try to detect top-level await code.

--
components: Interpreter Core
messages: 373128
nosy: mbussonn
priority: normal
severity: normal
status: open
title: PyCF_ALLOW_TOP_LEVEL_AWAIT + list comprehension set .CO_COROUTINE  falg.
versions: Python 3.10, Python 3.8, Python 3.9

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



[issue19335] codeop misclassifies incomplete code with 'nonlocal'

2020-06-28 Thread Matthias Bussonnier


Change by Matthias Bussonnier :


--
nosy: +mbussonn

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



[issue41041] Multiprocesing Pool borken on macOS REPL

2020-06-19 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

Thanks.

That's an annoying side effect of having spawn by default on macOS then. 

Could it be possible in `pool.map()` to detect that some of the objects are 
from main and would fail and then raise an error message in the parent process 
before starting the children ?

--

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



[issue41041] Multiprocesing Pool borken on macOS REPL

2020-06-19 Thread Matthias Bussonnier


New submission from Matthias Bussonnier :

$ python
Python 3.8.2 | packaged by conda-forge | (default, Apr 24 2020, 07:56:27)
[Clang 9.0.1 ] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from multiprocessing import Pool
>>>
>>> def f(x):
... return x*x
...
 
>>> with Pool(5) as p:
... print(p.map(f, [1, 2, 3]))
Process SpawnPoolWorker-1:
Process SpawnPoolWorker-2:
Process SpawnPoolWorker-3:
Traceback (most recent call last):
  File 
"/Users/bussonniermatthias/miniconda3/lib/python3.8/multiprocessing/process.py",
 line 315, in _bootstrap
self.run()
  File 
"/Users/bussonniermatthias/miniconda3/lib/python3.8/multiprocessing/process.py",
 line 108, in run
self._target(*self._args, **self._kwargs)
  File 
"/Users/bussonniermatthias/miniconda3/lib/python3.8/multiprocessing/pool.py", 
line 114, in worker
task = get()
  File 
"/Users/bussonniermatthias/miniconda3/lib/python3.8/multiprocessing/queues.py", 
line 358, in get
return _ForkingPickler.loads(res)
AttributeError: Can't get attribute 'f' on 
Traceback (most recent call last):
...

This is likely due to https://bugs.python.org/issue33725 (use spawn on MacOS), 
we we can't use `fork()`.

--
messages: 371900
nosy: mbussonn
priority: normal
severity: normal
status: open
title: Multiprocesing Pool borken on macOS REPL

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



[issue37028] Implement asyncio repl

2020-05-27 Thread Matthias Bussonnier

Matthias Bussonnier  added the comment:

> Compared to the vanilla REPL, this doesn’t include readline setup for tab 
> completion and history file.  Was it on purpose?

Not particularly, it was mostly to show it is possible. I'm guessing any 
improvement to make it more consistent with the normal REPL would be welcome. 

If you want a fancier repl that also have these features it should work out of 
the box with IPython.

--

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



[issue38632] setup.py sdist should honor SOURCE_DATE_EPOCH

2020-05-23 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

https://github.com/python/cpython/pull/20331 is a first step toward this. 

See comments in there, I would love some reviews. If that gets im I'll be happy 
to send further refactor to make the compression step also respect 
SOURCE_DATE_EPOCH.

For projects building with older python you should be able to unpack/repack 
with your custom scripts that should allow you have bytes identical tar in many 
cases.

--

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



[issue38632] setup.py sdist should honor SOURCE_DATE_EPOCH

2020-05-23 Thread Matthias Bussonnier


Change by Matthias Bussonnier :


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

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



[issue38632] setup.py sdist should honor SOURCE_DATE_EPOCH

2020-05-23 Thread Matthias Bussonnier


Change by Matthias Bussonnier :


--
nosy: +mbussonn

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



[issue40257] Improve the use of __doc__ in pydoc

2020-05-18 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

> Looks like the revert is solving the issue?

It appears to do so as far as I can tell, and most test pass on nightly, the 
rest seem to be unrelated to changes in current 3.9. 

Many thanks to Serhiy for all the work on making documentation better, and 
there are definitively case where a version of getowndoc, or something that 
discriminate where the docstring comes from would be useful.

I also agree that having _some_ ability to extend docstring would be nice but 
it's likely for another issue.

--

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



[issue40257] Improve the use of __doc__ in pydoc

2020-05-12 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

I've sent a request for comments on python-dev 

https://mail.python.org/archives/list/python-...@python.org/thread/6QO2XI5B7RVZDW3YZV24LYD75VGRITFU/

Thanks.

--

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



[issue40257] Improve the use of __doc__ in pydoc

2020-05-11 Thread Matthias Bussonnier

Matthias Bussonnier  added the comment:

> Can you all please decide which issue to use?

We can stay here, I opened the other issue before figuring out this was the 
cause.

> If IPython wants to output the help on the instance, it should change the 
> implementation of `?` and `??`. It would be better if it correctly attribute 
> the source of the docstring: the object itself, its class or its superclass. 
> It was difficult to distinguish these cases before, now it is easier.

Sure I can do that, but this issue feel like a important semantic change of 
`inspect.getdoc()`, it may be documented but there is no warning or deprecation 
of behavior. It is also likely to affect untested code (documentation 
generation).

If you decide that this change of behavior is the one you want I'll be happy to 
support you – I just want to make sure the impact on the rest of the ecosystem. 
IPython/Jupyter is likely not the only one to rely on inspect.getdoc behavior, 
I'm thinking pycharm, spyder, sphinx will likely be impacted. I can see 
`inspect.getdoc()` in the source of even scipy/numpy and rarely in tests.


I would prefer new functions with clearer behavior and for example returning a 
sequence of tuple (docs, where it comes from) potentially deprecating 
inspect.getdocs() than a change of behavior that remove data where their used 
to be some


>  I just tried IPython 5.5.0

(You may want to update to 5.10, and do you have reason to still be on 5 and 
not 7 ?)

--

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



[issue40257] Improve the use of __doc__ in pydoc

2020-05-10 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

> can you clarify your example? What's load()? And what does df?? do?

It was vague on purpose, 

`load()` would be for example `load_csv()` from `pandas` that return a 
`pandas.DataFrame`. The point being that users typically won't really know the 
type of what they will get, they may get a DataFrame, but they may get a 
subclass if for example they use `dask` to do distributed computing. 

`?` or `??` is the way to get help in IPython/Jupyter, we try to pull as much 
information as we can and under the hood call `inspect.getdoc()`.

Assuming 

In [4]: class A:
   ...: "doc"

In [5]: class B(A):
   ...: pass

In [6]: b = B()

Python 3.8 gives:

In [9]: b?
Type:B
String form: <__main__.B object at 0x104be7d00>
Docstring:   
Class docstring: doc

Python 3.9 give

In [4]: b?
Type:B
String form: <__main__.B object at 0x10a0b7140>
Docstring:   


We do already pull docs from the superclass of the instance if no doc is found 
on current object, but now we get even less for the user. We could of course 
publish patch and walk the hierarchy ourselves, but it will require many users 
to upgrade (which you of course know they are not good at).

(Here i'm using `?`, `??` try to pull even more informations like the source, 
known subclasses and other stuff)


(Will try to get examples with actual code, but I haven't had time to build 
pandas or other scientific package on 3.9 yet).

--

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



[issue40257] Improve the use of __doc__ in pydoc

2020-05-10 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

This is going to potentially break a lot of interactive usage in the Scientific 
ecosystem. 

A a lot of people are going to do:

df = load('my.csv')
df??

To ask for help and will get nothing. 

Even for subclass, I want to argue that a docstring for a superclass is better 
than no docstring. 


This will be devastating for many users.

--
nosy: +mbussonn

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



[issue40587] [regression] inspect.getdoc not returning docstring.

2020-05-10 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

That will break a lot o the interactive usage for the scientific ecossytem 
Imho, 

For example anyone that get a Pandas Dataframe and try to get help on it either 
via help(df), or `df?` in IPython/Jupyter.

Might be purposeful (https://bugs.python.org/issue40257)

--

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



[issue40587] [regression] inspect.getdoc not returning docstring.

2020-05-10 Thread Matthias Bussonnier


New submission from Matthias Bussonnier :

In python 3.8:

```
>>> class A(object):
... """standard docstring"""
... pass
...
>>> import inspect
>>> inspect.getdoc(A())
'standard docstring'
```

In 3.9:

```
$ python
Python 3.9.0a6+ (heads/master:5b956ca42d, May 10 2020, 20:31:26)
[Clang 9.0.0 (clang-900.0.39.2)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> class A(object):
KeyboardInterrupt
>>> class A(object):
... """standard docstring"""
... pass
...
>>> import inspect
>>> inspect.getdoc(A())
>>>
```

--
messages: 368603
nosy: mbussonn
priority: normal
severity: normal
status: open
title: [regression] inspect.getdoc not returning docstring.

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



[issue40587] [regression] inspect.getdoc not returning docstring.

2020-05-10 Thread Matthias Bussonnier


Change by Matthias Bussonnier :


--
components: +Interpreter Core
versions: +Python 3.9

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



[issue40334] PEP 617: new PEG-based parser

2020-05-10 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

Seem to not be in the new parser but simply in codeop in particular `def 
_maybe_compile`

The logic seem weird (but weird logic usually have a reason), it try to compile 
thrice by appending many `\n`.

1) Why do that and not return the first successful compile directly ? I'm not 
sure. 
2) It does compare the repr of error when  compile(source + "\n") and 
compile(source+'\n\n') and only raise if both are identical (which they are not 
in the new parser, they differ by `\n`...)

SyntaxError('invalid syntax', ('', 1, 6, 'def a-b')) 
vs
SyntaxError('invalid syntax', ('', 1, 6, 'def a-b\n'))


This logic seem to go back to the 2000s.

--

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



[issue38872] Document exec symbol for codeop.compile_command

2020-05-10 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

See the `compile()` documentation for the difference between eval/single/exec:

https://docs.python.org/3/library/functions.html#compile

`exec` is meant for multiline program, for example you would "exec" the string 
read from a file to get a module. 

I don't think we should re-document what each of these does, but list the 
possible values that compile_command/CommandCompiler() can take.

--

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



[issue40334] PEP 617: new PEG-based parser

2020-05-10 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

Thanks Pablo for replying to my tweet, a couple of other non-failing case in 
https://bugs.python.org/issue40585 that I filled concurrently to your message.

(also using this occasion to thanks all of you for your work on the new parser)

--
nosy: +mbussonn

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



[issue40585] compile_command exec not raising syntax error with new PGEN Parser

2020-05-10 Thread Matthias Bussonnier


New submission from Matthias Bussonnier :

compile_command  used to produce syntax error in exec mode:

```
$ python -c "import codeop; codeop.compile_command('raise = 2', symbol='exec')"
Traceback (most recent call last):
  File "", line 1, in 
  File "...python3.8/codeop.py", line 125, in compile_command
return _maybe_compile(_compile, source, filename, symbol)
  File "...python3.8/codeop.py", line 100, in _maybe_compile
raise err1
  File "...python3.8/codeop.py", line 87, in _maybe_compile
code1 = compiler(source + "\n", filename, symbol)
  File "...python3.8/codeop.py", line 105, in _compile
return compile(source, filename, symbol, PyCF_DONT_IMPLY_DEDENT)
  File "", line 1
raise = 2
  ^
SyntaxError: invalid syntax
```

This happens to not be the case anymore in master, where it simply return 
`None` for above invalid input. 

```
$ python -c "import codeop; codeop.CommandCompiler()('raise = 2', 
symbol='exec')"
```

or many other:

```
 $ python
Python 3.9.0a6+ (heads/master:2cc9b8486d, May 10 2020, 15:52:00)
[Clang 9.0.0 (clang-900.0.39.2)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import codeop;
>>> codeop.compile_command('def a-b', symbol='exec')
>>> codeop.compile_command('await?', symbol='exec')
>>> codeop.compile_command('=!=', symbol='exec')
>>> codeop.compile_command('a await raise b', symbol='exec')
>>> codeop.compile_command('a await raise b?+1', symbol='exec')
```


It is problematic as this is used in many places to decide whether code is 
valid, and for example in IPython to know wether we should insert a new line, 
or try to execute the code. 

It seem to be due to the new PGEN parser as setting PYTHONOLDPARSER solve the 
issue:

```
$ PYTHONOLDPARSER=1 python -c "import codeop; codeop.CommandCompiler()('raise = 
2', symbol='exec')"
Traceback (most recent call last):
  File "", line 1, in 
  File "/Users/bussonniermatthias/dev/cpython/Lib/codeop.py", line 171, in 
__call__
return _maybe_compile(self.compiler, source, filename, symbol)
  File "/Users/bussonniermatthias/dev/cpython/Lib/codeop.py", line 100, in 
_maybe_compile
raise err1
  File "/Users/bussonniermatthias/dev/cpython/Lib/codeop.py", line 87, in 
_maybe_compile
code1 = compiler(source + "\n", filename, symbol)
  File "/Users/bussonniermatthias/dev/cpython/Lib/codeop.py", line 136, in 
__call__
codeob = compile(source, filename, symbol, self.flags, True)
  File "", line 1
raise = 2
  ^
SyntaxError: invalid syntax
```

`single` and `eval` appear to behave fine.

--
components: Interpreter Core
messages: 368594
nosy: mbussonn
priority: normal
severity: normal
status: open
title: compile_command exec not raising syntax error with new PGEN Parser
versions: Python 3.9

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



[issue38872] Document exec symbol for codeop.compile_command

2020-05-10 Thread Matthias Bussonnier


Change by Matthias Bussonnier :


--
nosy: +mbussonn

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



[issue38981] better name for re.error Exception class.

2019-12-09 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

> RECompileError, REParseError, RESyntaxError, REError, CompileError, 
> ParseError, SyntaxError or Error, 

> Many modules [...] have an exception named just Error

RECompileError, REParseError, RESyntaxError, REError, CompileError, ParseError 
are all fine with me. 

SyntaxError would be super confusing IMHO.
Remember the StackTrace does not get the fully qualified name, so it would be 
hard to distinguish from a SyntaxError with the Python Syntax.

aifc, binhex, sunau, uu, xdrlib might be removed with PEP 594, And I find  
`Error` not informative enough. It suffers from the same issues as above, as 
stack traces do not have the full qualified name. 

I would also add that being able to search and find all occurrences of a given 
exceptions is useful, and that Error is too generic.

Let me know your choice and I can rename.

--

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



[issue38981] better name for re.error Exception class.

2019-12-07 Thread Matthias Bussonnier


Change by Matthias Bussonnier :


--
keywords: +patch
pull_requests: +16979
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/17501

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



[issue38981] better name for re.error Exception class.

2019-12-07 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

Thanks Serhiy, 

Here is a rough idea of how many places would be touched by renaming in the 
`re` module:

https://github.com/Carreau/cpython/commit/59e4c5150c842f849ff3a9ba8a94df1df7a5eb1c
 (50 additions and 42 deletions.). 

I haven't found any places that need changes in the C code, and need to polish 
documentation, rebuild and run the test suite before sending a PR.

--

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



[issue38981] better name for re.error Exception class.

2019-12-05 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

Thanks for the advice I've done that ! 

Have a good day.

--

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



[issue38981] better name for re.error Exception class.

2019-12-05 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

Most of the module specific classes are `Error`, not `error`, at least with an 
uppercase E you know it's a class. 

if a novice sees :

> error: missing ), unterminated subpattern at position 0

It will be relatively tough or them to figure out that `error` is the type of 
the exception. 

Also it's not because something works that you can't improve it ...

--
status: closed -> open

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



[issue38981] better name for re.error Exception class.

2019-12-05 Thread Matthias Bussonnier


New submission from Matthias Bussonnier :

better error/exception name for re.compile error. 

Currently the error raise by re.compile when it fails to compile is `error` 
defined in sre_constants.py: 

```
class error(Exception):
"""Exception raised for invalid regular expressions.

```

This is quite disturbing as most exception start with an uppercase and have a 
tiny bit more descriptive name. 

Would it be possible to have it renamed as something more explicit like 
`ReCompileError`, and still keeping the potential `error` alias as deprecated ?

--
components: Regular Expressions
messages: 357867
nosy: ezio.melotti, mbussonn, mrabarnett
priority: normal
severity: normal
status: open
title: better name for re.error Exception class.

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



[issue38955] Non indemnpotent behavior of asyncio.get_event_loop and asyncio.run sequence.

2019-12-05 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

Thanks Andrew; 

I'd still would love to have a way to get the current eventloop outside of 
async code that is consistent. 

I guess throwing an error with `get_event_loop()` is ok, it's just that 
`RuntimeError` feel like a weird thing to catch.

Alternatively is the current event loop is None I feel like returning None 
would also make sens imho. 

Feel free to close if you think this will not get fixed/updated.

--

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



[issue38955] Non indemnpotent behavior of asyncio.get_event_loop and asyncio.run sequence.

2019-12-02 Thread Matthias Bussonnier


New submission from Matthias Bussonnier :

Hi, Not sure if this a bug, or an intended feature. 
I got surprise by the following behavior. 


from asyncio import run, sleep, get_event_loop

print(get_event_loop()) # return the current eventloop
run(sleep(0))
print(get_event_loop()) # raise a RuntimeError


I would expect `get_event_loop` to get back to it's initial default value. 

This comes from the fact that `run()` call `set_event_loop()` to `None`. with
both sets `_set_called` to `True`, but `get_event_loop` seem to assume if
_set_called is True, then loop cannot be none. 

I'm tempted to think that if `set_loop()` is called with `None`, it should 
reset the `_set_called` to False. Or Am I supposed to call 
`set_event_loop(new_event_loop())` myself ? 

I'm likely missing  something so any insight would be appreciated; if you
believe this is an actual issue I'm happy to send a PR.

--
components: asyncio
messages: 357727
nosy: asvetlov, mbussonn, yselivanov
priority: normal
severity: normal
status: open
title: Non indemnpotent behavior of asyncio.get_event_loop and asyncio.run 
sequence.
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

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



[issue26389] Expand traceback module API to accept just an exception as an argument

2019-11-13 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

> were you interested in continuing with Brett's (and your) suggestion for the 
> API by making the first argument positional-only and the others optional?

Yes, but I currently do not have the time; if someone else want to take over; 
or if you need to close this issue or corresponding PR for now please feel free 
to do so. I'll come back to it at some point.

--

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



[issue37102] Automatically dedent docstring constants by default

2019-05-31 Thread Matthias Bussonnier


Change by Matthias Bussonnier :


--
nosy: +mbussonn

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



[issue36896] clarify in types.rst that FunctionTypes & co constructors don't have stable signature

2019-05-31 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

>  I don't believe we put version changed notes in docstrings,

Oh no I was thinking a note in the docstring "constructor signature may change 
between Python versions".

Whether to put changed/addition info in docstrings is another subject and a 
thing I would be in favor of; but let's not digress and the current issue which 
is to convey to users the non-stability of interface.

--

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



[issue36896] clarify in types.rst that FunctionTypes & co constructors don't have stable signature

2019-05-31 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

Victor recently implemented CodeType.replace(); which I believe will cover many 
of the usecase.

Should I also send a PR that update the DocStrings of (some of) ? these 
objects? many people don't go and read the html docs...

--

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



[issue36373] asyncio.gather: no docs for deprecated loop parameter

2019-05-28 Thread Matthias Bussonnier


Change by Matthias Bussonnier :


--
nosy: +mbussonn

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



[issue37082] Assignment expression operator (walrus) not in built-in help()

2019-05-28 Thread Matthias Bussonnier


New submission from Matthias Bussonnier :

Do the following at a Python prompt: 
```
>>> help()

Welcome to Python 3.8's help utility!

[...]SNIP

help> symbols

Here is a list of the punctuation symbols which Python assigns special meaning
to. Enter any symbol to get more help.

!=  +   <=  __
"   +=  <>  `
""" ,   ==  b"
%   -   >   b'
%=  -=  >=  f"
&   .   >>  f'
&=  ... >>= j
'   /   @   r"
''' //  J   r'
(   //= [   u"
)   /=  \   u'
*   :   ]   |
**  <   ^   |=
**= <<  ^=  ~
*=  <<= _
```

Oh no ! Our favorite `:=` is missing :-(

--
assignee: docs@python
components: Documentation
messages: 343813
nosy: docs@python, mbussonn
priority: normal
severity: normal
status: open
title: Assignment expression operator (walrus) not in built-in help()
versions: Python 3.8, Python 3.9

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



[issue36933] sys.set_coroutine_wrapper documented as to be removed in 3.8 (still there)

2019-05-28 Thread Matthias Bussonnier


Change by Matthias Bussonnier :


--
pull_requests: +13526
pull_request: https://github.com/python/cpython/pull/13627

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



[issue37003] ast unparse does not support f-string new debug format.

2019-05-27 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

I believe all is fine now. Thanks !

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

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



[issue37068] Emit SyntaxWarning for f-strings without expressions ?

2019-05-27 Thread Matthias Bussonnier

New submission from Matthias Bussonnier :

Or more precisely I suggest to emit a SyntaxWarning for JoinedStr where no 
f-string members has an expression. 

There seem to be a couple of case where f-strings without expressions may 
indicate
that the programmer may have made a mistake; though there are also a number of
case where f-string w/o expressions are legitimate; I believe we should be able
to emit a SyntaxWarning in case where `f` are really unnecessary or might be a
mistakes.

First case where f-string w/o expressions are legitimate: multiline joined 
string,
to make sure each line is aligned. Example from CPython source:

# not a SyntaxWarning.
msg = (
f'error while attempting to bind on '
f'address {laddr!r}: '
f'{exc.strerror.lower()}'
)

The first line has obviously no expression, but the f is useful for visual
consistency, and we likely do not want a warning.

Though in the above case we can imagine the following typo :

msg = (
f'error while attempting to bind on ', #SyntaxWarning here
f'address {laddr!r}: ',
f'{exc.strerror.lower()}'
)

Easy to make and in this case, the expression-less f-string is likely an error.
In this case a syntax warning would help to distinguish that there are trailing
commas.

Another case from the cpython is the following: 

fullName = f'%s.%s.%s' % ( #SyntaxWarning here
 testCaseClass.__module__, testCaseClass.__qualname__, attrname
 )

Looking at the history; I believe the author was meaning to change to an
f-string, but got interrupted half-way and only added the prefix.

Pep 498 does not seem to say anything about f-string w/o expressions; but
test-suite appear to test that f-string without expression do not raise an
error. I do not believe that making it an error is in anyway desirable;

I believe a SyntaxWarning would align with the current warning on invalid
escape sequence, and help – mostly during refactoring, if an f-string loses 
some of its parameters, and the f"" if non-intentionally kept.

--
components: Interpreter Core
messages: 343672
nosy: mbussonn
priority: normal
severity: normal
status: open
title: Emit SyntaxWarning for f-strings without expressions ?
versions: Python 3.9

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



[issue37032] Add CodeType.replace() method

2019-05-26 Thread Matthias Bussonnier


Change by Matthias Bussonnier :


--
nosy: +mbussonn

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



[issue36853] inconsistencies in docs builds (Sphinx 2)

2019-05-26 Thread Matthias Bussonnier


Change by Matthias Bussonnier :


--
nosy: +mbussonn

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



[issue37057] suspicious.py sphinx extension access non-existing attribute.

2019-05-26 Thread Matthias Bussonnier


Change by Matthias Bussonnier :


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

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



[issue37057] suspicious.py sphinx extension access non-existing attribute.

2019-05-26 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

Oh yeah, I do... and you are right this is duplicate.

--

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



[issue37057] suspicious.py sphinx extension access non-existing attribute.

2019-05-26 Thread Matthias Bussonnier


New submission from Matthias Bussonnier :

On a local branch  with some modified docs
```
Traceback (most recent call last):
  File 
"/Users/bussonniermatthias/dev/cpython/Doc/venv/lib/python3.8/site-packages/sphinx/cmd/build.py",
 line 284, in build_main
app.build(args.force_all, filenames)
  File 
"/Users/bussonniermatthias/dev/cpython/Doc/venv/lib/python3.8/site-packages/sphinx/application.py",
 line 337, in build
self.builder.build_update()
  File 
"/Users/bussonniermatthias/dev/cpython/Doc/venv/lib/python3.8/site-packages/sphinx/builders/__init__.py",
 line 324, in build_update
self.build(to_build,
  File 
"/Users/bussonniermatthias/dev/cpython/Doc/venv/lib/python3.8/site-packages/sphinx/builders/__init__.py",
 line 392, in build
self.finish()
  File 
"/Users/bussonniermatthias/dev/cpython/Doc/tools/extensions/suspicious.py", 
line 118, in finish
self.warn('Found %s/%s unused rules:' %
AttributeError: 'CheckSuspiciousMarkupBuilder' object has no attribute 'warn'
```

My guess is that it should be self.logger.warn, and not self.warn.

--
messages: 343569
nosy: mbussonn
priority: normal
severity: normal
status: open
title: suspicious.py sphinx extension access non-existing attribute.
versions: Python 3.8

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



[issue36933] sys.set_coroutine_wrapper documented as to be removed in 3.8 (still there)

2019-05-25 Thread Matthias Bussonnier


Change by Matthias Bussonnier :


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

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



[issue3693] Obscure array.array error message

2019-05-25 Thread Matthias Bussonnier


Change by Matthias Bussonnier :


--
pull_requests:  -13484

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



[issue3693] Obscure array.array error message

2019-05-25 Thread Matthias Bussonnier


Change by Matthias Bussonnier :


--
pull_requests: +13484
pull_request: https://github.com/python/cpython/pull/13577

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



[issue36933] sys.set_coroutine_wrapper documented as to be removed in 3.8 (still there)

2019-05-25 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

Some discussion in 
https://github.com/python/cpython/pull/13349#discussion_r284567113

--

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



[issue37050] Remove expr_text from ast node FormattedValue

2019-05-25 Thread Matthias Bussonnier


Change by Matthias Bussonnier :


--
nosy: +mbussonn

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



[issue37028] Implement asyncio repl

2019-05-23 Thread Matthias Bussonnier


Change by Matthias Bussonnier :


--
nosy: +mbussonn

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



[issue37006] Add top level await statement support for doctest

2019-05-22 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

As a reference, PR from Yuri for an asyncREPL  `python -m asyncio` which I 
believe he want in 3.8:

https://github.com/python/cpython/pull/13472

I'm also likely to align IPython behavior on whatever core python decides.

--

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



[issue37003] ast unparse does not support f-string new debug format.

2019-05-22 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

I thought it was comparing the AST of the file to the AST of the unparsed
AST.

So it's actually checking if parse(unparse(x)) is indempotent and not
wether parse(unparse(x)) is indempotent.

So x={x!r} should be fine.

On Wed, May 22, 2019, 09:22 Pablo Galindo Salgado 
wrote:

>
> Pablo Galindo Salgado  added the comment:
>
> Notice that test_tools will fail if  f'{x=}' becomes f'x={x!r}' when
> unparsed as it compares the text of the file and the text of the roundtrip
> of the ast of the file
>
> --
> nosy: +pablogsal
>
> ___
> Python tracker 
> <https://bugs.python.org/issue37003>
> ___
>

--

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



[issue37006] Add top level await statement support for doctest

2019-05-22 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

The other thing to think about is `ensure_future` and `create_task`, they may 
not move forward until a foreground task is running. 

You can keep a loop running between lines or code-chunks, but then doctest 
cannot contain `asyncio.run()`.

I'm leaning toward conservatisme, and make things better but not perfect for 
3.8; potentially improving, in minor release of 3.9

--

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



[issue34616] implement "Async exec"

2019-05-21 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

> section to document the new flag inside "Improved Modules" category

Done in https://github.com/python/cpython/pull/13484

--

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



[issue34616] implement "Async exec"

2019-05-21 Thread Matthias Bussonnier


Change by Matthias Bussonnier :


--
pull_requests: +13396

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



[issue37003] ast unparse does not support f-string new debug format.

2019-05-21 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

Just for clarification for future readers;

I landed a PR that used f"{x=}" in some new functionalities, and that broke the 
buildbots, the buildbots do test that many of the `Lib/` files can be 
round-tripped ast->unparse->ast, and as ast-unparse did not understood f-debug, 
if roundtripped f"{x=}" to f"{x!r}". The PRs CIs did not fail as apparently 
they don't test this functionality.

So currently not having support for f-string-debug in ast-unparse kind of 
prevent using f-string debug format in the stdlib.

I'm happy if `expr_text` get removed, and having unparse round-trip to 
`x={x!r}` sounds sufficient to me; it may make like of formatters like black a 
bit harder maybe ? Though I believe black is likely not using ast but lib2to3.

--

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



[issue34616] implement "Async exec"

2019-05-21 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

> Maybe you used "git merge" and your PR "contained" changes from other issues?

I quasi-nerver merge, either `rebase interactive` or `reset --hard HEAD`... I 
even proscribed "git pull" from my CLI.. but you know everybody does mistakes. 

> Would be great if you could make a PR to add an entry to whatsnew/3.8.rst (as 
> Victor suggests)

Ok, i'll do this.

--

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



[issue34616] implement "Async exec"

2019-05-21 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

> Yes, Elvis and I will take care of that later.

And I'm guessing you will collect what's in NEWS.d ? Otherwise I'm happy to 
contribute some text. let me know the best way.

--

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



[issue34616] implement "Async exec"

2019-05-21 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

> Any idea why PR 13148 has been linked to unrelated bugs.python.org issues?

Could it be due to rebasing and force-pushing ? Cause I did force-push on this 
branch a couple of times...

--

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



[issue36817] Add = to f-strings for easier debugging.

2019-05-21 Thread Matthias Bussonnier

Matthias Bussonnier  added the comment:

I'm not quite sure I completely understand how this is implemented and all the 
possibilities;  – so I would appreciate reviews on the issue (and patch) to 
handle this in ast-unparse. 

See https://bugs.python.org/issue37003

Thanks,

--
nosy: +mbussonn

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



[issue37003] ast unparse does not support f-string new debug format.

2019-05-21 Thread Matthias Bussonnier


Change by Matthias Bussonnier :


--
keywords: +patch
pull_requests: +13387
stage:  -> patch review

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



[issue37003] ast unparse does not support f-string new debug format.

2019-05-21 Thread Matthias Bussonnier


New submission from Matthias Bussonnier :

All in title, f"{x=}" implemented in https://bugs.python.org/issue36817
are not liked by unparse:  https://github.com/python/cpython/pull/13473,

--
components: Library (Lib)
messages: 343105
nosy: mbussonn
priority: normal
severity: normal
status: open
title: ast unparse does not support f-string new debug format.
versions: Python 3.8

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



[issue35363] test_eintr: test_open() hangs randomly on x86-64 El Capitan 3.x buildbot

2019-05-21 Thread Matthias Bussonnier


Change by Matthias Bussonnier :


--
pull_requests: +13384

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



[issue25234] test_eintr.test_os_open hangs under Xcode 7

2019-05-21 Thread Matthias Bussonnier


Change by Matthias Bussonnier :


--
pull_requests: +13383

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



[issue33725] Python crashes on macOS after fork with no exec

2019-05-21 Thread Matthias Bussonnier


Change by Matthias Bussonnier :


--
pull_requests: +13382

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



[issue33563] fileinput input's and Fileinput's bufsize=0 do not remit deprecationWarnings

2019-05-21 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

bufsize has now been removed.

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

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



[issue28971] nntplib is broken when responses are longer than _MAXLINE

2019-05-21 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

Would that be anyway closed by pep 594 
(https://www.python.org/dev/peps/pep-0594/#nntplib) which suggest the removal 
nntp ?

--
nosy: +mbussonn

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



[issue36906] Compile time textwrap.dedent() equivalent for str or bytes literals

2019-05-20 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

> Oh, please, please, please PLEASE let's not over-sell this! 

Sorry didn't wanted to give you a heart attack. The optimisation has been 
mentioned, and you never know what people get excited on.

> Such constant-folding ...

Well, in here we might get that, but I kind of want to see how this is taught 
or explain, what I want to avoid is tutorial or examples saying that 
`.dedent()` is "as if you hadn't put spaces in front".

> I don't think so, but eventually it might.

Ok, thanks.

Again just being cautious, and I see this is targeted 3.9 so plenty of time.
I believe this will be a net improvement on many codebases.

--

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



[issue36906] Compile time textwrap.dedent() equivalent for str or bytes literals

2019-05-20 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

I've tried a bit PR 13455, I find this way nicer than textwrap.dedent(...), 
though I wonder if f-string readability (and expected behavior?) might suffer a 
tiny bit with the order of formatting the f-string vs dedenting. 

In the following it is clear that dedent is after formatting: 

>>> dedent(f"   {stuff}")

It might be unclear for the following especially if `.dedent()` get sold as 
zero-overhead at compile time.

>>> f"   {stuff}".dedent()

Could it be made clearer with the peephole optimiser (and tested, I don't 
believe it is now), that dedent applies after-formatting ?

Alternative modifications/suggestions/notes: 

   - I can also see how having dedent applied  **before** formatting with 
f-string could be useful or less surprising ( a d"" prefix could do that... 
just wondering what your actual goal is). 
   - Is this a supposed to deprecating textwrap.dedent ? Duck-typing and stuff, 
could textwrap.dedent work on non-str things and the current implementation not 
( it assumes the `.dedent()` method exists) and thus be backward-incompatible ?

--

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



[issue25988] collections.abc.Indexable

2019-05-20 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

mbussonn: Your new PR looks like it's related to #36953 ("Remove collections 
ABCs?"), not this issue specifically. Can you withdraw/reissue attached to the 
correct issue?

Apologies, I've rebased and updated the issue numbers, not sure how I got the 
wrong one. I've also unlinked from here.

--

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



[issue25988] collections.abc.Indexable

2019-05-20 Thread Matthias Bussonnier


Change by Matthias Bussonnier :


--
pull_requests:  -13320

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



[issue36953] Remove collections ABCs?

2019-05-20 Thread Matthias Bussonnier


Change by Matthias Bussonnier :


--
keywords: +patch
pull_requests: +13356
stage:  -> patch review

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



[issue36691] SystemExit & sys.exit : Allow both exit status and message

2019-05-19 Thread Matthias Bussonnier


Change by Matthias Bussonnier :


--
nosy: +mbussonn

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



[issue25988] collections.abc.Indexable

2019-05-18 Thread Matthias Bussonnier


Change by Matthias Bussonnier :


--
pull_requests: +13320

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



[issue36953] Remove collections ABCs?

2019-05-18 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

Should it still raise an informative error message with ImportError:

> ImportError: cannot import name 'XXX' from 'collections', please import it 
> from 'collections.abc'.

or just the "cannot import name ''" without the  "please import it from 
'collections.abc'." ?

--

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



[issue36953] Remove collections ABCs?

2019-05-17 Thread Matthias Bussonnier


Change by Matthias Bussonnier :


--
nosy: +mbussonn

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



[issue36952] fileinput input's and Fileinput's bufsize=0 marked for removal in 3.8

2019-05-17 Thread Matthias Bussonnier


Change by Matthias Bussonnier :


--
keywords: +patch
pull_requests: +13310
stage:  -> patch review

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



[issue36952] fileinput input's and Fileinput's bufsize=0 marked for removal in 3.8

2019-05-17 Thread Matthias Bussonnier


New submission from Matthias Bussonnier :

Can likely thus be removed now. 

See also https://bugs.python.org/issue33563 that was tracking better 
deprecation warnings.

If not removed documentation should bump removal to 3.9

--
components: Library (Lib)
messages: 342769
nosy: mbussonn
priority: normal
severity: normal
status: open
title: fileinput input's and Fileinput's bufsize=0 marked for removal in 3.8
versions: Python 3.8

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



[issue36933] sys.set_coroutine_wrapper documented as to be removed in 3.8 (still there)

2019-05-15 Thread Matthias Bussonnier


New submission from Matthias Bussonnier :

See issue32591

It was deprecated in 3.7, so maybe removed only in 3.9?

--
components: Interpreter Core
messages: 342615
nosy: mbussonn
priority: normal
severity: normal
status: open
title: sys.set_coroutine_wrapper documented as to be removed in 3.8 (still 
there)
versions: Python 3.8

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



[issue36932] asyncio-task.rst could use proper deprecated-removed directive

2019-05-15 Thread Matthias Bussonnier


Change by Matthias Bussonnier :


--
assignee:  -> docs@python
components: +Documentation
nosy: +docs@python
versions: +Python 3.8

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



[issue36932] asyncio-task.rst could use proper deprecated-removed directive

2019-05-15 Thread Matthias Bussonnier


Change by Matthias Bussonnier :


--
keywords: +patch
pull_requests: +13260
stage:  -> patch review

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



[issue36932] asyncio-task.rst could use proper deprecated-removed directive

2019-05-15 Thread Matthias Bussonnier


New submission from Matthias Bussonnier :

SOme place in the documentation do not use the Deprected-remove directive 
(which is nice as it has a consistent pharing and is easy to search for), 
and deprecation warnings do not always have the version since deprecation which 
could be improved.

--
messages: 342610
nosy: mbussonn
priority: normal
severity: normal
status: open
title: asyncio-task.rst could use proper deprecated-removed directive

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



[issue34616] implement "Async exec"

2019-05-15 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

> I'll be working on CPython on Friday. Will take a look at your PR first thing.

Thanks, let me know if the is anything I can do for you in exchange; also 
thanks again for sitting with me and stepping me through the things at PyCon.

--

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



[issue34616] implement "Async exec"

2019-05-15 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

I see the 3.8 feature freeze seem to be end of next-week; do you think that 
async-exec (gh-13148) has a chance of getting in ? I'm happy to do modification 
to the PR but would need some more reviews. I'm happy to take some other tasks 
of your plate is that allow this to squeeze in before feature freeze. 

Thanks.

--

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



[issue36917] ast.NodeVisitor no longer calls visit_Str

2019-05-15 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

> so my vote is to revert, keep the complexity in the compiler and out of user 
> code


Playing Devil advocate here, but the complexity depends on what transformations 
user want to do; with the current state of 3.8, a user that wants to visit all 
immutable types can do with a single visit_Constant; once 32892 reverted; they 
would need to implement all of visit_Str,NamedConstant,Num,Bytes, and have it 
called the same visit_Constant.

--

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



[issue36917] ast.NodeVisitor no longer calls visit_Str

2019-05-14 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

> There would still be a breakage for that if someone was defining py36+ 
> `visit_Constant` (which would clobber the `ast.NodeVisitor.visit_Constant` if 
> we were to add it)


Ok, it would still break in some cases, but that would still be a net 
improvement for codebase that do not override visit_Constant; right ? 

We could also push the patch further if we really want and call explicitly 
NodeVisitor.visit_Constant before the overridden method in NodeVisitor.visit.

Not advocating for the second part, but minimal breakage and code repetition in 
libraries when we can.

--

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



  1   2   3   >