[Python-Dev] Re: [python-committers] Currently working on the release of Python 3.8.0rc1

2019-10-01 Thread Łukasz Langa 
I merged it. In the future: you can use priorities on BPO issues to make it 
more visible.

- Ł



> On 1 Oct 2019, at 07:03, Giampaolo Rodola'  wrote:
> 
> Hello Łukasz,
> I consider this one critical enough to get into 3.8:
> https://bugs.python.org/issue38319 
> Long story short: shutil.copyfile() and socket.sendfile() are broken on 
> 32-bit platforms for files >= 2GiB.
> shutil.copyfile() was modified by me in the 3.8 cycle so the bug only affects 
> 3.8 and 3.9.
> 
> 
> On Mon, Sep 30, 2019 at 3:48 PM Łukasz Langa  > wrote:
> Team,
> amazing job on getting us back on track over the weekend.
> 
> Thank you
> All release blockers and deferred release blockers solved. And there was 
> relatively little additional activity on the branch -- as expected at this 
> point! Thank you for this, it will help get the release candidate out on time.
> 
> I'm working on cutting RC1 today
> Hopefully all sanity checks, as well as building the source tarball and the 
> binary installers for macOS and Windows will all work out fine and we'll be 
> seeing RC1 out tonight.
> 
> RC2 and the date of 3.8.0 gold
> If we manage to avoid the need for RC2, we will be able to release 3.8.0 on 
> October 14th. If we need an RC2, that will slip by a week. I hope we won't. 
> Ideally RC1 should be identical codewise to 3.8.0.
> 
> To help our chances, please avoid any source-related activity on the 3.8 
> branch from now until the release of 3.8.0. Yes, that also counts for bug 
> fixes unless they are critical. (Yeah, it might be a bit annoying but nobody 
> wants to be the person who introduced a last minute regression in a major 
> release.)
> 
> Note I didn't say I forbid any activity. I have no power over you, actually. 
> More importantly though, I trust your judgement if you assess some bug is bad 
> enough the fix absolutely has to get into 3.8.0. Moreover, I specifically 
> said source-related activity because...
> 
> 3.8.0 is important. To some users it will be the first and the last release 
> in the 3.8 series they will see.
> 
> We need you to focus on the docs now
> Are all your changes properly documented?
> Did you notice other changes you know of to have insufficient documentation?
> Can you help with the "What's New" document?
> 
> anxiously configure-&&-makingly y'rs
> - Ł
> ___
> python-committers mailing list -- [email protected] 
> 
> To unsubscribe send an email to [email protected] 
> 
> https://mail.python.org/mailman3/lists/python-committers.python.org/ 
> 
> Message archived at 
> https://mail.python.org/archives/list/[email protected]/message/ACMKEQNGK4FVUIZ6TYD5H26OSPIO5GSN/
>  
> 
> Code of Conduct: https://www.python.org/psf/codeofconduct/ 
> 
> 
> 
> --
> Giampaolo - http://grodola.blogspot.com 
> 



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/V2IRS7TBDMB7FOGQSCHD2NGGJ4F2USN3/

[Python-Dev] Re: [python-committers] Re: Currently working on the release of Python 3.8.0rc1

2019-10-01 Thread Victor Stinner 
Hi Łukasz,

Le lun. 30 sept. 2019 à 16:32, Łukasz Langa  a écrit :
> > On 30 Sep 2019, at 16:09, Nick Coghlan  wrote:
> >
> > I've filed https://bugs.python.org/issue38326 as a release blocker, as
> > I don't think we should be cutting RCs when changes have been made to
> > a PEP-approved API without any pre-merge design discussion.
>
> Nick, Victor, as co-authors of said PEP, please reach a decision ASAP.

Last Friday, I sent an python-dev to get feedback since I dislike
modifying a PEP which is already approved and I wasn't sure of the
design of my change (stable ABI for PyConfig).

There was an interesting discussion and it seems like we all agreed to
abandon the whole idea of a stable ABI, so I removed
PyConfig.struct_size. The change is already merged into 3.8 and the
PEP has been updated again.

Nick approved and merged my PRs which means that we agreed the on solution ;-)

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/ASPYFZ4J7JXSQBOUK54OC5KA4OX4FKAM/

[Python-Dev] Re: PEP 587 (Python Initialization Configuration) updated to be future proof again

2019-10-01 Thread Victor Stinner 
Sorry for the bad timing. I dislike working under pressure. The
discussion on python-dev, the bug tracker and pull requests was really
interesting.

