[Python-Dev] [RELEASE] Python 3.8.1rc1 is now available for testing

2019-12-10 Thread Łukasz Langa 
Python 3.8.1rc1 is the release candidate of the first maintenance release of 
Python 3.8.

The Python 3.8 series is the newest feature release of the Python language, and 
it contains many new features and optimizations. You can find Python 3.8.1rc1 
here:

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

Assuming no critical problems are found prior to 2019-12-16, the scheduled 
release date for 3.8.1 as well as Ned Deily's birthday, no code changes are 
planned between this release candidate and the final release.

That being said, please keep in mind that this is a pre-release of 3.8.1 and as 
such its main purpose is testing.

See the “What’s New in Python 3.8 
” document for more information 
about features included in the 3.8 series. Detailed information about all 
changes made in 3.8.0 can be found in its change log.

Maintenance releases for the 3.8 series will continue at regular bi-monthly 
intervals, with 3.8.2 planned for February 2020.

We hope you enjoy Python 3.8!

Thanks to all of the many volunteers who help make Python Development and these 
releases possible! Please consider supporting our efforts by volunteering 
yourself or through organization contributions to the Python Software 
Foundation.

https://www.python.org/psf/ 


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/IGJ6ZOAOT2WFY5ZIPRQNTHOSUMPUAO2H/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 611 -- why limit coroutines and classes?

2019-12-10 Thread Steven D'Aprano 
On Mon, Dec 09, 2019 at 11:27:56PM -0500, Kyle Stanley wrote:

> I agree, I think that sys would likely be the most reasonable place to read
> these limits from. Also, it seems like a good location for setting of the
> limits, if that becomes an option. This would go along well with the
> existing sys.getrecursionlimit() and sys.setrecursionlimit().
> 
> In general, this proposal would be much easier to consider if the limits
> were customizable. I'm not sure if it would be reasonable for all of the
> options, but it would at least allow those who have a legitimate use case
> for going beyond the limits (either now or in the future) to still be able
> to do so.

Someone will correct me if I'm wrong, but my reading of the PEP tells me 
that these are structural limits in the interpreter's internal data 
structures, so they can't be configured at runtime.

The impression I get is that you believe that the proposal is to add a 
bunch of runtime checks like this:

# pseudo-code for the module-loading code
lines = 0;
while 1
{
read and process line of code
lines += 1;
if lines >= 100:
GOTO error condition
}

In that case, it would be easy to change the 100 constant to a value 
that can be configured at runtime. You wouldn't even need to quit the 
running interpreter.

As I understand the PEP, the proposal is to change a bunch of C-level 
structs which currently contain 32-bit fields into 20-bit fields. To 
change that, you would need to recompile with new struct definitions and 
build a new interpreter binary.

If I'm right, making this configurable at *build-time* could be 
possible, but that's probably a bad idea. That's like the old "narrow 
versus wide Unicode" builds. It doubles (at least!) the amount of effort 
needed to maintain Python, for something which (if the PEP is correct) 
benefits nearly nobody but costs nearly everyone.



-- 
Steven
___
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/Q2UOEO3VOLG762WJ5N7LMJGX6ULUE6JR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 611 -- why limit coroutines and classes?

2019-12-10 Thread Kyle Stanley 
Steve D'Aprano wrote:
> As I understand the PEP, the proposal is to change a bunch of C-level
> structs which currently contain 32-bit fields into 20-bit fields. To
> change that, you would need to recompile with new struct definitions and
> build a new interpreter binary.
>
> If I'm right, making this configurable at *build-time* could be
> possible, but that's probably a bad idea. That's like the old "narrow
> versus wide Unicode" builds. It doubles (at least!) the amount of effort
> needed to maintain Python, for something which (if the PEP is correct)
> benefits nearly nobody but costs nearly everyone.

Ah, if that's case I'll withdraw the suggestion for allowing the limits to
be configurable through sys then. Thanks for the clarification.

