Re: [Python-ideas] Boolean ABC similar to what's provided in the 'numbers' module

[Chris Barker - NOAA Federal]

Sent from my iPhone
> A thought just occurred to me. Maybe we should just add a Boolean class to 
> numbers?

This makes lots of sense to me.

Bool is a subclass of int — might as well embrace that fact.

-CHB
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Coming up with an alternative to PEP 505's None-aware operators

[Ethan Furman]

On 02/15/2018 11:55 PM, Nick Coghlan wrote:

On 16 February 2018 at 12:19, rym...@gmail.com wrote:



I don't know...to me this looks downright ugly and an awkward special case.
It feels like it combines reading difficulty of inline assignment with the
awkwardness of a magic word and the ugliness of using ?. Basically, every
con of the other proposals combined...


Yeah, it's tricky to find a spelling that looks nice without being
readily confusable with other existing constructs (most notably
keyword arguments).

The cleanest *looking* idea I've come up with would be to allow
arbitrary embedded assignments to ordinary frame local variables using
the "(expr as name)" construct:


-1 to ?it

+1 to (name as expr)


However, while I think that looks nicer in general, we'd still have to
choose between two surprising behaviours:

* implicitly delete the statement locals after the statement where
they're set (which still overwrites any values previously bound to
those names, similar to what happens with exception clauses)


If we're overwriting locals anyway, don't delete it.  The good reason for
unsetting an exception variable doesn't apply here.


* skip deleting, which means references to subexpressions may last
longer than expected (and we'd have the problem where embedded
assignments could overwrite existing local variables)


Odds are good that we'll want/need that assignment even after the immediate
expression it's used in.  Let it stick around.

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Temporary variables in comprehensions

[Martin Teichmann]

Hi list,

> But when it comes to something like
> [f(x) + g(f(x)) for x in range(10)]
> you find you have to sacrifice some readableness if you don't want two
f(x)
> which might slow down your code.
>
> Someone may argue that one can write
> [y + g(y) for y in [f(x) for x in range(10)]]

personally I think that the biggest problem readability-wise is that "for"
is a post-fix operator, which makes generators much harder to read. It's
also very different from normal for loops, which have the "for" at the top.
IMHO generators would be much easier to read with a prefix for, as in

[for x in range(10): f(x) + g(f(x))]

also nested generators get nicer like that:

[for y in (for x in range(10): f(x)):
  y + g(y)]

one could critique here that we shouldn't use colons in expressions, but
that boat has sailed: we use them for lambdas. We do not write

 sq = x**2 lambda x

and I am not proposing that.

Also if/else could be written with colons, but I am not sure whether that's
actually nicer:

val = (if attr is None: 5 else: attr + 3)

but it certainly is in case of ifs in generators:

[for x in range(10):
 if x % 3 != 2: x]

which could be problematic to parse if you compare that to

[for x in range(10):
 if x % 3 == 2: x - 1
 else: x + 1]

one could even dig out the often-proposed always-rejected
except-in-expression:

[for x in range(10):
 try: f(x)
 except WhateverError: None]

or even a with:

[for x in file_names:
 with open(x) as f:
 f.read()]


Greetings

Martin
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Coming up with an alternative to PEP 505's None-aware operators

[Rhodri James]

On 16/02/18 02:06, Nick Coghlan wrote:

