Mailman 3 December 2017 - Python-ideas

Re: [Python-ideas] [Python-Dev] What's the status of PEP 505: None-aware operators?
by Steven D'Aprano 03 Dec '17

03 Dec '17

On Tue, Nov 28, 2017 at 12:31:06PM -0800, Raymond Hettinger wrote: > > > I also cc python-dev to see if anybody here is strongly in favor or against this inclusion. > > Put me down for a strong -1. The proposal would occasionally save a > few keystokes but comes at the expense of giving Python a more Perlish > look and a more arcane feel. I think that's an unfair characterisation of the benefits of the PEP. It's not just "a few keystrokes". Ironically, the equivalent in Perl is // which Python has used for truncating division since version 2.4 or so. So if we're in danger of looking "Perlish", that ship has sailed a long time ago. Perl is hardly the only language with null-coalescing operators -- we might better describe ?? as being familiar to C#, PHP, Swift and Dart. That's two mature, well-known languages and two up-and-coming languages. [...] > timeout ?? local_timeout ?? global_timeout As opposed to the status quo: timeout if timeout is not None else (local_timeout if local_timeout is not None else global_timeout) Or shorter, but even harder to understand: (global_timeout if local_timeout is None else local_timeout) if timeout is None else timeout I'd much prefer to teach the version with ?? -- it has a simple explanation: "the first of the three given values which isn't None". The ?? itself needs to be memorized, but that's no different from any other operator. The first time I saw ** I was perplexed and couldn't imagine what it meaned. Here ?? doesn't merely save a few keystrokes, it significantly reduces the length and complexity of the expression and entirely cuts out the duplication of names. If you can teach timeout or local_timeout or global_timeout then you ought to be able to teach ??, as it is simpler: it only compares to None, and avoids needing to explain or justify Python's truthiness model. > 'foo' in (None ?? ['foo', 'bar']) If you can understand 'foo' in (False or ['foo', 'bar']) then surely you can understand the version with ??. > requested_quantity ?? default_quantity * price Again: (default_quantity if requested_quantity is None else requested_quantity) * price I'd much prefer to read, write and teach the version with ?? over the status quo. -- Steve

11 21

How assignment should work with generators?
by Kirill Balunov 02 Dec '17

02 Dec '17

Currently during assignment, when target list is a comma-separated list of targets (*without "starred" target*) the rule is that the object (rhs) must be an iterable with the same number of items as there are targets in the target list. That is, no check is performed on the number of targets present, and if something goes wrong the ValueError is raised. To show this on simple example: >>> from itertools import count, islice >>> it = count() >>> x, y = it >>> it count(3) Here the count was advanced two times but assignment did not happen. I found that in some cases it is too much restricting that rhs must have the same number of items as targets. It is proposed that if the rhs is a generator or an iterator (better some object that yields values on demand), the assignmenet should be lazy and dependent on the number of targets. I find this feature to be very convenient for interactive use, while it remains readable, expected, and expressed in a more compact code. There are some Pros: 1. No overhead 2. Readable and not so verbose code 3. Optimized case for x,y,*z = iterator 4. Clear way to assign values partially from infinite generators. Cons: 1. A special case of how assignment works 2. As with any implicit behavior, hard-to-find bugs There several cases with "undefined" behavior: 1. Because the items are assigned, from left to right to the corresponding targets, should rhs see side effects during assignment or not? 2. Should this work only for generators or for any iterators? 3. Is it Pythonic to distinguish what is on the rhs during assignment, or it contradicts with duck typing (goose typing)? In many cases it is possible to do this right now, but in too verbose way: >>> x, y = islice(gen(), 2) But it seems for me that: >>> x, y = gen() Looks the same, easy to follow and not so verbose. Another case, which is a pitfall, but will be possible: >>> x, y = iter([0,1,2,3,4]) # Now it is Ok >>> x 1 >>> y 2 But: >>> x, y = [0,1,2,3,4] # raises ValueError Any thoughts? With kind regards, -gdg