I have some basic understanding of how C structs work, but I'll admit that
it's far from an area that I'm knowledgeable about. My feedback is mostly
based on experience as a user and involvement with stdlib development, not
as a C developer. I don't have a strong understanding of the implementation
details behind the limits.

Although if they're not (reasonably) configurable by most users, I would
consider that to further reinforce my previous statement that we should
have some form of concrete evidence; to prove that imposing the limits will
provide tangible benefits to the vast majority of Python users.

On Tue, Dec 10, 2019 at 4:45 AM Steven D'Aprano  wrote:

> On Mon, Dec 09, 2019 at 11:27:56PM -0500, Kyle Stanley wrote:
>
> > I agree, I think that sys would likely be the most reasonable place to
> read
> > these limits from. Also, it seems like a good location for setting of the
> > limits, if that becomes an option. This would go along well with the
> > existing sys.getrecursionlimit() and sys.setrecursionlimit().
> >
> > In general, this proposal would be much easier to consider if the limits
> > were customizable. I'm not sure if it would be reasonable for all of the
> > options, but it would at least allow those who have a legitimate use case
> > for going beyond the limits (either now or in the future) to still be
> able
> > to do so.
>
> Someone will correct me if I'm wrong, but my reading of the PEP tells me
> that these are structural limits in the interpreter's internal data
> structures, so they can't be configured at runtime.
>
> The impression I get is that you believe that the proposal is to add a
> bunch of runtime checks like this:
>
> # pseudo-code for the module-loading code
> lines = 0;
> while 1
> {
> read and process line of code
> lines += 1;
> if lines >= 100:
> GOTO error condition
> }
>
> In that case, it would be easy to change the 100 constant to a value
> that can be configured at runtime. You wouldn't even need to quit the
> running interpreter.
>
> As I understand the PEP, the proposal is to change a bunch of C-level
> structs which currently contain 32-bit fields into 20-bit fields. To
> change that, you would need to recompile with new struct definitions and
> build a new interpreter binary.
>
> If I'm right, making this configurable at *build-time* could be
> possible, but that's probably a bad idea. That's like the old "narrow
> versus wide Unicode" builds. It doubles (at least!) the amount of effort
> needed to maintain Python, for something which (if the PEP is correct)
> benefits nearly nobody but costs nearly everyone.
>
>
>
> --
> Steven
> ___
> 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/Q2UOEO3VOLG762WJ5N7LMJGX6ULUE6JR/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/V5T3GYC5UB4HICCSNHXXUKIZ4KV4YWQC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [RELEASE] Python 3.8.1rc1 is now available for testing

2019-12-10 Thread Miro Hrončok 

On 10. 12. 19 10:22, Łukasz Langa wrote:
Python 3.8.1rc1 is the release candidate of the first maintenance release of 
Python 3.8.


The Python 3.8 series is the newest feature release of the Python language, and 
it contains many new features and optimizations. You can find Python 3.8.1rc1 here:


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


Hey Łukasz. Could you please also push the tag to gihub?

--
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/R7DH5D5OTT2B6OBQKUT267HKSODJEFEL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [RELEASE] Python 3.8.1rc1 is now available for testing

2019-12-10 Thread Christian Tismer 
Hi Łukasz,

tonite I found a critical bug that affects all heaptype extension
classes with a custom (not PyType_Type) type.

the bug is in typeobject.c function type_mro_modified line 309:

if (custom) {
_Py_IDENTIFIER(mro);
mro_meth = lookup_maybe_method(
(PyObject *)type, &PyId_mro, &unbound);
if (mro_meth == NULL)
goto clear;
Py_INCREF(mro_meth);
type_mro_meth = lookup_maybe_method(
(PyObject *)&PyType_Type, &PyId_mro, &unbound);
if (type_mro_meth == NULL)
goto clear;
Py_INCREF(type_mro_meth);
if (mro_meth != type_mro_meth)
goto clear;
Py_XDECREF(mro_meth);
Py_XDECREF(type_mro_meth);
}

