Re: [Python-Dev] Initial updates to PEP 1 for Steering Council based governance

[Victor Stinner]

Hi,

Le lun. 11 mars 2019 à 13:26, Nick Coghlan  a écrit :
> This is the smallest change to PEP 1 that we consider potentially viable: 
> handling all PEPs through the BDFL-Delegate model, with the Steering 
> Council's primary involvement being to appoint the delegates (or accept their 
> volunteering), once a PEP has reached the point of being actively reviewed.

Does it mean that very controversial PEPs like PEP 572 would have a
BDFL-delegate as well? The delegate will be the only one taking the
final decision?

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Typing Summit at PyCon?

[Guido van Rossum]

If you're going to PyCon and interested in static typing for Python (e.g.
mypy, pytype, Pyre, PyCharm), I have something for you. I am hoping to
organize a Typing Summit, on Thursday afternoon, May 2nd. If you're
interested, please reply to me so I can gauge interest.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Initial updates to PEP 1 for Steering Council based governance

[Brett Cannon]

On Thu, Mar 14, 2019 at 10:02 AM Victor Stinner  wrote:

> Hi,
>
> Le lun. 11 mars 2019 à 13:26, Nick Coghlan  a écrit :
> > This is the smallest change to PEP 1 that we consider potentially
> viable: handling all PEPs through the BDFL-Delegate model, with the
> Steering Council's primary involvement being to appoint the delegates (or
> accept their volunteering), once a PEP has reached the point of being
> actively reviewed.
>
> Does it mean that very controversial PEPs like PEP 572 would have a
> BDFL-delegate as well? The delegate will be the only one taking the
> final decision?
>

Probably not. In cases where no clear BDFL Delegate can be identified the
SC will probably handle the decision.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] How to create a child process using multiprocessing in Python2.7.10 without the child sharing resources with parent?

[Jigar Bhalodia]

Hello,

We are trying to move our python 2.7.10 codebase from Windows to Linux. We
recently discovered that multiprocessing library in Python 2.7 behaves
differently on Windows vs Linux. We have found many articles like this one

describing
the problem however, we are unable to find a solution online for Python
2.7. This is a fix

for
this issue in Python 3.4 however, we are unable to upgrade to Python 3.4.
Is there any way to use multiprocessing in Python 2.7 on Linux without the
child and parent sharing memory? We can also use guidance on modifying
forking.py

code
in python 2.7 to ensure child and parent process aren't sharing memory and
doing Copy-on-Write. Thanks!

https://stackoverflow.com/questions/55168149/how-to-create-a-child-process-using-multiprocessing-in-python2-7-10-without-the

Thanks,
Jigar
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] int() and math.trunc don't accept objects that only define __index__

[Steven D'Aprano]

On Wed, Mar 13, 2019 at 03:21:31AM -0700, Rémi Lapeyre wrote:

> When __index__ is defined it means that there is a lossless conversion
> to int possible. In this case, this means a lossless conversion to
> float and complex is also possible 

That's not correct:

py> n = 2**64 + 1
py> n == int(float(n))
False

Python floats (C doubles) can lose digits when converting from ints 
over 2**53 or so.


> (with the exception of overflows
> but anyone doing float(var) should expect them).

I don't. I expect float(var) to overflow to infinity, if it is going to 
overflow, and always forget that it can raise.


py> float("9e")
inf

py> float(str(9*10**))
inf

But:

py> float(9*10**)
Traceback (most recent call last):
  File "", line 1, in 
OverflowError: int too large to convert to float

This never fails to surprise me.




-- 
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com