Some syntactic sugar proposals

[alex23]

On Nov 15, 4:39 pm, Dmitry Groshev <lambdadmi... at gmail.com> wrote:
> First of all: how many times do you write something like
>     t = foo()
>     t = t if pred(t) else default_value
> ? Of course we can write it as
>     t = foo() if pred(foo()) else default_value
> but here we have 2 foo() calls instead of one. Why can't we write just
> something like this:
>     t = foo() if pred(it) else default_value
> where "it" means "foo() value"?

Could you provide an actual use case for this. This seems weird to me:
you're creating an object, testing the object, then possibly throwing
it away and using a default instead. Are you sure you can't
restructure your code as such:

   t = foo(x) if <text on x> else default

> Second, I saw a lot of questions about using dot notation for a
> "object-like" dictionaries and a lot of solutions like this:
>     class dotdict(dict):
>         def __getattr__(self, attr):
>             return self.get(attr, None)
>         __setattr__= dict.__setitem__
>         __delattr__= dict.__delitem__
> why there isn't something like this in a standart library?

Personally, I like keeping object attribute references separate from
dictionary item references. If you're someone who doesn't mind
muddying that distinction, then - as you've discovered - it's a simple
addition to your own code.

>     if x in range(a, b): #wrong!

Only in Python 3.x, it's perfectly valid in Python 2.x. To achieve the
same in Python 3.x, try:

    if x in list(range(a, b,)): # BUT SEE MY COMMENT BELOW
> it feels so natural to check it that way, but we have to write
>     if a <= x <= b
> I understand that it's not a big deal, but it would be awesome to have
> some optimisations - it's clearly possible to detect things like that
> "wrong" one and fix it in a bytecode.

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.