This block is wrong because it decrefs a value that comes from
lookup_maybe_method which does not incref.

The code is easily fixed by two Py_INCREF s.

Please let me know how you want to proceed.
This is a critical error, producing negative refcounts.

Cheers -- Chris


On 10.12.19 10:22, Łukasz Langa wrote:
> Python 3.8.1rc1 is the release candidate of the first maintenance
> release of Python 3.8.
> 
> The Python 3.8 series is the newest feature release of the Python
> language, and it contains many new features and optimizations. You can
> find Python 3.8.1rc1 here:
> 
> https://www.python.org/downloads/release/python-381rc1/
> 
> Assuming no critical problems are found prior to *2019-12-16*, the
> scheduled release date for *3.8.1* as well as *Ned Deily's birthday*, no
> code changes are planned between this release candidate and the final
> release.
> 
> That being said, please keep in mind that this is a pre-release of 3.8.1
> and as such its main purpose is testing.
> 
> See the “What’s New in Python 3.8
> ” document for more
> information about features included in the 3.8 series. Detailed
> information about all changes made in 3.8.0 can be found in its change log.
> 
> Maintenance releases for the 3.8 series will continue at regular
> bi-monthly intervals, with *3.8.2* planned for February 2020.
> 
> 
>   We hope you enjoy Python 3.8!
> 
> Thanks to all of the many volunteers who help make Python Development
> and these releases possible! Please consider supporting our efforts by
> volunteering yourself or through organization contributions to the
> Python Software Foundation.
> 
> https://www.python.org/psf/
> 
> 
> ___
> 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/IGJ6ZOAOT2WFY5ZIPRQNTHOSUMPUAO2H/
> Code of Conduct: http://python.org/psf/codeofconduct/
> 


-- 
Christian Tismer :^)   [email protected]
Software Consulting  : http://www.stackless.com/
Karl-Liebknecht-Str. 121 : https://github.com/PySide
14482 Potsdam: GPG key -> 0xFB7BEE0E
phone +49 173 24 18 776  fax +49 (30) 700143-0023



signature.asc
Description: OpenPGP digital signature
___
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/6VIEOGQJ433TVQZRYFXQ7SWQM3XRBBKD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [RELEASE] Python 3.8.1rc1 is now available for testing

2019-12-10 Thread Christian Tismer 
Sorry, I sent the fixed version.
These two incref's are missing!

On 10.12.19 14:16, Christian Tismer wrote:
> Hi Łukasz,
> 
> tonite I found a critical bug that affects all heaptype extension
> classes with a custom (not PyType_Type) type.
> 
> the bug is in typeobject.c function type_mro_modified line 309:
> 
> if (custom) {
> _Py_IDENTIFIER(mro);
> mro_meth = lookup_maybe_method(
> (PyObject *)type, &PyId_mro, &unbound);
> if (mro_meth == NULL)
> goto clear;

This one
> Py_INCREF(mro_meth);
> type_mro_meth = lookup_maybe_method(
> (PyObject *)&PyType_Type, &PyId_mro, &unbound);
> if (type_mro_meth == NULL)
> goto clear;

And this one
> Py_INCREF(type_mro_meth);
> if (mro_meth != type_mro_meth)
> goto clear;
> Py_XDECREF(mro_meth);
> Py_XDECREF(type_mro_meth);
> }
> 
> This block is wrong because it decrefs a value that comes from
> lookup_maybe_method which does not incref.
> 
> The code is easily fixed by two Py_INCREF s.
> 
> Please let me know how you want to proceed.
> This is a critical error, producing negative refcounts.
> 
> Cheers -- Chris

