Le 25/07/2018 à 08:49, Grégory Lielens a écrit :

BTW, I did (very quickly, so it's rough, my regexps are not really catching everything) the same or our code base:

"is None"+ "is not None": 5600 AttributeError: 160 3 args getattr: 60 hasattr: 1800

So very similar to your pattern....except for hasattr, which is much more common in my case...

(I'm not going to speak about how nice or ugly the syntax is, just about the use cases and statistics)

I think the use case here is not really the simple 'is  None' + 'is not None'.

if the case is just to replace one None value by something else, it's not really an improvement as we just save one short line, and once the new syntax is accepted and we're used to it, both solution are quite explicit with what they do, so I'd prefer the status quo over a second way of doing the same thing.

It gets interesting in json-like cases, when we traverse a deep tree in which we might encounter None at multiple levels. To me, the new functionality is better by than the status quo as it shortens the code drastically and makes it more readable (you may see the entire traversal at once).

So for the statistics, what's getting interesting is knowing when we are in that second case (but of course, it's harder to get them using simple regexes). Maybe we could find when there are more than one "is None" or "is not None" within the small block of code, and then manually check a few random dozens of those cases to see how many of them would be improved? Another thing that would be interesting in those statistics, but probably even harder to get automatically, is the proportion of cases where there is a side effect involved (so the cases when we also need a temporary variable not to have the side effect executed twice). Those cases benefit more of the new syntax than from the old one, until there's a good solution with ':=' or a lazy evaluation syntax, or some function return caching from the caller side. Also, it would be nice to know if those use cases come from specific libraries/functionalities (like json tree traversal or use of ORM) or from many different situations. In the first case, the improvement would probably belong inside the libraries themselves, or helpers could be created for this very purpose, and in the second case, if the problem is quite common, it gets interesting finding a solution inside Python itself, like what's described in this PEP.

I didn't automate those search in my codebase, I just searched for 'is None' and looked if it was complicated enough to justify a new syntax, and over 937 'is None', 43 were close to another 'is None', so I looked them up manually, and 13 could have benefited from the proposal, in the sense I described sooner, so more than 1 'is None' removed in a single line of code, and/or there was a side effect (I needed a temp variable not to have the side effect repeated). But I didn't check for side effects in the other 894 'is None', so this number should probably be a bit bigger. Side note: we're not big JSON users, and when we do use some, we catch exceptions as it's never (here) normal not have well formed json strings, so the code never continues and we never have to use default values given by the backend.