The issue has been fixed: the whole idea of stable ABI for PyConfig
has been abandoned. If you want to switch to a different version of
Python when you embed Python, you must recompile your code. It was
always like that and the PEP 587 doesn't change anything.

PyConfig_InitPythonConfig() and PyConfig_InitIsolatedConfig()
initialize PyConfig to sane default configuration. So if we add new
fields in Python 3.9, you don't have to manually initialize these
fields, except if you explicitly want to use these new fields to
benefit of new configuration options.

Victor

Le mar. 1 oct. 2019 à 00:38, Nick Coghlan  a écrit :
>
>
>
> On Tue., 1 Oct. 2019, 6:47 am Victor Stinner,  wrote:
>>
>> Hi back,
>>
>> It seems like "config.struct_size = sizeof(PyConfig);" syntax is "not
>> really liked".
>>
>> I don't see any traction to provide a stable ABI for embedded Python.
>> The consensus is more towards: "it doesn't work and we don't want to
>> bother with false promises" (nor add code for that).
>>
>> Since Lukasz is supposed to tag 3.8.0rc1 today, I propose to remove
>> anything related to "stable API" or "stable ABI" from the PEP 587
>> right now. I wrote two PRs to remove struct_size:
>>
>> * CPython: https://github.com/python/cpython/pull/16500
>> * PEP 587: https://github.com/python/peps/pull/1185
>>
>> Later, if we decide to start proving a stable ABI for embedded Python,
>> we can still add a "version" or "struct_size" field to PyConfig later
>> (for example in Python 3.9).
>
>
> Thanks Victor, I think this is the right way for us to go, given the relative 
> timing in the release cycle.
>
> The idea of some day expanding the stable ABI to cover embedding 
> applications, not just extension modules, is an intriguing one, but I'm 
> genuinely unsure anyone would ever actually use it.
>
> Cheers,
> Nick.
>
>
>
>>
>> Victor
>> ___
>> Python-Dev mailing list -- [email protected]
>> To unsubscribe send an email to [email protected]
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at 
>> https://mail.python.org/archives/list/[email protected]/message/2JAJQA5OANFPXAJ3327RRPHPQLKVP2EW/



-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/36RTEPNE6HSPMXGDGSHWDJN56GZRX4YU/

[Python-Dev] Re: PEP 587 (Python Initialization Configuration) updated to be future proof again

2019-10-01 Thread Thomas Wouters 
On Mon, Sep 30, 2019 at 11:00 PM Brett Cannon  wrote:

> Victor Stinner wrote:
> > Hi Nick,
> > Le dim. 29 sept. 2019 à 08:47, Nick Coghlan [email protected] a écrit :
> > > I don't quite understand the purpose of this change,
> > > as there's no
> > > stable ABI for applications embedding CPython.
> > > Well, I would like to prepare Python to provide a stable ABI for
> > embedded Python. While it's not a design goal yet
> > (Include/cpython/initconfig.h is currently excluded from
> > Py_LIMITED_API), this change is a step towards that.
>
> So then isn't this a very last-minute, premature optimization if it isn't
> a design goal yet? If that's the case then I would vote not to make the
> change and wait until there's been feedback on 3.8 and then look at
> stabilizing the embedding API such that it can be considered stable.
>

