Some syntactic sugar proposals

[alex23]

On Nov 15, 5:50 pm, Dmitry Groshev <lambdadmi... at gmail.com> wrote:
> On Nov 15, 10:30 am, alex23 <wuwe... at gmail.com> wrote:
> > Personally, I like keeping object attribute references separate from
> > dictionary item references.
>
> Your Python doesn't - dot notation is just a sugar for __dict__ lookup
> with default metaclass.

That's a gross oversimplification that tends towards wrong:

>>> class C(object):
...   def __init__(self):
...     self._x = None
...   @property
...   def x(self): return self._x
...   @x.setter
...   def x(self, val): self._x = val
...
>>> c = C()
>>> c.x = 1
>>> c.x
1
>>> c.__dict__['x']
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 'x'

But my concern has _nothing_ to do with the implementation detail of
how objects hold attributes, it's solely over the clarity that comes
from being able to visually tell that something is an object vs a
dictionary.

> > This seems more like a pessimisation to me: your range version
> > constructs a list just to do a single container check. That's a _lot_
> > more cumbersome than two simple comparisons chained together.
>
> By "wrong" I meant exactly this. I told about "compiler" optimisation
> of statements like this so it would not construct a list.

So you want this:

  if x in range(1,10):

...to effectively emit the same bytecode as a chained comparison while
this:

  for x in range(1,10):

...produces a list/generator?

Never going to happen. "Special cases aren't special enough to break
the rules." The standard form for chained comparisons can handle far
more complex expressions which your 'in' version could not: 0 <= min
<= max <= 100