-- 
Christian Tismer :^)   [email protected]
Software Consulting  : http://www.stackless.com/
Karl-Liebknecht-Str. 121 : https://github.com/PySide
14482 Potsdam: GPG key -> 0xFB7BEE0E
phone +49 173 24 18 776  fax +49 (30) 700143-0023



signature.asc
Description: OpenPGP digital signature
___
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/K2SX7F7P5CXJ7PMK2AAIU7JTAG2AH2A5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [RELEASE] Python 3.8.1rc1 is now available for testing

2019-12-10 Thread Miro Hrončok 

On 10. 12. 19 14:34, Łukasz Langa wrote:



On 10 Dec 2019, at 13:01, Miro Hrončok  wrote:

On 10. 12. 19 10:22, Łukasz Langa wrote:

Python 3.8.1rc1 is the release candidate of the first maintenance release of 
Python 3.8.
The Python 3.8 series is the newest feature release of the Python language, and 
it contains many new features and optimizations. You can find Python 3.8.1rc1 
here:
https://www.python.org/downloads/release/python-381rc1/


Hey Łukasz. Could you please also push the tag to gihub?


Done.


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/RNVTWQ43F3EW5GQH4FBDI2V46UQD76FZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [RELEASE] Python 3.8.1rc1 is now available for testing

2019-12-10 Thread Łukasz Langa 

> On 10 Dec 2019, at 14:16, Christian Tismer  wrote:
> 
> Please let me know how you want to proceed.
> This is a critical error, producing negative refcounts.

Is there a BPO issue for this? If not, there should be, let's discuss there. Is 
this a 3.8 regression?

3.8.1 proper is next Monday, if this fix is handled quickly it will land in 
3.8.1.

- Ł


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/X4V3MV5BKWCG6T7Q6R2CTJUXE5HPQPJD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Please be more precise when commenting on PEP 611.

2019-12-10 Thread Rhodri James 

On 10/12/2019 00:01, Chris Angelico wrote:

Exactly. Yes, I know that I massively oversimplified things in that
post. But you nonetheless acknowledge here that we are*still*  quite
lacking in any actual evidence. We have people who believe that a bit
mask will slow things down, others who claim that improved cache
locality will speed things up, and Mark asks us to please justify our
objections with numbers. But surely it's up to Mark to show numbers
first?


+1

--
Rhodri James *-* Kynesim Ltd
___
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/Y2SKFQBYZRWWLRWD35M6NKSFQWDMECZP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [RELEASE] Python 3.8.1rc1 is now available for testing

2019-12-10 Thread Łukasz Langa 

> On 10 Dec 2019, at 13:01, Miro Hrončok  wrote:
> 
> On 10. 12. 19 10:22, Łukasz Langa wrote:
>> Python 3.8.1rc1 is the release candidate of the first maintenance release of 
>> Python 3.8.
>> The Python 3.8 series is the newest feature release of the Python language, 
>> and it contains many new features and optimizations. You can find Python 
>> 3.8.1rc1 here:
>> https://www.python.org/downloads/release/python-381rc1/
> 
> Hey Łukasz. Could you please also push the tag to gihub?

Done.

- Ł



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/JFORWNC2DYRTEJEJPOCM6G4LAGQAE3QI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [python-committers] Re: [RELEASE] Python 3.8.1rc1 is now available for testing

2019-12-10 Thread Victor Stinner 
Can you please open an issue at https://bugs.python.org/ and then post
the link in this thread?

Thanks in advance,
Victor

