Re: [Python-Dev] Python 2.7 -- bugfix or security before EOL?
On 11 March 2018 at 11:54, Guido van Rossum wrote: > Let's not play games with semantics. The way I see the situation for 2.7 > is that EOL is January 1st, 2020, and there will be no updates, not even > source-only security patches, after that date. Support (from the core devs, > the PSF, and python.org) stops completely on that date. If you want > support for 2.7 beyond that day you will have to pay a commercial vendor. > Of course it's open source so people are also welcome to fork it. But the > core devs have toiled long enough, and the 2020 EOL date (an extension from > the originally annouced 2015 EOL!) was announced with sufficient lead time > and fanfare that I don't feel bad about stopping to support it at all. > +1 from me, as even if commercial redistributors do decide they want to collaborate on a post-2020 Python 2.7 maintenance branch, there's no technical reason that that needs to live under the "python" GitHub organisation, and some solid logistical reasons for it to live somewhere more explicitly vendor managed. For example, a 2.7 vendor branch would need its own issue tracker that's independent of bugs.python.org, since the ability to report bugs against 2.7 will be removed from bpo (and all remaining 2.7-only bugs will be closed). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.7 -- bugfix or security before EOL?
On 2018-03-12, 13:13 GMT, Nick Coghlan wrote: > +1 from me, as even if commercial redistributors do decide > they want to collaborate on a post-2020 Python 2.7 maintenance > branch, there's no technical reason that that needs to live > under the "python" GitHub organisation, and some solid > logistical reasons for it to live somewhere more explicitly > vendor managed. It would be good to have some email list of the commercial redistributors (Linux distro maintainers + people from Anaconda etc.). Could python.org host it? Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: [email protected] GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 ..every Man has a Property in his own Person. This no Body has any Right to but himself. The Labour of his Body, and the Work of his Hands, we may say, are properly his. The great and chief end therefore, of Mens uniting into Commonwealths, and putting themselves under Government, is the Preservation of their Property. -- John Locke, "A Treatise Concerning Civil Government" ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Symmetry arguments for API expansion
There is a feature request and patch to propagate the float.is_integer() API
through rest of the numeric types ( https://bugs.python.org/issue26680 ).
While I don't think it is a good idea, the OP has been persistent and wants his
patch to go forward.
It may be worthwhile to discuss on this list to help resolve this particular
request and to address the more general, recurring design questions. Once a
feature with a marginally valid use case is added to an API, it is common for
us to get downstream requests to propagate that API to other places where it
makes less sense but does restore a sense of symmetry or consistency. In cases
where an abstract base class is involved, acceptance of the request is usually
automatic (i.e. range() and tuple() objects growing index() and count()
methods). However, when our hand hasn't been forced, there is still an
opportunity to decline. That said, proponents of symmetry requests tend to
feel strongly about it and tend to never fully accept such a request being
declined (it leaves them with a sense that Python is disordered and unbalanced).
Raymond
My thoughts on the feature request -
What is the proposal?
* Add an is_integer() method to int(), Decimal(), Fraction(), and Real().
Modify Rational() to provide a default implementation.
Starting point: Do we need this?
* We already have a simple, traditional, portable, and readable way to make the
test: int(x) == x
* In the context of ints, the test x.is_integer() always returns True. This
isn't very useful.
* Aside from the OP, this behavior has never been requested in Python's 27 year
history.
Does it cost us anything?
* Yes, adding a method to the numeric tower makes it a requirement for every
class that ever has or ever will register or inherit from the tower ABCs.
* Adding methods to a core object such as int() increases the cognitive load
for everyday users who look at dir(), call help(), or read the main docs.
* It conflicts with a design goal for the decimal module to not invent new
functionality beyond the spec unless essential for integration with the rest of
the language. The reasons included portability with other implementations and
not trying to guess what the committee would have decided in the face of tricky
questions such as whether Decimal('1.01').is_integer()
should return True when the context precision is only three decimal places
(i.e. whether context precision and rounding traps should be applied before the
test and whether context flags should change after the test).
Shouldn't everything in a concrete class also be in an ABC and all its
subclasses?
* In general, the answer is no. The ABCs are intended to span only basic
functionality. For example, GvR intentionally omitted update() from the Set()
ABC because the need was fulfilled by __ior__().
But int() already has real, imag, numerator, and denominator, why is this
different?
* Those attributes are central to the functioning of the numeric tower.
* In contrast, the is_integer() method is a peripheral and incidental concept.
What does "API Parsimony" mean?
* Avoidance of feature creep.
* Preference for only one obvious way to do things.
* Practicality (not craving things you don't really need) beats purity
(symmetry and foolish consistency).
* YAGNI suggests holding off in the absence of clear need.
* Recognition that smaller APIs are generally better for users.
Are there problems with symmetry/consistency arguments?
* The need for guard rails on an overpass doesn't imply the same need on a
underpass even though both are in the category of grade changing byways.
* "In for a penny, in for a pound" isn't a principle of good design; rather, it
is a slippery slope whereby the acceptance of a questionable feature in one
place seems to compel later decisions to propagate the feature to other places
where the cost / benefit trade-offs are less favorable.
Should float.as_integer() have ever been added in the first place?
* Likely, it should have been a math module function like isclose() and isinf()
so that it would not have been type specific.
* However, that ship has sailed; instead, the question is whether we now have
to double down and have to dispatch other ships as well.
* There is some question as to whether it is even a good idea to be testing the
results of floating point calculations for exact values. It may be useful for
testing inputs, but is likely a trap for people using it other contexts.
Have we ever had problems with just accepting requests solely based on symmetry?
* Yes. The str.startswith() and str.endswith() methods were given optional
start/end arguments to be consistent with str.index(), not because there were
known use cases where code was made better with the new feature. This ended
up conflicting with a later feature request that did have valid use cases
(supporting multiple test prefixes/suffixes). As a result, we ended-up with an
awkward and error-p
Re: [Python-Dev] Symmetry arguments for API expansion
On Mon, Mar 12, 2018 at 9:51 AM Raymond Hettinger < [email protected]> wrote: > There is a feature request and patch to propagate the float.is_integer() > API through rest of the numeric types ( https://bugs.python.org/issue26680 > ). > > While I don't think it is a good idea, the OP has been persistent and > wants his patch to go forward. > > It may be worthwhile to discuss on this list to help resolve this > particular request and to address the more general, recurring design > questions. Once a feature with a marginally valid use case is added to an > API, it is common for us to get downstream requests to propagate that API > to other places where it makes less sense but does restore a sense of > symmetry or consistency. In cases where an abstract base class is > involved, acceptance of the request is usually automatic (i.e. range() and > tuple() objects growing index() and count() methods). However, when our > hand hasn't been forced, there is still an opportunity to decline. That > said, proponents of symmetry requests tend to feel strongly about it and > tend to never fully accept such a request being declined (it leaves them > with a sense that Python is disordered and unbalanced). > > > Raymond > > > My thoughts on the feature request - > > What is the proposal? > * Add an is_integer() method to int(), Decimal(), Fraction(), and Real(). > Modify Rational() to provide a default implementation. > > Starting point: Do we need this? > * We already have a simple, traditional, portable, and readable way to > make the test: int(x) == x > Mark Dickerson left a comment on the bug pointing out that such a test is not great as it can lead to an excessive amount of computation to create the int from some numeric types such as Decimal when all that is desired is something the type itself may be able to answer without that. > * In the context of ints, the test x.is_integer() always returns True. > This isn't very useful. > * Aside from the OP, this behavior has never been requested in Python's 27 > year history. > > Does it cost us anything? > * Yes, adding a method to the numeric tower makes it a requirement for > every class that ever has or ever will register or inherit from the tower > ABCs. > * Adding methods to a core object such as int() increases the cognitive > load for everyday users who look at dir(), call help(), or read the main > docs. > * It conflicts with a design goal for the decimal module to not invent new > functionality beyond the spec unless essential for integration with the > rest of the language. The reasons included portability with other > implementations and not trying to guess what the committee would have > decided in the face of tricky questions such as whether > Decimal('1.01').is_integer() > should return True when the context precision is only three decimal places > (i.e. whether context precision and rounding traps should be applied before > the test and whether context flags should change after the test). > > Shouldn't everything in a concrete class also be in an ABC and all its > subclasses? > * In general, the answer is no. The ABCs are intended to span only basic > functionality. For example, GvR intentionally omitted update() from the > Set() ABC because the need was fulfilled by __ior__(). > > But int() already has real, imag, numerator, and denominator, why is this > different? > * Those attributes are central to the functioning of the numeric tower. > * In contrast, the is_integer() method is a peripheral and incidental > concept. > > What does "API Parsimony" mean? > * Avoidance of feature creep. > * Preference for only one obvious way to do things. > * Practicality (not craving things you don't really need) beats purity > (symmetry and foolish consistency). > * YAGNI suggests holding off in the absence of clear need. > * Recognition that smaller APIs are generally better for users. > > Are there problems with symmetry/consistency arguments? > * The need for guard rails on an overpass doesn't imply the same need on a > underpass even though both are in the category of grade changing byways. > * "In for a penny, in for a pound" isn't a principle of good design; > rather, it is a slippery slope whereby the acceptance of a questionable > feature in one place seems to compel later decisions to propagate the > feature to other places where the cost / benefit trade-offs are less > favorable. > > Should float.as_integer() have ever been added in the first place? > * Likely, it should have been a math module function like isclose() and > isinf() so that it would not have been type specific. > * However, that ship has sailed; instead, the question is whether we now > have to double down and have to dispatch other ships as well. > * There is some question as to whether it is even a good idea to be > testing the results of floating point calculations for exact values. It may > be useful for testing inputs, but is likely a trap for people using it
Re: [Python-Dev] Symmetry arguments for API expansion
12.03.18 18:49, Raymond Hettinger пише: There is a feature request and patch to propagate the float.is_integer() API through rest of the numeric types ( https://bugs.python.org/issue26680 ). While I don't think it is a good idea, the OP has been persistent and wants his patch to go forward. It may be worthwhile to discuss on this list to help resolve this particular request and to address the more general, recurring design questions. Once a feature with a marginally valid use case is added to an API, it is common for us to get downstream requests to propagate that API to other places where it makes less sense but does restore a sense of symmetry or consistency. In cases where an abstract base class is involved, acceptance of the request is usually automatic (i.e. range() and tuple() objects growing index() and count() methods). However, when our hand hasn't been forced, there is still an opportunity to decline. That said, proponents of symmetry requests tend to feel strongly about it and tend to never fully accept such a request being declined (it leaves them with a sense that Python is disordered and unbalanced). Raymond My thoughts on the feature request - I concur with Raymond at all points about this concrete feature and about the general design in general. ___ Python-Dev mailing list [email protected] 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
On 12 March 2018 at 17:59, Serhiy Storchaka wrote: > 12.03.18 18:49, Raymond Hettinger пише: >> >> There is a feature request and patch to propagate the float.is_integer() >> API through rest of the numeric types ( https://bugs.python.org/issue26680 >> ). >> >> While I don't think it is a good idea, the OP has been persistent and >> wants his patch to go forward. >> >> It may be worthwhile to discuss on this list to help resolve this >> particular request and to address the more general, recurring design >> questions. Once a feature with a marginally valid use case is added to an >> API, it is common for us to get downstream requests to propagate that API to >> other places where it makes less sense but does restore a sense of symmetry >> or consistency. In cases where an abstract base class is involved, >> acceptance of the request is usually automatic (i.e. range() and tuple() >> objects growing index() and count() methods). However, when our hand hasn't >> been forced, there is still an opportunity to decline. That said, >> proponents of symmetry requests tend to feel strongly about it and tend to >> never fully accept such a request being declined (it leaves them with a >> sense >> that Python is disordered and unbalanced). >> >> >> Raymond >> >> >> My thoughts on the feature request - > > > I concur with Raymond at all points about this concrete feature and about > the general design in general. So do I. I do think that there is an element of considered judgement in all of these types of request, and it's right that each such request be considered on its merits. But I do not think that "symmetry with other cases" is a merit in itself, it needs to be subjected to precisely the same sort of scrutiny as any other argument. In this case, Raymond's arguments seem persuasive to me (in particular, the uselessness of int.is_integer() and the complexities in deciding correct behaviour for Decimal.is_integer() in the absence of an answer in the standard). I would ask why a standalone is_integer() function, targeted at somewhere in the stdlib like the math module[1] isn't acceptable, and I'd be wanting to see use cases for the functionality - in particular use cases for a generic "can be used for an unknown type" solution, as opposed to type-specific solutions like float.is_integer or (Fraction.denominator == 1). I imagine these questions have already been thrashed out on the tracker, though. It's certainly true that people get particularly wedded to symmetry/consistency arguments. Sometimes such arguments have value (discoverability, teachability, ease of writing type-agnostic code) but we should keep that value in perspective. Paul [1] with possibly a period for development as a 3rd party library, although I can see that "being built in" may be a key benefit of a proposal like this ___ Python-Dev mailing list [email protected] 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
On Mon, 12 Mar 2018 09:49:27 -0700
Raymond Hettinger wrote:
>
> Starting point: Do we need this?
> * We already have a simple, traditional, portable, and readable way to make
> the test: int(x) == x
It doesn't look that obvious to me. As a reviewer I would request to
add a comment explaining the test.
> * Aside from the OP, this behavior has never been requested in Python's 27
> year history.
That's possible. One thing I often see is suboptimal compatibility
with third-party integer types such as Numpy ints, but that's a
slightly different request (as it usually doesn't imply accepting
Numpy floats that exactly represent integrals).
> Does it cost us anything?
> * Yes, adding a method to the numeric tower makes it a requirement for every
> class that ever has or ever will register or inherit from the tower ABCs.
Well, the big question is whether the notion of numeric tower is useful
in Python at all. If it's useful then there's a point to expand its
usability with such a feature. Personally I don't care much :-)
> As a result, we ended-up with an awkward and error-prone API that requires
> double parenthesis for the valid use case: url.endswith(('.html', '.css')).
It doesn't look that awkward to me.
Regards
Antoine.
___
Python-Dev mailing list
[email protected]
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
On Mon, Mar 12, 2018 at 4:49 PM, Raymond Hettinger < [email protected]> wrote: > What is the proposal? > * Add an is_integer() method to int(), Decimal(), Fraction(), and Real(). > Modify Rational() to provide a default implementation. > >From the issue discussion, it sounds to me as though the OP would be content with adding is_integer to int and Fraction (leaving the decimal module and the numeric tower alone). > Starting point: Do we need this? > * We already have a simple, traditional, portable, and readable way to > make the test: int(x) == x > As already pointed out in the issue discussion, this solution isn't particularly portable (it'll fail for infinities and nans), and can be horribly inefficient in the case of a Decimal input with large exponent: In [1]: import decimal In [2]: x = decimal.Decimal('1e9') In [3]: %timeit x == int(x) 1.42 s ± 6.27 ms per loop (mean ± std. dev. of 7 runs, 1 loop each) In [4]: %timeit x == x.to_integral_value() 230 ns ± 2.03 ns per loop (mean ± std. dev. of 7 runs, 100 loops each) * In the context of ints, the test x.is_integer() always returns True. > This isn't very useful. > It's useful in the context of duck typing, which I believe is a large part of the OP's point. For a value x that's known to be *either* float or int (which is not an uncommon situation), it makes x.is_integer() valid without needing to know the specific type of x. * It conflicts with a design goal for the decimal module to not invent new > functionality beyond the spec unless essential for integration with the > rest of the language. The reasons included portability with other > implementations and not trying to guess what the committee would have > decided in the face of tricky questions such as whether > Decimal('1.01').is_integer() > should return True when the context precision is only three decimal places > (i.e. whether context precision and rounding traps should be applied before > the test and whether context flags should change after the test). > I don't believe there's any ambiguity here. The correct behaviour looks clear: the context isn't used, no flags are touched, and the method returns True if and only if the value is finite and an exact integer. This is analogous to the existing is-sNaN, is-signed, is-finite, is-zero, is-infinite tests, none of which are affected by (or affect) context. -- Mark ___ Python-Dev mailing list [email protected] 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
There's a reason why adding this to int feels right to me. In mypy we treat
int as a sub*type* of float, even though technically it isn't a sub*class*.
The absence of an is_integer() method on int means that this code has a bug
that mypy doesn't catch:
def f(x: float):
if x.is_integer():
"do something"
else:
"do something else"
f(12)
This passes the type check (because 12 is considered an acceptable
substitute for float) but currently fails at runtime (because x is an int
and does not have that method).
You may think that mypy is obviously wrong here, but in fact we (the Python
community) have gone through considerable hoops to make other cases like
this work at runtime (e.g. adding .imag and .real to int), and disallowing
ints where a float is expected in mypy would cause unacceptable noise about
many valid programs (the difference in runtime behavior between int and
float was much more pronounced in Python 2, where integer division
truncated, and we intentionally changed that for the same reason).
So I think the OP of the bug has a valid point, 27 years without this
feature notwithstanding.
And while mypy does not endorse or use the numeric tower, given the strong
argument for adding the method to int, it makes sense to add it to all
types in the numeric tower as well. I have no strong opinion about what to
do for Decimal, which in general doesn't like to play nice with other ABCs
(in general I think Decimal is doing itself a disfavor by favoring the
language-independent Decimal standard over Python conventions, but that's a
discussion for another time).
On Mon, Mar 12, 2018 at 11:10 AM, Antoine Pitrou
wrote:
> On Mon, 12 Mar 2018 09:49:27 -0700
> Raymond Hettinger wrote:
> >
> > Starting point: Do we need this?
> > * We already have a simple, traditional, portable, and readable way to
> make the test: int(x) == x
>
> It doesn't look that obvious to me. As a reviewer I would request to
> add a comment explaining the test.
>
> > * Aside from the OP, this behavior has never been requested in Python's
> 27 year history.
>
> That's possible. One thing I often see is suboptimal compatibility
> with third-party integer types such as Numpy ints, but that's a
> slightly different request (as it usually doesn't imply accepting
> Numpy floats that exactly represent integrals).
>
> > Does it cost us anything?
> > * Yes, adding a method to the numeric tower makes it a requirement for
> every class that ever has or ever will register or inherit from the tower
> ABCs.
>
> Well, the big question is whether the notion of numeric tower is useful
> in Python at all. If it's useful then there's a point to expand its
> usability with such a feature. Personally I don't care much :-)
>
> > As a result, we ended-up with an awkward and error-prone API that
> requires double parenthesis for the valid use case: url.endswith(('.html',
> '.css')).
>
> It doesn't look that awkward to me.
>
> Regards
>
> Antoine.
>
>
>
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
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
12.03.18 21:15, Guido van Rossum пише: There's a reason why adding this to int feels right to me. In mypy we treat int as a sub*type* of float, even though technically it isn't a sub*class*.. The absence of an is_integer() method on int means that this code has a bug that mypy doesn't catch: def f(x: float): if x.is_integer(): "do something" else: "do something else" What is the real use case of float.is_integer()? I searched on GitHub and found only misuses of it like (x/5).is_integer() (x % 5 == 0 would be more correct and clear) or (x**0.5).is_integer() (returns wrong result for large ints and some floats) in short examples. Some of these snippets look like book examples, and they propagate bad practices (like "if a.is_integer() == True:"). ___ Python-Dev mailing list [email protected] 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
> On Mar 12, 2018, at 12:15 PM, Guido van Rossum wrote:
>
> There's a reason why adding this to int feels right to me. In mypy we treat
> int as a sub*type* of float, even though technically it isn't a sub*class*.
> The absence of an is_integer() method on int means that this code has a bug
> that mypy doesn't catch:
>
> def f(x: float):
> if x.is_integer():
> "do something"
> else:
> "do something else"
>
> f(12)
Do you have any thoughts about the other non-corresponding float methods?
>>> set(dir(float)) - set(dir(int))
{'as_integer_ratio', 'hex', '__getformat__', 'is_integer', '__setformat__',
'fromhex'}
In general, would you prefer that functionality like is_integer() be a math
module function or that is should be a method on all numeric types except
Complex? I expect questions like this to recur over time.
Also, do you have any thoughts on the feature itself? Serhiy ran a Github
search and found that it was baiting people into worrisome code like:
(x/5).is_integer() or (x**0.5).is_integer()
> So I think the OP of the bug has a valid point, 27 years without this feature
> notwithstanding.
Okay, I'll ask the OP to update his patch :-)
Raymond
___
Python-Dev mailing list
[email protected]
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
On Mon, Mar 12, 2018 at 1:03 PM, Raymond Hettinger < [email protected]> wrote: > > > On Mar 12, 2018, at 12:15 PM, Guido van Rossum wrote: > > > > There's a reason why adding this to int feels right to me. In mypy we > treat int as a sub*type* of float, even though technically it isn't a > sub*class*. The absence of an is_integer() method on int means that this > code has a bug that mypy doesn't catch: > > > > def f(x: float): > > if x.is_integer(): > > "do something" > > else: > > "do something else" > > > > f(12) > > Do you have any thoughts about the other non-corresponding float methods? > Not really, but I'll try below. > >>> set(dir(float)) - set(dir(int)) >{'as_integer_ratio', 'hex', '__getformat__', 'is_integer', > '__setformat__', 'fromhex'} > IIUC fromhex is a class method so the story isn't the same there -- typical use is float.fromhex(). as_integer_ratio() seems mostly cute (it has Tim Peters all over it), OTOH it looks like Decimal has it, so I think this ship has sailed too and maybe it's best to add it to the numeric tower just to be done with it. I found a comment for __getformat__ saying "You probably don't want to use this function. It exists mainly to be used in Python's test suite" so let's skip that. So that leaves hex(). There I think it's preposterous that for ints you have to write hex(i) but for floats you must write x.hex(). The idea that the user always knows whether they have an int or a float is outdated (it stems back to the very early Python days when 3.14 + 42 was a type error -- Tim talked me out of that in '91 or '92). If you force me to choose between allowing hex(3.14) or 42.hex() I'll choose the latter -- we also have bytes.hex() and it's an easier change to add a hex() method to int than to extend the hex() function -- we'd have to add a __hex__ protocol first. > In general, would you prefer that functionality like is_integer() be a > math module function or that is should be a method on all numeric types > except Complex? I expect questions like this to recur over time. > That feels like a loaded question -- we have a math module because C has one and back in 1990 I didn't want to spend time thinking about such design issues. > Also, do you have any thoughts on the feature itself? Serhiy ran a Github > search and found that it was baiting people into worrisome code like: > (x/5).is_integer() or (x**0.5).is_integer() > Finding bad example of floating point use is like stealing candy from babies. The feature seems venerable so I think there would have to be a very high bar to deprecate it -- I don't think you want to go there. > > So I think the OP of the bug has a valid point, 27 years without this > feature notwithstanding. > > Okay, I'll ask the OP to update his patch :-) > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] 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
[Guido] > as_integer_ratio() seems mostly cute (it has Tim Peters all > over it), Nope! I had nothing to do with it. I would have been -0.5 on adding it had I been aware at the time. - I expect the audience is tiny. - While, ya, _I_ have uses for it, I had a utility function for it approximately forever (it's easily built on top of math.frexp()). - Especially now, fractions.Fraction(some_float) is the same thing except for return type. > OTOH it looks like Decimal has it, Looks like ints got it first, and then spread to Decimal because "why not?" ;-) The first attempt to spread it to Decimal I found was rejected (which would have been my vote too): https://bugs.python.org/issue8947 > so I think this ship has sailed too and maybe it's best to add it to the > numeric tower just to be done with it. Or rip it out of everything. Either way works for me ;-) ___ Python-Dev mailing list [email protected] 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
If anyone cares, my vote is to rip out both .as_integer_ratio() and .is_integer() from Python. I've never used either and wouldn't want to. Both seem like perfectly good functions for the `math` module, albeit the former is simply the Fraction() constructor. I can see no sane reason why anyone would ever call float.is_integer() actually. That should always be spelled math.isclose(x, int(x)) because IEEE-754. Attractive nuisance is probably too generous, I'd simply call the method a bug. On Mon, Mar 12, 2018, 2:21 PM Tim Peters wrote: > [Guido] > > as_integer_ratio() seems mostly cute (it has Tim Peters all > > over it), > > Nope! I had nothing to do with it. I would have been -0.5 on adding > it had I been aware at the time. > > - I expect the audience is tiny. > > - While, ya, _I_ have uses for it, I had a utility function for it > approximately forever (it's easily built on top of math.frexp()). > > - Especially now, fractions.Fraction(some_float) is the same thing > except for return type. > > > > OTOH it looks like Decimal has it, > > Looks like ints got it first, and then spread to Decimal because "why > not?" ;-) The first attempt to spread it to Decimal I found was > rejected (which would have been my vote too): > > https://bugs.python.org/issue8947 > > > > so I think this ship has sailed too and maybe it's best to add it to the > > numeric tower just to be done with it. > > Or rip it out of everything. Either way works for me ;-) > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx > ___ Python-Dev mailing list [email protected] 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
On Mon, Mar 12, 2018 at 5:18 PM, Tim Peters wrote:
> [Guido]
>> as_integer_ratio() seems mostly cute (it has Tim Peters all
>> over it),
>
> Nope! I had nothing to do with it. I would have been -0.5 on adding
> it had I been aware at the time.
>
> - I expect the audience is tiny.
The datetime module would benefit from having as_integer_ratio()
supported by more types. It's been hard to resist requests to allow
Decimal in timedelta constructors and/or arithmetics
>>> timedelta(Decimal('1.5'))
Traceback (most recent call last):
File "", line 1, in
TypeError: unsupported type for timedelta days component: decimal.Decimal
but
>>> timedelta(1.5)
datetime.timedelta(days=1, seconds=43200)
I don't recall why we decided not to accept anything with an
.as_integer_ratio() method.
See for additional discussion.
___
Python-Dev mailing list
[email protected]
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
[David Mertz ] > ... > I can see no sane reason why anyone would ever call float.is_integer() > actually. That should always be spelled math.isclose(x, int(x)) because > IEEE-754. Attractive nuisance is probably too generous, I'd simply call the > method a bug. Sometimes it's necessary to know, and especially when _implementing_ 754-conforming functions. For example, what negative infinity raised to a power needs to return depends on whether the power is an integer (specifically on whether it's an odd integer): >>> (-math.inf) ** random.random() inf >>> (-math.inf) ** random.random() inf >>> (-math.inf) ** random.random() inf >>> (-math.inf) ** 3.1 inf >>> (-math.inf) ** 3.0 # NOTE THIS ONE -inf >>> (-math.inf) ** 2.9 inf But, ya, for most people most of the time I agree is_integer() is an attractive nuisance. People implementing math functions are famous for cheerfully enduring any amount of pain needed to get the job done ;-) ___ Python-Dev mailing list [email protected] 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
On Mon, Mar 12, 2018, 3:25 PM Tim Peters wrote: > [David Mertz ] > > ... > > I can see no sane reason why anyone would ever call float.is_integer() > > actually. That should always be spelled math.isclose(x, int(x)) because > > IEEE-754. Attractive nuisance is probably too generous, I'd simply call > the > > method a bug. > > Sometimes it's necessary to know, and especially when _implementing_ > 754-conforming functions. For example, what negative infinity raised > to a power needs to return depends on whether the power is an integer > (specifically on whether it's an odd integer): > > >>> (-math.inf) ** 3.1 > inf > Weird. I take it that's what IEEE-754 says. NaN would sure be more intuitive here since inf+inf-j is not in the domain of Reals. Well, technically neither is inf, but at least it's the limit of the domain. :-). >>> (-math.inf) ** 3.0 # NOTE THIS ONE > -inf > >>> (-math.inf) ** 2.9 > inf > > But, ya, for most people most of the time I agree is_integer() is an > attractive nuisance. People implementing math functions are famous > for cheerfully enduring any amount of pain needed to get the job done > ;-) > ___ Python-Dev mailing list [email protected] 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
[Tim Peters] >> ... >> >>> (-math.inf) ** 3.1 >> inf [David Mertz] > Weird. I take it that's what IEEE-754 says. NaN would sure be more intuitive > here since inf+inf-j is not in the domain of Reals. Well, technically > neither is inf, but at least it's the limit of the domain. :-). Mathematical reals have all sorts of properties floats fail to capture, while mathematical reals don't distinguish between -0 and +0 at all. "Practical' symmetry arguments often underlie what float standards require. At heart , the rules for infinite arguments are often _consequences_ of "more obvious" rules for signed zero arguments, following from replacing +-inf with 1/+-0 in the latter. More explanation here: https://stackoverflow.com/questions/10367011/why-is-pow-infinity-positive-non-integer-infinity But we're not required to _like_ it; we just have to implement it ;-) >> >>> (-math.inf) ** 3.0 # NOTE THIS ONE >> -inf >> >>> (-math.inf) ** 2.9 >> inf ___ Python-Dev mailing list [email protected] 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
[Tim. on as_integer_ratio()]
>> - I expect the audience is tiny.
[Alexander Belopolsky]
> The datetime module would benefit from having as_integer_ratio()
> supported by more types. It's been hard to resist requests to allow
> Decimal in timedelta constructors and/or arithmetics
I don't see the connection. That timedelta construction may use
as_integer_ratio() today doesn't mean it _has_ to use
as_integer_ratio() forever, and is no reason (to my mind) to add
as_integer_ratio all over the place.
Why not drop that, and in oddball cases see whether
fractions.Fraction() can handle the input?
>>> fractions.Fraction(decimal.Decimal("1.76"))
Fraction(44, 25)
Probably less efficient, but I don't care ;-) And then, e.g.,
timedelta would also automagically allow Fraction arguments (which,
BTW, don't support as_integer_ratio() either). Bonus: if datetime is
bothering with hand-coding rational arithmetic now out of concern to
get every bit right, Fraction could handle that too by itself.
At heart, the Fraction() constructor is _all about_ creating integer
ratios, so is the most natural place to put knowledge of how to do so.
A protocol for allowing new numeric types to get converted to Fraction
would be more generally useful than just a weird method only datetime
uses ;-)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
