I was also around back then
Hong Kong Phooey is for sure testimony to that. I also watched it as a kid.
In any case, you may consider (I do) me a beginner, I have never worked professionally as a programmer.
Back in business.
Maybe you should identify some examples, from public code like the stdlib or 3rd party libraries, where this proposal would improve readability. For completeness (and contrast), you could add some examples of where using it would be a bad idea, and therefore get a feel of how often this would be a useful thing to have.
I had threading.py
open and had the __init__
method of Condition
at hand.
Original
def __init__(self, lock=None):
if lock is None:
lock = RLock()
self._lock = lock
# Export the lock's acquire() and release() methods
self.acquire = lock.acquire
self.release = lock.release
# If the lock defines _release_save() and/or _acquire_restore(),
# these override the default implementations (which just call
# release() and acquire() on the lock). Ditto for _is_owned().
if hasattr(lock, '_release_save'):
self._release_save = lock._release_save
if hasattr(lock, '_acquire_restore'):
self._acquire_restore = lock._acquire_restore
if hasattr(lock, '_is_owned'):
self._is_owned = lock._is_owned
self._waiters = _deque()
Syntax-modified
def __init__(self, lock=None):
self._lock = lock = RLock() if lock is None
# Export the lock's acquire() and release() methods
self.acquire = lock.acquire
self.release = lock.release
# If the lock defines _release_save() and/or _acquire_restore(),
# these override the default implementations (which just call
# release() and acquire() on the lock). Ditto for _is_owned().
self._release_save = lock._release_save if hasattr(lock, '_release_save')
self._acquire_restore = lock._acquire_restore if hasattr(lock, '_acquire_restore')
self._is_owned = lock._is_owned if hasattr(lock, '_is_owned')
self._waiters = _deque()
I don’t know how other readers see it, but I look at both versions and the 2nd one seems a lot cleaner and easier to understand. The number of lines is of course not relevant.
Even the assignment self._lock = lock
can now be re-written to be part of the 1st statement.
You’d also need to consider the fact that
retries -= 1 if logical_condition else 2
is currently valid syntax, and both the parser and human readers need to look ahead quite a long way to distinguish the two cases, and that often hurts readability. Particularly if logical_condition
is a complex expression (which it typically is, from my experience with Perl, as that’s when you want to push it to the end, to avoid having it “hide” the main point of the construct, which is to decrement retries
).
Considered from the very beginning of the idea. I do actually (and truly) believe that it is an extension of that syntax, which allows dropping the else 2
(in the example)
The ternary assigment without else
(call it "dernary" for marketing purposes) is what kept banging in my head whenever I felt that a return
following an if
could be read a lot more naturally by writing first the return
and then the logical condition to be evaluated, which would determine the execution of the return
.