Le mar. 10 déc. 2019 à 14:18, Christian Tismer  a écrit :
>
> Hi Łukasz,
>
> tonite I found a critical bug that affects all heaptype extension
> classes with a custom (not PyType_Type) type.
>
> the bug is in typeobject.c function type_mro_modified line 309:
>
> if (custom) {
> _Py_IDENTIFIER(mro);
> mro_meth = lookup_maybe_method(
> (PyObject *)type, &PyId_mro, &unbound);
> if (mro_meth == NULL)
> goto clear;
> Py_INCREF(mro_meth);
> type_mro_meth = lookup_maybe_method(
> (PyObject *)&PyType_Type, &PyId_mro, &unbound);
> if (type_mro_meth == NULL)
> goto clear;
> Py_INCREF(type_mro_meth);
> if (mro_meth != type_mro_meth)
> goto clear;
> Py_XDECREF(mro_meth);
> Py_XDECREF(type_mro_meth);
> }
>
> This block is wrong because it decrefs a value that comes from
> lookup_maybe_method which does not incref.
>
> The code is easily fixed by two Py_INCREF s.
>
> Please let me know how you want to proceed.
> This is a critical error, producing negative refcounts.
>
> Cheers -- Chris
>
>
> On 10.12.19 10:22, Łukasz Langa wrote:
> > Python 3.8.1rc1 is the release candidate of the first maintenance
> > release of Python 3.8.
> >
> > The Python 3.8 series is the newest feature release of the Python
> > language, and it contains many new features and optimizations. You can
> > find Python 3.8.1rc1 here:
> >
> > https://www.python.org/downloads/release/python-381rc1/
> >
> > Assuming no critical problems are found prior to *2019-12-16*, the
> > scheduled release date for *3.8.1* as well as *Ned Deily's birthday*, no
> > code changes are planned between this release candidate and the final
> > release.
> >
> > That being said, please keep in mind that this is a pre-release of 3.8.1
> > and as such its main purpose is testing.
> >
> > See the “What’s New in Python 3.8
> > ” document for more
> > information about features included in the 3.8 series. Detailed
> > information about all changes made in 3.8.0 can be found in its change log.
> >
> > Maintenance releases for the 3.8 series will continue at regular
> > bi-monthly intervals, with *3.8.2* planned for February 2020.
> >
> >
> >   We hope you enjoy Python 3.8!
> >
> > Thanks to all of the many volunteers who help make Python Development
> > and these releases possible! Please consider supporting our efforts by
> > volunteering yourself or through organization contributions to the
> > Python Software Foundation.
> >
> > https://www.python.org/psf/
> >
> >
> > ___
> > 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/IGJ6ZOAOT2WFY5ZIPRQNTHOSUMPUAO2H/
> > Code of Conduct: http://python.org/psf/codeofconduct/
> >
>
>
> --
> Christian Tismer :^)   [email protected]
> Software Consulting  : http://www.stackless.com/
> Karl-Liebknecht-Str. 121 : https://github.com/PySide
> 14482 Potsdam: GPG key -> 0xFB7BEE0E
> phone +49 173 24 18 776  fax +49 (30) 700143-0023
>
> ___
> 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/6VIEOGQJ433TVQZRYFXQ7SWQM3XRBBKD/
> Code of Conduct: https://www.python.org/psf/codeofconduct/



-- 
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/G5FRX7T5HC4QEIJSSNBUJWKSSBV2CV3R/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [RELEASE] Python 3.8.1rc1 is now available for testing

2019-12-10 Thread Christian Tismer 
On 10.12.19 14:28, Łukasz Langa wrote:
> 
>> On 10 Dec 2019, at 14:16, Christian Tismer > > wrote:
>>
>> Please let me know how you want to proceed.
>> This is a critical error, producing negative refcounts.
> 
> Is there a BPO issue for this? If not, there should be, let's discuss
> there. Is this a 3.8 regression?
> 
> 3.8.1 proper is next Monday, if this fix is handled quickly it will land
> in 3.8.1.


Yes, this problem exists since the first 3.8.0 version.
I did not create a PR, yet because it took me so long
to understand that this time it was really not a PySide problem ;-)

I will try to produce one ASAP.

-- 
Christian Tismer :^)   [email protected]
Software Consulting  : http://www.stackless.com/
Karl-Liebknecht-Str. 121 : https://github.com/PySide
14482 Potsdam: GPG key -> 0xFB7BEE0E
phone +49 173 24 18 776  fax +49 (30) 700143-0023



