Mailman 3 December 2017 - Python-ideas

a set of enum.Enum values rather than the construction of bit-sets as the "norm"?
by Paddy3118 03 Jan '18

03 Jan '18

Maybe it is time to deemphasize the creation and passing of what is, in effect, bit-sets <https://en.wikipedia.org/wiki/Bit_array>as a single argument, and instead promote the passing of a set of members of an enum.Enum <https://docs.python.org/3/library/enum.html> constants. Thi comes about because someone wrote a description, (since deleted), of constructing bit-sets to use in passing flags to, for example, the re.compile <https://docs.python.org/3/library/re.html#re.compile>function. The use of individual bits in a bit-array/bit-set to pass multiple flags is an implementation detail. Should we not *first *teach the passing of a set of enum.Enum constant values in one argument as the *pythonic *way; and leave bit-sets and other types of enum's as a performance or interoperability detail? Comments please, (And a happy new year to you :-)

10 20

Improve ABCs _dump_registry() readability
by Yahya Abou 'Imran 31 Dec '17

31 Dec '17

In python 2.7, ABCs's caches and registries are sets. But in python 3.6 they are WeakSet. In consequence, the output of _dump_registry() is almost useless: >>> from collections import abc >>> abc.Iterator._dump_registry() Class: collections.abc.Iterator Inv.counter: 40 _abc_cache: <_weakrefset.WeakSet object at 0x7f4b58fe2668> _abc_negative_cache: <_weakrefset.WeakSet object at 0x7f4b53283780> _abc_negative_cache_version: 40 _abc_registry: <_weakrefset.WeakSet object at 0x7f4b58fe2630> We could convert them into a regular set before printing: if isinstance(value, WeakSet): value = set(value) The result: >>> abc.Iterator._dump_registry() Class: collections.abc.Iterator Inv.counter: 40 _abc_cache: {<class 'dict_valueiterator'>, <class 'bytearray_iterator'>, <class 'tuple_iterator'>, <class 'dict_itemiterator'>, <class 'dict_keyiterator'>, <class 'str_iterator'>, <class 'zip'>, <class 'set_iterator'>, <class 'list_reverseiterator'>, <class 'range_iterator'>, <class 'longrange_iterator'>, <class 'list_iterator'>, <class 'bytes_iterator'>} _abc_negative_cache: set() _abc_negative_cache_version: 40 _abc_registry: set() NB: It seems pretty weird to me that registry is empty... All the iterators in the cache should've been in the registry instead, should'nt they?

4 7

Change the __repr__ of the `MappingView`s
by Yahya Abou 'Imran 30 Dec '17

30 Dec '17