14 61

Add a dict with the attribute access capability
by Serhiy Storchaka 01 Dec '17

01 Dec '17

In 3.7 I have removed an old-deprecated plistlib.Dict. [1] Actually it already was deprecated when the plistlib module was added to the regular stdlib in Python 2.6. This is a dict subclass which allows to access items as attributes. d = plistlib.Dict() d['a'] = 1 assert d.a == 1 d.b = 2 assert d['b'] == 2 Raymond noticed that that capability seemed nice to have. What do you think about reviving this type as general purpose type in collections or types? Perhaps it can be convenient for working with JSON, plists, configuration files, databases and in other cases that need a dict with string keys. If reintroduce it, there are open questions. 1. The name of the type. 2. The location of the type. collections or types? Or other variants? 3. How it will collaborate with OrderedDict, defaultdict, etc? 4. Should it be a dict subclass, or a mixin, or a proxy? Or add several types? [1] https://bugs.python.org/issue29196

12 12

Re: [Python-ideas] How assignment should work with generators?
by Alon Snir 01 Dec '17

01 Dec '17

On Wed, Nov 29, 2017 at 5:46 AM, Alon Snir <AlonSnir(a)hotmail.com> wrote: > I would like to mention that the issue of assignment to a target list, is also relevant to the case of elementwise assignment to a mutable sequence (e.g. lists and arrays). Here as well, the rhs of the assignment statement states the number of elements to be assigned. Consequently, the following example will get into infinite loop: > >>>> from itertools import count >>>> A = [] >>>> A[:] = count() > > Writing "A[:2] = count()" will cause the same result. > Here as well, it is currently safer to use islice if the rhs is a generator or an iterator. e.g.: > >>>> it = count() >>>> A[:] = islice(it,2) > > In my opinion, it is be better to devise a solution that could be applied in both cases. Maybe a new kind of assignment operator that will be dedicated to this kind of assignment. i.e. elementwise assignment with restriction on the number of elements to be assigned, based on the length of the lhs object (or the number of targets in the target list). > ChrisA wrote: Hmm. The trouble is that slice assignment doesn't have a fixed number of targets. If you say "x, y = spam", there's a clear indication that 'spam' needs to provide exactly two values; but "A[:] = spam" could have any number of values, and it'll expand or shrink the list accordingly. Rhodri James wrote: Flatly, no. It is better not to ask for things you don't want in the first place, in this case the infinite sequence. Still, don't let me discourage you from working on this. If you can define how such an assignment would work, or even the length of A[:] as an assignment target, I'm not going to dismiss it out of hand. My answer: The idea is to define an alternative assignment rule, that is to assign exactly as many elements as the current length of the lhs object (without expanding or shrinking it). Suppose "?=" is the operator for the alternative assignment rule; A=[None]*2; and "iterator" is any iterator (finite or infinite). In this case, the following code: >>> A ?= iterator would behave like this: >>> A[:] = islice(iterator, 2) # where 2 is the length of A And as suggested earlier for the case of assignment to a target list, the following code: >>> x, y ?= iterator would behave like this: >>> x, y = islice(iterator, 2) # where 2 is the number of targets Regarding the length issue: Is there any difficulty in finding the length of a sliced sequence? After all, the range object has a len method. Therefore, the length of A[s] (where s is a slice object) could be evaluated as follows: >>> len(range(*s.indices(len(A))))

7 10

Stub class for Generic to further improve PEP 560
by Ilya Kulakov 01 Dec '17

01 Dec '17

As explained in PEP 560, creation of Generic subclasses is much slower (~7x on my machine). My guess is that a limited number of applications actually need Generic classes at "production" runtime (i.e. when not under analysis of mypy or IDE). I propose a special class that will alias typing.Generic whenever typing.TYPE_CHECKING == True and a no-op stub otherwise. Best Regards, Ilya Kulakov

2 7