signature.asc
Description: OpenPGP digital signature
___
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/BWHTDGNDKZFE4G6GK7ASSY4WTANBGMZ5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [python-committers] Re: [RELEASE] Python 3.8.1rc1 is now available for testing

2019-12-10 Thread Christian Tismer 
Howdy,

I have produced this:
https://bugs.python.org/issue39016

No idea if it's correct, doing that too rarely.

Cheers -- Chris


On 10.12.19 14:34, Victor Stinner wrote:
> Can you please open an issue at https://bugs.python.org/ and then post
> the link in this thread?
> 
> Thanks in advance,
> Victor
> 
> Le mar. 10 déc. 2019 à 14:18, Christian Tismer  a écrit 
> :
>>
>> Hi Łukasz,
>>
>> tonite I found a critical bug that affects all heaptype extension
>> classes with a custom (not PyType_Type) type.
>>
>> the bug is in typeobject.c function type_mro_modified line 309:
>>
>> if (custom) {
>> _Py_IDENTIFIER(mro);
>> mro_meth = lookup_maybe_method(
>> (PyObject *)type, &PyId_mro, &unbound);
>> if (mro_meth == NULL)
>> goto clear;
>> Py_INCREF(mro_meth);
>> type_mro_meth = lookup_maybe_method(
>> (PyObject *)&PyType_Type, &PyId_mro, &unbound);
>> if (type_mro_meth == NULL)
>> goto clear;
>> Py_INCREF(type_mro_meth);
>> if (mro_meth != type_mro_meth)
>> goto clear;
>> Py_XDECREF(mro_meth);
>> Py_XDECREF(type_mro_meth);
>> }
>>
>> This block is wrong because it decrefs a value that comes from
>> lookup_maybe_method which does not incref.
>>
>> The code is easily fixed by two Py_INCREF s.
>>
>> Please let me know how you want to proceed.
>> This is a critical error, producing negative refcounts.
>>
>> Cheers -- Chris
>>
>>
>> On 10.12.19 10:22, Łukasz Langa wrote:
>>> Python 3.8.1rc1 is the release candidate of the first maintenance
>>> release of Python 3.8.
>>>
>>> The Python 3.8 series is the newest feature release of the Python
>>> language, and it contains many new features and optimizations. You can
>>> find Python 3.8.1rc1 here:
>>>
>>> https://www.python.org/downloads/release/python-381rc1/
>>>
>>> Assuming no critical problems are found prior to *2019-12-16*, the
>>> scheduled release date for *3.8.1* as well as *Ned Deily's birthday*, no
>>> code changes are planned between this release candidate and the final
>>> release.
>>>
>>> That being said, please keep in mind that this is a pre-release of 3.8.1
>>> and as such its main purpose is testing.
>>>
>>> See the “What’s New in Python 3.8
>>> ” document for more
>>> information about features included in the 3.8 series. Detailed
>>> information about all changes made in 3.8.0 can be found in its change log.
>>>
>>> Maintenance releases for the 3.8 series will continue at regular
>>> bi-monthly intervals, with *3.8.2* planned for February 2020.
>>>
>>>
>>>   We hope you enjoy Python 3.8!
>>>
>>> Thanks to all of the many volunteers who help make Python Development
>>> and these releases possible! Please consider supporting our efforts by
>>> volunteering yourself or through organization contributions to the
>>> Python Software Foundation.
>>>
>>> https://www.python.org/psf/
>>>
>>>
>>> ___
>>> 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/IGJ6ZOAOT2WFY5ZIPRQNTHOSUMPUAO2H/
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>>
>>
>> --
>> Christian Tismer :^)   [email protected]
>> Software Consulting  : http://www.stackless.com/
>> Karl-Liebknecht-Str. 121 : https://github.com/PySide
>> 14482 Potsdam: GPG key -> 0xFB7BEE0E
>> phone +49 173 24 18 776  fax +49 (30) 700143-0023
>>
>> ___
>> 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/6VIEOGQJ433TVQZRYFXQ7SWQM3XRBBKD/
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
> 
> 
> 


