Re: [Python-Dev] PEP 572: Assignment Expressions
If you restrict the idea to 'if' and 'while', Why not render this using the existing 'as' form for binding names, already used with 'except' and 'with': while learner.get(static_hint) as points: learner.feed(f(points)) The equivalent for 'if' helps with the regex matching case: if re.match(r"...") as m: print(m.group(1)) I considered proposing these two forms in a PEP a few years ago, but never got around to it. To my eye, they fit syntactically into the language as-is, without introducing new symbols, operators or keywords, are consistent with existing usage, and address two relatively common causes of displeasing Python code. Robert ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Symmetry arguments for API expansion
In the PR I've submitted, that's essentially what I'm doing for the default Real.is_integer() implementation. The details differ slightly, in that I rely on the int() constructor to call __trunc__(), rather than introduce a new dependency on the math module. On Tue, 27 Mar 2018 at 21:29, Chris Barker <chris.bar...@noaa.gov> wrote: > I know this is all done, but for completeness’ sake: > > I just noticed math.trunc() and __trunc__(). > > So wouldn’t the “correct” way to check for an integral value be something > like: > > obj.__trunc__() == obj > > I don’t think this has any bearing on adding is_integer() methods to > numeric objects, but might if we wanted to add a generic is_integer() > function somewhere. > > In any case, I don’t recall it being mentioned in the conversation, so > thought I’d complete the record. > > -CHB > > > > > > On Wed, Mar 21, 2018 at 8:31 PM Guido van Rossum <gu...@python.org> wrote: > >> On Wed, Mar 21, 2018 at 6:48 PM, Chris Barker <chris.bar...@noaa.gov> >> wrote: >> >>> On Wed, Mar 21, 2018 at 4:12 PM, Guido van Rossum <gu...@python.org> >>> wrote: >>> >>>> Thank you! As you may or may not have noticed in a different thread, >>>> we're going through a small existential crisis regarding the usefulness of >>>> is_integer() -- Serhiy believes it is not useful (and even an attractive >>>> nuisance) and should be deprecated. OTOH the existence of >>>> dec_mpd_isinteger() seems to validate to me that it actually exposes useful >>>> functionality (and every Python feature can be abused, so that alone should >>>> not >>>> >>> ) >> > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/rob%40sixty-north.com > -- *Robert Smallshire | *Managing Director *Sixty North* | Applications | Consulting | Training r...@sixty-north.com | T +47 63 01 04 44 | M +47 924 30 350 http://sixty-north.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecating float.is_integer()
In the PR which implements is_integer() for int, the numeric tower, and Decimal I elected not to implement it for Complex or complex. This was principally because complex instances, even if they have an integral real value, are not convertible to int and it seems reasonable to me that any number for which is_integer() returns True should be convertible to int successfully, and without loss of information. >>> int(complex(2, 0)) Traceback (most recent call last): File "", line 1, in TypeError: can't convert complex to int There could be an argument that a putative complex.is_integral() should therefore return False, but I expect that would get even less support than the other suggestions in these threads. *Robert Smallshire | *Managing Director *Sixty North* | Applications | Consulting | Training r...@sixty-north.com | T +47 63 01 04 44 | M +47 924 30 350 http://sixty-north.com On 22 March 2018 at 10:51, Kirill Balunov <kirillbalu...@gmail.com> wrote: > I apologize that I get into the discussion. Obviously in some situations > it will be useful to check that a floating-point number is integral, but > from the examples given it is clear that they are very rare. Why the > variant with the inclusion of this functionality into the math module was > not considered at all. If the answer is - consistency upon the numeric > tower - will it go for complex type and what will it mean (there can be two > point of views)? > > Is this functionality so often used and practical to be a method of float, > int, ..., and not just to be an auxiliary function? > > p.s.: The same thoughts about `as_integer_ratio` discussion. > > With kind regards, > -gdg > > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > rob%40sixty-north.com > > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecating float.is_integer()
Here's an excerpted (and slightly simplified for consumption here) usage of
float.is_integer() from the top of a function which does some
convolution/filtering in a geophysics application. I've mostly seen it used
in guard clauses in this way to reject either illegal numeric arguments
directly, or particular combinations of arguments as in this case:
def filter_convolve(x, y, xf, yf, stride=1, padding=1):
x_out = (x - xf + 2*padding) / stride + 1
y_out = (y - yf + 2*padding) / stride + 1
if not (x_out.is_integer() and y_out.is_integer()):
raise ValueError("Invalid convolution filter_convolve({x},
{y}, {xf}, {yf}, {stride}, {padding})"
.format(x=x, y=y, xf=xf, yf=yf,
stride=stride, padding=padding))
x_out = int(x_out)
y_out = int(y_out)
# ...
Of course, there are other ways to do this check, but the approach here is
obvious and easy to comprehend.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Symmetry arguments for API expansion
As requested on the bug tracker, I've submitted a pull request for is_integer() support on the other numeric types. https://github.com/python/cpython/pull/6121 These are the tactics I used to implement it: - float: is_integer() already exists, so no changes - int: return True - Real: return x == int(x). Although Real doesn't explicitly support conversation to int with __int__, it does support conversion to int with __trunc__. The int constructor falls back to using __trunc__. - Rational (also inherited by Fraction): return x.denominator == 1 as Rational requires that all numbers must be represented in lowest form. - Integral: return True - Decimal: expose the existing dec_mpd_isinteger C function to Python as is_integer() ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
