The steering council felt the PEP was too broad and not focused enough.
Discussions about adding more attributes to built-in exceptions can
continue on the issue tracker on a per-exception basis (and obviously here
for any broader points, e.g. performance implications as I know that has
come up before when the idea of storing relevant objects on exceptions).
Thanks to Sebastian Kreft for taking the time to write the PEP in the first
place.
I'd like to formally present to Python-dev PEP 581: Using GitHub Issues for
CPython
Full text: https://www.python.org/dev/peps/pep-0581/
This is my first PEP, and in my opinion it is ready for wider discussion. I
don't know if it is "ready for pronouncement" so I'm hoping to get more
guidance about it from other experienced core devs and steering council.
I also plan to open discussion about PEP 581 at Python Language Summit, and
since I'm one-half of the language summit chairs, it is quite likely this
discussion will happen.
On that note, you can still sign up for the language summit here:
https://us.pycon.org/2019/events/language-summit/
Note that unlike previous years, you do not need to be invited by a core
developer. Łukasz and I will be curating the content, and we want to
include more diverse perspectives into language summit discussions.
Thanks.
ᐧ
Hi folks,
Brett recently posted about the update to PEP 1 that added the PEP Sponsor
role, but folks may not have noticed that we've also made the amendments
needed to allow the PEP decision making process to restart:
https://github.com/python/peps/pull/896/files
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.
We'll also act as an ongoing consulting resource for anyone that takes on
the BD role for a PEP.
We're currently working through the follow-up activity, which is to review
the list of Draft PEPs, and work out which ones are at a point where
assigning a BDFL-Delegate makes sense.
Cheers,
Nick.
The steering council has decided to reject PEP 542 as the idea never seemed
to gain traction.
Thanks to Markus Meskanen for taking the time to write the PEP.
Hello,
some time ago I contributed a couple of patches to speedup shutil.copy*()
functions:
https://bugs.python.org/issue33671https://bugs.python.org/issue33695
I would like to backport both functionalities so that they can be used on
Python 2.7 and <3.8 and put it on PYPI. In order to do so I will basically
have to copy some parts of shutil module (copytree() function + the
unit-tests I added in BPO-33671 and a couple of other things). Are there
constraints regarding this in terms of license? Am I supposed to use GPL?
(I was thinking about using MIT)
Note: in this package called "zerocopy" I will probably want to expose
other functionalities such as tee(), splice() and CopyFileEx and
TransmitFile on Windows, so it's probably gonna be half a backport and half
a brand new project.
Thanks.
--
Giampaolo - http://grodola.blogspot.com
Hi, I open this thread to discuss the proposal by Nick Coghlan in
https://bugs.python.org/issue33039
to add __int__ and __trunc__ to a type when __index__ is defined.
Currently __int__ does not default to __index__ during class initialisation
so
both must be defined to get a coherant behavior:
(cpython-venv) ➜ cpython git:(add-key-argument-to-bisect) ✗ python3
Python 3.8.0a1+ (heads/add-key-argument-to-bisect:b7aaa1adad, Feb 18
2019, 16:10:22)
[Clang 10.0.0 (clang-1000.10.44.4)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
>>> class MyInt:
... def __index__(self):
... return 4
...
>>> int(MyInt())
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: int() argument must be a string, a bytes-like object or a
number, not 'MyInt'
>>> math.trunc(MyInt())
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: type MyInt doesn't define __trunc__ method
>>> hex(MyInt())
'0x4'
>>> len("a"*MyInt())
4
>>> MyInt.__int__ = MyInt.__index__
>>> int(MyInt())
4
The difference in behavior is espacially weird in builtins like int() and
hex().
The documentation mentions at
https://docs.python.org/3/reference/datamodel.html#object.__index__
the need to always define both __index__ and __int__:
Note: In order to have a coherent integer type class, when __index__()
is defined __int__() should also be defined, and both should return the
same value.
Nick Coghlan proposes to make __int__ defaults to __index__ when only the
second
is defined and asked to open a discussion on python-dev before making any
change
"as the closest equivalent we have to this right now is the "negative"
derivation,
where overriding __eq__ without overriding __hash__ implicitly marks the
derived
class as unhashable (look for "type->tp_hash =
PyObject_HashNotImplemented;").".
I think the change proposed makes more sense than the current behavior and
volunteer to implement it if it is accepted.
What do you think about this?