-- 
Christian Tismer :^)   [email protected]
Software Consulting  : http://www.stackless.com/
Karl-Liebknecht-Str. 121 : https://github.com/PySide
14482 Potsdam: GPG key -> 0xFB7BEE0E
phone +49 173 24 18 776  fax +49 (30) 700143-0023
___
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/6A7UURL224NQQFHRJXRQYKVTRWNHLLGR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [python-committers] [RELEASE] Python 3.8.1rc1 is now available for testing

2019-12-10 Thread Jason R. Coombs 
I think I missed the announcement of the cutoff date for 3.8.1; I was hoping to 
get some bug fixes in for 
importlib.metadata.

These aren’t crucial bugfixes, but it would be nice not to have them linger for 
months. Would you consider including these, especially as the code changes are 
pre-vetted in the backport (released 12-01)? Or maybe only if there’s another 
RC for another reason?

If it’s too disruptive, that’s no big deal. Your call.

Thanks for the release work.

On 10 Dec, 2019, at 04:22, Łukasz Langa 
mailto:[email protected]>> wrote:


Python 3.8.1rc1 is the release candidate of the first maintenance release of 
Python 3.8.

The Python 3.8 series is the newest feature release of the Python language, and 
it contains many new features and optimizations. You can find Python 3.8.1rc1 
here:

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

Assuming no critical problems are found prior to 2019-12-16, the scheduled 
release date for 3.8.1 as well as Ned Deily's birthday, no code changes are 
planned between this release candidate and the final release.

That being said, please keep in mind that this is a pre-release of 3.8.1 and as 
such its main purpose is testing.

See the “What’s New in Python 
3.8” document for more 
information about features included in the 3.8 series. Detailed information 
about all changes made in 3.8.0 can be found in its change log.

Maintenance releases for the 3.8 series will continue at regular bi-monthly 
intervals, with 3.8.2 planned for February 2020.

We hope you enjoy Python 3.8!

Thanks to all of the many volunteers who help make Python Development and these 
releases possible! Please consider supporting our efforts by volunteering 
yourself or through organization contributions to the Python Software 
Foundation.

https://www.python.org/psf/

___
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/IGJ6ZOAOT2WFY5ZIPRQNTHOSUMPUAO2H/
Code of Conduct: https://www.python.org/psf/codeofconduct/

___
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/YX4DTT26DNYQFUBW5EHPODYMRGT4ZOQX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Feedback on PEP 611 (so far) from the Steering Council

2019-12-10 Thread Barry Warsaw 
The Python Steering Council discussed PEP 611 at today’s meeting.  Here is our 
feedback so far:

* The Steering Council reserves the right to be the BDFL-Delegate for this PEP

* The PEP should clearly delineate two aspects:

  - A language generic part (i.e. applies to all implementations of Python) 
which exposes implementation limits in a way that Python code can read at 
runtime.  Think sys.getrecursionlimit(), sys.maxsize, and sys.implementation

  - An implementation-specific part where the PEP would propose specific limits 
for the CPython implementation.  Other implementations of the Python language 
would be free to adjust such limits up or down as they deem appropriate.

* We encourage the PEP authors and proponents to gather actual performance data 
that can be used to help us evaluate whether this PEP is a good idea or not.

By all means, continue to discuss and refine the PEP.  When the PEP author is 
ready for a pronouncement, you can email the Steering Council.

Cheers,
-Barry



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/KY46EXGLKNTFMQZXKHMMYWD2GIM5PDL5/
Code of Conduct: http://python.org/psf/codeofconduct/