The recent thread on variable assignment in comprehensions has
prompted me to finally share
https://gist.github.com/ncoghlan/a1b0482fc1ee3c3a11fc7ae64833a315 with
a wider audience (see the comments there for some notes on iterations
I've already been through on the idea).

== The general idea ==

The general idea would be to introduce a *single* statement local
reference using a new keyword with a symbolic prefix: "?it"

[snip]

If we did pursue this, then PEPs 505, 532, and 535 would all be
withdrawn or rejected (with the direction being to use an it-reference
instead).


I don't think that follows.


== Examples ==

`None`-aware attribute access:

 value = ?it.strip()[4:].upper() if (?it=var1) is not None else None

`None`-aware subscript access:

 value = ?it[4:].upper() if (?it=var1) is not None else None

`None`-coalescense:

 value = ?it if (?it=var1) is not None else ?it if (?it=var2) is
not None else var3

`NaN`-coalescence:

 value = ?it if not math.isnan((?it=var1)) else ?it if not
math.isnan((?that=var2)) else var3

>


Conditional function call:

 value = ?it() if (?it=calculate) is not None else default



I have to say I don't find this an improvement on "value = var if var is 
not None else None" and the like.  In fact I think it's markedly harder 
to read.  It has the same repetition problem as the current situation, 
just with added glyphs.



Avoiding repeated evaluation of a comprehension filter condition:

 filtered_values = [?it for x in keys if (?it=get_value(x)) is not None]


Definite win here.  It doesn't read particularly naturally, but then 
list comprehensions don't read that naturally either.  I would still 
prefer something that read better.



Avoiding repeated evaluation for range and slice bounds:

 range((?it=calculate_start()), ?it+10)
 data[(?it=calculate_start()):?it+10]

Avoiding repeated evaluation in chained comparisons:

 value if (?it=lower_bound()) <= value < ?it+tolerance else 0

Avoiding repeated evaluation in an f-string:

 print(f"{?it=get_value()!r} is printed in pure ASCII as {?it!a}
and in Unicode as {?it}"


While these are wins, they don't read nicely at all.  I still don't see 
what's wrong with


  start = calculate_start()
  values = range(start, start+10)

which beats everything I've seen so far for clarity.


--
Rhodri James *-* Kynesim Ltd
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Coming up with an alternative to PEP 505's None-aware operators

[Nick Coghlan]

On 16 February 2018 at 18:36, Kirill Balunov  wrote:
> What about (| val = get_value(x) |) assignment expression which will be True
> if success, and None if not?
>
> So it will be value = f() if (| f = calculate |) else default…The idea is
> inspired from C’s assignment, but needs some special treatment for anything
> which is False in boolean context.

If we're going to allow arbitrary embedded assignments, then "(expr as
name)" is the most likely spelling, since:

* "as" is already a keyword
* "expr as name" is already used for name binding related purposes
(albeit not for simple assignments)
* "python as expression" and "python as keyword" are both things
search engines will accept as queries (search engines tend not to cope
very well when you try to search for punctuation characters)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Coming up with an alternative to PEP 505's None-aware operators

[Kirill Balunov]

What about (| val = get_value(x) |) assignment expression which will be True
if success, and None if not?

So it will be value = f() if (| f = calculate |) else default…The idea is
inspired from C’s assignment, but needs some special treatment for anything
which is False in boolean context.

With kind regards,

-gdg
​

2018-02-16 10:55 GMT+03:00 Nick Coghlan :

> On 16 February 2018 at 12:19, rym...@gmail.com  wrote:
> > I don't know...to me this looks downright ugly and an awkward special
> case.
> > It feels like it combines reading difficulty of inline assignment with
> the
> > awkwardness of a magic word and the ugliness of using ?. Basically, every
> > con of the other proposals combined...
>
> Yeah, it's tricky to find a spelling that looks nice without being
> readily confusable with other existing constructs (most notably
> keyword arguments).
>
> The cleanest *looking* idea I've come up with would be to allow
> arbitrary embedded assignments to ordinary frame local variables using
> the "(expr as name)" construct:
>
> value = tmp.strip()[4:].upper() if (var1 as tmp) is not None else None
>
> value = tmp[4:].upper() if (var1 as tmp) is not None else None
>
> value = tmp if (var1 as tmp) is not None else tmp if (var2 as tmp)
> is not None else var3
>
> value = tmp if not math.isnan((var1 as tmp)) else tmp if not
> math.isnan((var2 as tmp)) else var3
>
> value = f() if (calculate as f) is not None else default
>
> filtered_values = [val for x in keys if (get_value(x) as val) is not
> None]
>
> range((calculate_start() as start), start+10)
> data[(calculate_start() as start):start+10]
>
> value if (lower_bound() as min_val) <= value < min_val+tolerance else 0
>
> print(f"{(get_value() as tmp)!r} is printed in pure ASCII as
> {tmp!a} and in Unicode as {tmp}")
>
> However, while I think that looks nicer in general, we'd still have to
> choose between two surprising behaviours:
>
> * implicitly delete the statement locals after the statement where
> they're set (which still overwrites any values previously bound to
> those names, similar to what happens with exception clauses)
> * skip deleting, which means references to subexpressions may last
> longer than expected (and we'd have the problem where embedded
> assignments could overwrite existing local variables)
>
> The interaction with compound statements would also be tricky to
> figure out (especially if we went with the "delete after the
> statement" behaviour).
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/