I just want to chime in here and confirm, as a Professional CPython
Embedder(tm) that embedders cannot currently rely on a stable ABI, or the
limited API, and often not even the public API. It's not just about exposed
symbols and struct sizes, it's often also about the semantics of internals
(e.g. how importlib handles custom module finders and loaders) that subtly
changes. For anything but the simplest PyRun_SimpleString-based embedding
this is more the case when embedding than extending, and even than a
regular (complex) Python program. (I already showed Victor and a few others
some of the hoops we have to jump through at Google to embed CPython
correctly, and only half of those things are necessary just because of
Google's environment.)


>
> -Brett
>
> > > As a result, updating
> > > to a new X.Y.0 release always requires rebuilding the entire
> > > application, not just building and relinking CPython.
> > > In Python 3.8, C extensions are no longer linked to libpython which
> > allows to switch between a release build and a debug build of
> > libpython.
> > Can we imagine the same idea for embedded Python? I checked vim on
> > Linux: it's linked to libpython3.7m.so.1.0: a specific Python version,
> > library built in release mode.
> > > I could understand a change to require passing in an
> > > expected Python
> > > version so we can fail more gracefully on a bad link where an
> > > application that intended to embed Python 3.8 is incorrectly linked
> > > against Python 3.9 (for example), but performing that kind of check
> > > would require passing in PY_VERSION_HEX, not the size of the config
> > > struct.
> > > It seems simpler to me to pass the structure size rather than the
> > Python version. It avoids the risk of updating the structure without
> > update the Python version. I also avoids to have to change the Python
> > version immediately when PyConfig is modified. The main risk of
> > sizeof(PyConfig) comes if we remove a field and add a new field of
> > the same size: the structure size doesn't change... But in my
> > experience, we only add new ways to configure Pyhon, we never remove
> > old ones :-D
> > The question is if it's convenient to compute sizeof(PyConfig) in
> > programming languages other than C. Providing a "structure version" or
> > the structure size from a function call would not work. The value must
> > be known a compilation time, not at runtime. The purpose is to compare
> > the version/size between build and runtime (they must match).
> > In the first implementation of my PEP, I used an internal "config
> > version" provides by a macro. But it was said that macros are not
> > convenient.
> > PY_VERSION_HEX is provided as a macro, but we are now trying to avoid
> > macros in our C API, no? At least, it's what I understood from the PEP
> > 587 discussion.
> > > We don't support that - all our APIs that accept
> > > PyObject/PyTypeObject/etc require that the caller pass in structs of
> > > the correct size for the version of Python being used.
> > > For PyConfig, it's allocated (on the stack on or on heap) by the
> > application. So the application requires to access to the full
> > structure.
> > Objects (instances) are allocated by Python (on the heap).
> > Applications usually don't need to know/access the structure.
> > Python is far from being perfect, static types are still supported and
> > they are an issue for the stable ABI.
> > > The PyConfig
> > > and PyPreConfig structs are no different from PyObject in that regard:
> > > if there's a size mismatch, then the developers of the embedding
> > > application have somehow messed up their build process.
> > > In short, PyConfig initialization works like that:
> >
> > The application allocates a PyConfig object on the stack
> > Python calls memset(config, 0, sizeof(PyConfig))
> >
> > If there is a size mismatch, Python triggers a buffer overflow which
> > is likely to cause issues.
> > I prefer to have a clean API which makes buffer overflow impossible.
> > Embedding Python and handling different Python versions is not
> > trivial, especially if we start to add new fields to each PyConfig
> > (

[Python-Dev] [RELEASE] Python 3.8.0rc1 is now available

2019-10-01 Thread Łukasz Langa 
Python 3.8.0 is almost ready. After a rather tumultuous few days, we are very 
happy to announce the availability of the release candidate:

https://www.python.org/downloads/release/python-380rc1/ 


This release, 3.8.0rc1, is the final planned release preview. Assuming no 
critical problems are found prior to 2019-10-14, the scheduled release date for 
3.8.0, no code changes are planned between this release candidate and the final 
release.
Please keep in mind that this is not the gold release yet and as such its use 
is not recommended for production environments.

Major new features of the 3.8 series, compared to 3.7

Some of the new major new features and changes in Python 3.8 are:

PEP 572 , Assignment expressions
PEP 570 , Positional-only arguments
PEP 587 , Python Initialization 
Configuration (improved embedding)
PEP 590 , Vectorcall: a fast calling 
protocol for CPython
PEP 578 , Runtime audit hooks
PEP 574 , Pickle protocol 5 with 
out-of-band data
Typing-related: PEP 591  (Final 
qualifier), PEP 586  (Literal types), 
and PEP 589  (TypedDict)
Parallel filesystem cache for compiled bytecode
Debug builds share ABI as release builds
f-strings support a handy = specifier for debugging
continue is now legal in finally: blocks
on Windows, the default asyncio event loop is now ProactorEventLoop
on macOS, the spawn start method is now used by default in multiprocessing
multiprocessing can now use shared memory segments to avoid pickling costs 
between processes
typed_ast is merged back to CPython
LOAD_GLOBAL is now 40% faster
pickle now uses Protocol 4 by default, improving performance
(Hey, fellow core developer, if a feature you find important is missing from 
this list, let Łukasz know .)
Call to action: focus on the docs now

Are all your changes properly documented?
Did you notice other changes you know of to have insufficient documentation?
Can you help with the “What’s New 
” document?

- Ł



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/ECJX7GJHXZWJINLDGEAG42YQ32IYVBFL/

[Python-Dev] Re: [RELEASE] Python 3.8.0rc1 is now available

2019-10-01 Thread Miro Hrončok 

On 01. 10. 19 21:35, Łukasz Langa wrote:
Python 3.8.0 is *almost* ready. After a rather tumultuous few days, we are very 
happy to announce the availability of the release candidate:


https://www.python.org/downloads/release/python-380rc1/

This release, *3.8.0rc1*, is the final planned release preview. Assuming no 
critical problems are found prior to *2019-10-14*, the scheduled release date 
for *3.8.0*, no code changes are planned between this release candidate and the 
final release.


I don't see the v3.8.0rc1 tag on GitHub.
https://github.com/python/cpython/tree/v3.8.0rc1 gives 404

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/GA2AANKWSUDCLVWGLZ7FO5C6TZECPLTU/

[Python-Dev] Re: [RELEASE] Python 3.8.0rc1 is now available

2019-10-01 Thread Miro Hrončok 

On 01. 10. 19 21:54, Miro Hrončok wrote:

On 01. 10. 19 21:35, Łukasz Langa wrote:
Python 3.8.0 is *almost* ready. After a rather tumultuous few days, we are 
very happy to announce the availability of the release candidate:


https://www.python.org/downloads/release/python-380rc1/

This release, *3.8.0rc1*, is the final planned release preview. Assuming no 
critical problems are found prior to *2019-10-14*, the scheduled release date 
for *3.8.0*, no code changes are planned between this release candidate and 
the final release.


I don't see the v3.8.0rc1 tag on GitHub.
https://github.com/python/cpython/tree/v3.8.0rc1 gives 404


Now it is there, thanks.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/42ZNHX6UPPFBKB6XDBBLO7P6LTGTLPYQ/

[Python-Dev] Re: [RELEASE] Python 3.8.0rc1 is now available

2019-10-01 Thread Łukasz Langa 

> On 1 Oct 2019, at 21:54, Miro Hrončok  wrote:
> 
> On 01. 10. 19 21:35, Łukasz Langa wrote:
>> Python 3.8.0 is *almost* ready. After a rather tumultuous few days, we are 
>> very happy to announce the availability of the release candidate:
>> https://www.python.org/downloads/release/python-380rc1/
>> This release, *3.8.0rc1*, is the final planned release preview. Assuming no 
>> critical problems are found prior to *2019-10-14*, the scheduled release 
>> date for *3.8.0*, no code changes are planned between this release candidate 
>> and the final release.
> 
> I don't see the v3.8.0rc1 tag on GitHub.
> https://github.com/python/cpython/tree/v3.8.0rc1 gives 404

I was still working on that at the time, it's been fixed here: 
https://github.com/python/cpython/commits/3.8?author=ambv

Man, you're fast :-)

- Ł


signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/OLIVYCSY6C42U4PP4XQJPJ5NC2HJP3SL/

[Python-Dev] Re: [RELEASE] Python 3.8.0rc1 is now available

2019-10-01 Thread Miro Hrončok 

On 01. 10. 19 23:29, Łukasz Langa wrote:



On 1 Oct 2019, at 21:54, Miro Hrončok  wrote:

On 01. 10. 19 21:35, Łukasz Langa wrote:

Python 3.8.0 is *almost* ready. After a rather tumultuous few days, we are very 
happy to announce the availability of the release candidate:
https://www.python.org/downloads/release/python-380rc1/
This release, *3.8.0rc1*, is the final planned release preview. Assuming no 
critical problems are found prior to *2019-10-14*, the scheduled release date 
for *3.8.0*, no code changes are planned between this release candidate and the 
final release.


I don't see the v3.8.0rc1 tag on GitHub.
https://github.com/python/cpython/tree/v3.8.0rc1 gives 404


I was still working on that at the time, it's been fixed here: 
https://github.com/python/cpython/commits/3.8?author=ambv


Thanks.


Man, you're fast :-)


Rollin, rollin, rollin...
https://src.fedoraproject.org/rpms/python3/pull-request/135

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/UQVVBECGWPJENSU4PPTKGRHBK6UAIEGJ/

[Python-Dev] PEP 605: A rolling feature release stream for CPython

2019-10-01 Thread Nick Coghlan 
Hi folks,

Steve Dower and I have put together a proposal to try to reduce
feature delivery latency by changing our pre-release management
process such that beta releases are considered production ready.

The preferred discussion thread for that PEP is on Discourse here:
https://discuss.python.org/t/pep-605-a-rolling-feature-release-stream-for-cpython/2418/9

(Note: there are already some updates pending based on the initial
feedback in the thread, so folks may want to skim the thread before
reading the full PEP)

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/I24YZJZXPPTH3CSZXZAPU6OE47KXUUVR/