Re: [Python-Dev] Python 2.7 -- bugfix or security before EOL?

[Benjamin Peterson]

Sounds good to me. I've updated the PEP to say 2.7 is completely dead on Jan 1 
2020. The final release may not literally be on January 1st, but we certainly 
don't want to support 2.7 through all of 2020.

On Sat, Mar 10, 2018, at 18: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.
> 
> On Sat, Mar 10, 2018 at 5:36 PM, Terry Reedy  wrote:
> 
> > On 3/10/2018 4:59 PM, Michael Scott Cuthbert wrote:
> >
> >> I notice on https://devguide.python.org that Python 3.5 is in “security”
> >> status with an EOL of 2020-09-13 but Python 2.7 is in “bugfix” and has a
> >> likely earlier EOL.
> >>
> >
> > There is no relation between the two, or between 2.7 and any other
> > version.  2.7 is a completely special case.
> >
> >  Will there be a period where Py2.7 is in security-only status before
> >> hitting EOL?
> >>
> >
> > https://www.python.org/dev/peps/pep-0373 gives the public status.  When
> > Benjamin Peterson want to add something, he will.
> >
> > Already, the main emphasis is on security, build, and test infrastructure
> > fixes.  Backporting bug and doc fixes is at developer discretion.
> >
> >  Even if the EOL is set at the last possible date of 2020-12-31,
> >>
> >
> > Benjamin Peterson will decide when he decides.  He has not yet announced a
> > date for a 2018 release.
> >
> > People have mostly proposed either Jan 1 or sometime late spring related
> > to PyCon.  If you want something definite for your own planning, I
> > recommend that you assume Jan 1.
> >
> > it still is in the time period before EOL that other recent versions have
> >> gone to security only.
> >>
> >
> > Again, not relevant.
> >
> > You might want to read http://python3statement.org/.
> >
> > Some major projects (like Django, I believe) have already put their last
> > 2.x compatible version into bug-fix only mode and expect to stop patching
> > it before 2020.
> >
> > --
> > Terry Jan Reedy
> >
> >
> > ___
> > 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/guido%
> > 40python.org
> >
> 
> 
> 
> -- 
> --Guido van Rossum (python.org/~guido)
> ___
> 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/benjamin%40python.org
___
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] Python 2.7 -- bugfix or security before EOL?

[Nick Coghlan]

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   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

[Serhiy Storchaka]

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
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] Python 2.7 -- bugfix or security before EOL?

[Matěj Cepl]

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: mc...@ceplovi.cz
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
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

[Paul Moore]

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
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

[Antoine Pitrou]

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
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

[Mark Dickinson]

On Mon, Mar 12, 2018 at 4:49 PM, Raymond Hettinger <
raymond.hettin...@gmail.com> 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
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

[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"

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
> Python-Dev@python.org
> 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
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

[Gregory P. Smith]

On Mon, Mar 12, 2018 at 9:51 AM Raymond Hettinger <
raymond.hettin...@gmail.com> 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 

Re: [Python-Dev] Symmetry arguments for API expansion

[Raymond Hettinger]

> 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
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

[Serhiy Storchaka]

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
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

[Python-Dev] Symmetry arguments for API expansion

[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 -

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 

Re: [Python-Dev] Symmetry arguments for API expansion

[Tim Peters]

[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
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

[Tim Peters]

[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
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

[Tim Peters]

[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
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

[Alexander Belopolsky]

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
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

[David Mertz]

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
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx
>
___
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

[David Mertz]

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
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

[Guido van Rossum]

On Mon, Mar 12, 2018 at 1:03 PM, Raymond Hettinger <
raymond.hettin...@gmail.com> 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
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

[Tim Peters]

[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
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