=== This proposition is purely aesthetic === At this time, the __repr__ of the mapping views is showing the whole mapping: >>> from collections.abc import ValuesView, KeysView, ItemsView >>> d = {3: 'three', 4: 'four'} >>> KeysView(d) KeysView({3: 'three', 4: 'four'}) >>> ValuesView(d) ValuesView({3: 'three', 4: 'four'}) >>> ItemsView(d) ItemsView({3: 'three', 4: 'four'}) Witch is not consistent with dict_keys, dict_values, dict_items: >>> d.keys() dict_keys([3, 4]) >>> d.values() dict_values(['three', 'four']) >>> d.items() dict_items([(3, 'three'), (4, 'four')]) We could easily change that, since all the views are iterables on what they are designed for, in MappingView: def __repr__(self): viewname = self.__class__.__name__ elements = ', '.join(map(repr, self)) return f'{viewname}([elements]) And now: >>> KeysView(d) KeysView([3, 4]) >>> ValuesView(d) ValuesView(['three', 'four']) >>> ItemsView(d) ItemsView([(3, 'three'), (4, 'four')]) It's not breaking any test (it seems that there isn't any for this), but it have a real drawback: it's breaking the convention about instantiation by copy/pasting: >>> ValuesView(['three', 'four']) Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/IPython/core/formatters.py", line 684, in __call__ return repr(obj) File "/usr/lib/python3.6/_collections_abc.py", line 706, in __repr__ elements = ', '.join(map(repr, self)) File "/usr/lib/python3.6/_collections_abc.py", line 764, in __iter__ yield self._mapping[key] TypeError: list indices must be integers or slices, not str It's because __init__ in MappingView treat the passed argument -- wich is stored in self._mapping -- as the whole mapping, not just keys, values or items... And all the other methods (__contains__ and __iter__) in the subclasses are using this _mapping attribute to work. So what is to prioritize?

2 1

Make MappingView inherit from Collection instead of Sized
by Yahya Abou 'Imran 29 Dec '17

29 Dec '17

After I generate an UML diagram from collections.abc, I found very strange that MappingView inherit from Sized instead of Collection (new in python 3.6). Yes, MappingView only define __len__ and not __iter__ and __contains__, but all of its subclasses define them (KeysView, ValuesView and ItemViews). I tried to run the tests in test/test_collections.py after making this change and on only one fail : Traceback (most recent call last): File "/usr/lib/python3.6/test/test_collections.py", line 789, in test_Collection self.assertNotIsInstance(x, Collection) AssertionError: dict_values([]) is an instance of <class 'collections.abc.Collection'> Wich is absolutely wrong, since in reality a dict_values instance has the behaviour of a Collection: >>> vals = {1:'a', 2: 'b'}.values() >>> 'a' in vals True >>> 'c' in vals False >>> len(vals) 2 >>> for val in vals: ... print(val) ... a b The only lack is that it doesn't define a __contains__ method: >>> '__contains__' in vals False It uses __iter__ to find the presence of the value. But, hey: we have register() for this cases! In fact, when MappingView inherit from Collection, dict_values is considered as a subclass of Collection since it's in the register of ValuesView, causing the above bug... So, the test have to be changed, and dict_values must be placed in the samples that pass the test, and not in the ones that fail it. Maybe we can open an issue on the python bug tracker?

2 1

Is there a reason some of the PyLong_As* functions don't call an object's __int__?
by Erik Bray 29 Dec '17

29 Dec '17

IIUC, it seems to be carry-over from Python 2's PyLong API, but I don't see an obvious reason for it. In every case there's an explicit PyLong_Check first anyways, so not calling __int__ doesn't help for the common case of exact int objects; adding the fallback costs nothing in that case. I ran into this because I was passing an object that implements __int__ to the maxlen argument to deque(). On Python 2 this used PyInt_AsSsize_t which does fall back to calling __int__, whereas PyLong_AsSsize_t does not. Currently the following functions fall back on __int__ where available: PyLong_AsLong PyLong_AsLongAndOverflow PyLong_AsLongLong PyLong_AsLongLongAndOverflow PyLong_AsUnsignedLongMask PyLong_AsUnsignedLongLongMask whereas the following (at least according to the docs--haven't checked the code in all cases) do not: PyLong_AsSsize_t PyLong_AsUnsignedLong PyLong_AsSize_t PyLong_AsUnsignedLongLong PyLong_AsDouble PyLong_AsVoidPtr I think this inconsistency should be fixed, unless there's some reason for it I'm not seeing. Thanks, Erik

6 17

Re: [Python-ideas] Internal function idea
by Brett Cannon 29 Dec '17

29 Dec '17

[removing Python-ideas-owner so any replies don't flood my inbox] On Sat, Dec 23, 2017, 09:23 William Rose, <william27.07.02(a)gmail.com> wrote: > I had an idea that it could be helpful to have local functions as well as > normal ones. They would be called the same way as normal ones but def would > be replaced by internal and inside they could only access variables they > have defined and inputs to them so no global variables or class variables. > I think this could be used to save people accidentally changing variables > you dont' want to change when updating your code. Let me know what you > think!

3 2

Re: [Python-ideas] Internal function idea
by Franklin? Lee 29 Dec '17

29 Dec '17

On Thu, Dec 28, 2017 at 5:21 AM, William Rose <william27.07.02(a)gmail.com> wrote: > I agree with the point that it should allow builtin but the main purpose of > it is to not allow global variables But functions are also accessed using global names. What is your answer to the potential problem of programmers being reluctant to factor out code into new functions?

2 3

Re: [Python-ideas] a set of enum.Enum values rather than the construction of bit-sets as the "norm"?
by Paddy3118 28 Dec '17

28 Dec '17

Hi Inada, can I take your point as being that execution speed is an issue? I am coming from the "Python as higher level, more programmer-centric language"direction. In the past, useful but slow things have spurred actions to speed them up.

1 0

Deprecate "slice" on built-ins, move it to "types"?
by Joao S. O. Bueno 28 Dec '17

28 Dec '17

This is probably too little to justify the compatibility breakage, but is there a motive for the "slice" type to be on built-ins ? (besides people forgot it there at PEP-3000 time?) It is normally used in super-specialized cases, mostly when one is implementing a Sequence type, and even there just for type-checking, not to create new slice objects. It seems to me it should lie on the "types" module (or some other place), rather than eat built-in namespace (which can confuse newcomers anyway). As I said, the benefits of moving it to a less prominent place may be to little, and incompatibilities would ensue since all modules using it don't expect to have to import it anyway. But maybe thsi should be a thing to keep an eye on for some future Python release? js -><-

3 2

__intancehook__ special method
by Yahya Abou 'Imran 26 Dec '17

26 Dec '17

Hello everybody! In a personnal project I feel the need (or the desire) to implement something like this: assert isinstance(1, PositiveInteger) assert not isinstance(-1, PositiveInteger) So I began looking a lot in the abc module, and I end unp using an __instancehook__ special method wich is called by __instancechek__ in the corresponding metaclass, just like the __subclasshook__ special method called by __subclasscheck__. The core idea is something like this: class MyMeta(type): def __instancecheck__(cls, instance): return cls.__instancehook__(instance) class PositiveInteger(metaclass=MyMeta): @classmethod def __instancehook__(cls, instance): return isinstance(instance, int) and instance > 0 Of course, the real implemention is more detailed... What do you think about that ?

2 2