[issue36886] Failed to construct CodeType on Python-3.8.0a4

2019-05-24 Thread STINNER Victor


STINNER Victor  added the comment:

I created bpo-37032 to add a new CodeType.replace() helper which help projects 
to be more future-proof (no longer break if CodeType gets yet another 
parameter).

--
nosy: +vstinner

___
Python tracker 

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



[issue36886] Failed to construct CodeType on Python-3.8.0a4

2019-05-12 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

Thanks for the update to the what's new Pablo. 

> let's open a new issue for the notice in types.rst to keep the discussion 
> isolated.

See bpo-36896

--

___
Python tracker 

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



[issue36886] Failed to construct CodeType on Python-3.8.0a4

2019-05-12 Thread Pablo Galindo Salgado


Pablo Galindo Salgado  added the comment:


New changeset 5d23e282af69d404a3430bb95aefe371112817b3 by Pablo Galindo in 
branch 'master':
bpo-36886: Document changes in code object in What's new section (GH-13255)
https://github.com/python/cpython/commit/5d23e282af69d404a3430bb95aefe371112817b3


--

___
Python tracker 

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



[issue36886] Failed to construct CodeType on Python-3.8.0a4

2019-05-12 Thread Pablo Galindo Salgado


Change by Pablo Galindo Salgado :


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

___
Python tracker 

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



[issue36886] Failed to construct CodeType on Python-3.8.0a4

2019-05-12 Thread Big Stone


Big Stone  added the comment:

I found a third project that is impacted 
https://github.com/microsoft/python-language-server/issues/1070.

--

___
Python tracker 

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



[issue36886] Failed to construct CodeType on Python-3.8.0a4

2019-05-11 Thread Pablo Galindo Salgado


Pablo Galindo Salgado  added the comment:

After PR 13255 is merged, let's open a new issue for the notice in types.rst to 
keep the discussion isolated.

--

___
Python tracker 

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



[issue36886] Failed to construct CodeType on Python-3.8.0a4

2019-05-11 Thread Pablo Galindo Salgado


Pablo Galindo Salgado  added the comment:

>Understandable as well, just thinking that a CYA sentence in types.rst: 
>"These types are not supposed to be instantiated outside of CPython internals 
>and constructor signatures can vary between python versions.
>And maybe the docstrings. I rarely open the documentation on python.org and 
>work most of the time by calling `help()` or `?` in IPython, so having some 
>information saying this is non-public in the docstring would make sens to me. 
>I'm happy to do it if it is deemed useful.

I am +1 to such a sentence, but I think this is a decision that more core devs 
should agree on. Taking into account previous history (like the linked commit) 
and
the fact that promising stability on such internal pieces will prevent us from 
making critical optimizations I assume that others will agree, but I am still 
important
to know that there is a consensus.

I would recommend opening such PR if you have some time and let others review 
it as well.

--

___
Python tracker 

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



[issue36886] Failed to construct CodeType on Python-3.8.0a4

2019-05-11 Thread Matthias Bussonnier


Matthias Bussonnier  added the comment:

> There are other projects that have already added a fix for the new parameter 
> positionally. If we add it to be the last (that still will break the old 
> call) we would break them again.

Understandable


> The documentation never documented the arguments for the code type (probably 
> on purpose)

Understandable as well, just thinking that a CYA sentence in types.rst: 
"These types are not supposed to be instantiated outside of CPython internals 
and constructor signatures can vary between python versions.

And maybe the docstrings. I rarely open the documentation on python.org and 
work most of the time by calling `help()` or `?` in IPython, so having some 
information saying this is non-public in the docstring would make sens to me. 

I'm happy to do it if it is deemed useful.

--

___
Python tracker 

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



[issue36886] Failed to construct CodeType on Python-3.8.0a4

2019-05-11 Thread Pablo Galindo Salgado


Change by Pablo Galindo Salgado :


--
keywords: +patch
pull_requests: +13167
stage: resolved -> patch review

___
Python tracker 

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



[issue36886] Failed to construct CodeType on Python-3.8.0a4

2019-05-11 Thread Pablo Galindo Salgado


Change by Pablo Galindo Salgado :


--
title: problem with Types on Python-3.8.0a4 -> Failed to construct CodeType on 
Python-3.8.0a4

___
Python tracker 

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