[Python-Dev] [RELEASE] Python 3.6.5rc1 is now available for testing
Announcing the immediate availability of Python 3.6.5 release candidate 1! Python 3.6.5rc1 is the first release candidate for Python 3.6.5, the next maintenance release of Python 3.6. While 3.6.5rc1 is a preview release and, thus, not intended for production environments, we encourage you to explore it and provide feedback via the Python bug tracker (https://bugs.python.org). 3.6.5 is planned for final release on 2018-03-26 with the next maintenance release expected to follow in about 3 months. You can find Python 3.6.5rc1 and more information here: https://www.python.org/downloads/release/python-365rc1/ Attention macOS users: as of 3.6.5rc1, there is a new additional installer variant for macOS 10.9+ that includes a built-in version of Tcl/Tk 8.6. This variant is expected to become the default variant in future releases. Check it out! -- Ned Deily n...@python.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] Symmetry arguments for API expansion
[Tim] >> An obvious way to extend it is for Fraction() to look for a special >> method too, say "_as_integer_ratio()". [Greg Ewing] > Why not __as_integer_ratio__? Because. at this point, that would be beating a dead horse ;-) ___ 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 wrote: An obvious way to extend it is for Fraction() to look for a special method too, say "_as_integer_ratio()". Why not __as_integer_ratio__? -- Greg ___ 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
> On Mar 13, 2018, at 12:07 PM, Guido van Rossum wrote: > > OK, please make it so. Will do. I'll create a tracker issue right away. Since this one looks easy (as many things do at first), I would like to assign it to Nofar Schnider (one of my mentees). Raymond > > On Tue, Mar 13, 2018 at 11:39 AM, Raymond Hettinger > wrote: > > > > On Mar 13, 2018, at 10:43 AM, Guido van Rossum wrote: > > > > So let's make as_integer_ratio() the standard protocol for "how to make a > > Fraction out of a number that doesn't implement numbers.Rational". We > > already have two examples of this (float and Decimal) and perhaps numpy or > > the sometimes proposed fixed-width decimal type can benefit from it too. If > > this means we should add it to int, that's fine with me. > > I would like that outcome. > > The signature x.as_integer_ratio() -> (int, int) is pleasant to work with. > The output is easy to explain, and the denominator isn't tied to powers of > two or ten. Since Python ints are exact and unbounded, there isn't worry > about range or rounding issues. > > In contrast, math.frexp(float) ->(float, int) is a bit of pain because it > still leaves you in the domain of floats rather than letting you decompose to > more more basic types. It's nice to have a way to move down the chain from > ℚ, ℝ, or ℂ to the more basic ℤ (of course, that only works because floats and > complex are implemented in a way that precludes exact irrationals). > > > Raymond > > > > > > -- > --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
OK, please make it so. On Tue, Mar 13, 2018 at 11:39 AM, Raymond Hettinger < raymond.hettin...@gmail.com> wrote: > > > > On Mar 13, 2018, at 10:43 AM, Guido van Rossum wrote: > > > > So let's make as_integer_ratio() the standard protocol for "how to make > a Fraction out of a number that doesn't implement numbers.Rational". We > already have two examples of this (float and Decimal) and perhaps numpy or > the sometimes proposed fixed-width decimal type can benefit from it too. If > this means we should add it to int, that's fine with me. > > I would like that outcome. > > The signature x.as_integer_ratio() -> (int, int) is pleasant to work > with. The output is easy to explain, and the denominator isn't tied to > powers of two or ten. Since Python ints are exact and unbounded, there > isn't worry about range or rounding issues. > > In contrast, math.frexp(float) ->(float, int) is a bit of pain because it > still leaves you in the domain of floats rather than letting you decompose > to more more basic types. It's nice to have a way to move down the chain > from ℚ, ℝ, or ℂ to the more basic ℤ (of course, that only works because > floats and complex are implemented in a way that precludes exact > irrationals). > > > Raymond > > > -- --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
> On Mar 13, 2018, at 10:43 AM, Guido van Rossum wrote: > > So let's make as_integer_ratio() the standard protocol for "how to make a > Fraction out of a number that doesn't implement numbers.Rational". We already > have two examples of this (float and Decimal) and perhaps numpy or the > sometimes proposed fixed-width decimal type can benefit from it too. If this > means we should add it to int, that's fine with me. I would like that outcome. The signature x.as_integer_ratio() -> (int, int) is pleasant to work with. The output is easy to explain, and the denominator isn't tied to powers of two or ten. Since Python ints are exact and unbounded, there isn't worry about range or rounding issues. In contrast, math.frexp(float) ->(float, int) is a bit of pain because it still leaves you in the domain of floats rather than letting you decompose to more more basic types. It's nice to have a way to move down the chain from ℚ, ℝ, or ℂ to the more basic ℤ (of course, that only works because floats and complex are implemented in a way that precludes exact irrationals). 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
[Guido] > So let's make as_integer_ratio() the standard protocol for "how to make a > Fraction out of a number that doesn't implement numbers.Rational". We > already have two examples of this (float and Decimal) and perhaps numpy or > the sometimes proposed fixed-width decimal type can benefit from it too. Yup, that works. I only would have preferred that you went back in time to add a leading underscore. > If this means we should add it to int, that's fine with me. Given that int.numerator and int.denominator already exist, there's no plausible "good reason" to refuse to return them as twople. Still, I'd wait for someone to complain ;-) ___ 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
So let's make as_integer_ratio() the standard protocol for "how to make a Fraction out of a number that doesn't implement numbers.Rational". We already have two examples of this (float and Decimal) and perhaps numpy or the sometimes proposed fixed-width decimal type can benefit from it too. If this means we should add it to int, that's fine with me. On Tue, Mar 13, 2018 at 9:37 AM, Tim Peters wrote: > [Tim] > >> 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 ;-) > > [Guido] > > Ironically, the various Fraction constructors *calls* as_integer_ratio() > for > > floats and Decimals. From which follows IMO that the float and Decimal > > classes are the right place to encapsulate the knowledge on how to do it. > > It appears that as_integer_ratio was slammed into floats and Decimals > precisely _so that_ Fraction() could call them, while Fraction has its > own self-contained knowledge of how to convert ints and Fractions and > strings and numbers.Rationals to Fraction (and the former types don't > support as_integer_ratio). > > That's fine, but my objection is subtler: the actual answer to "can > this thing be converted to an integer ratio?" is not "does it support > as_integer_ratio?", but rather "can Fraction() deal with it?" - and > there's currently no way for a new numeric type to say "and here's how > I can be converted to Fraction". > > An obvious way to extend it is for Fraction() to look for a special > method too, say "_as_integer_ratio()". The leading underscore would > reflect the truth: that this wasn't really intended to be a public > method on its own, but is an internal protocol for use by the > Fraction() constructor. > > Then it would be obvious that, e.g., it would be just plain stupid ;-) > for `int` to bother implementing _as_integer_ratio. The only real > point of the method is to play nice with the Fraction constructor. > _As is_, it's jarring that int.as_integer_ratio() doesn't exist - for > the same reason it's jarring int.hex() doesn't exist. > > If Mark or I wanted to use float._as_integer_ratio() directly too, > that's fine: we're numeric grownups and won't throw a hissy fit if > ints don't support it too ;-) > -- --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] >> 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 ;-) [Guido] > Ironically, the various Fraction constructors *calls* as_integer_ratio() for > floats and Decimals. From which follows IMO that the float and Decimal > classes are the right place to encapsulate the knowledge on how to do it. It appears that as_integer_ratio was slammed into floats and Decimals precisely _so that_ Fraction() could call them, while Fraction has its own self-contained knowledge of how to convert ints and Fractions and strings and numbers.Rationals to Fraction (and the former types don't support as_integer_ratio). That's fine, but my objection is subtler: the actual answer to "can this thing be converted to an integer ratio?" is not "does it support as_integer_ratio?", but rather "can Fraction() deal with it?" - and there's currently no way for a new numeric type to say "and here's how I can be converted to Fraction". An obvious way to extend it is for Fraction() to look for a special method too, say "_as_integer_ratio()". The leading underscore would reflect the truth: that this wasn't really intended to be a public method on its own, but is an internal protocol for use by the Fraction() constructor. Then it would be obvious that, e.g., it would be just plain stupid ;-) for `int` to bother implementing _as_integer_ratio. The only real point of the method is to play nice with the Fraction constructor. _As is_, it's jarring that int.as_integer_ratio() doesn't exist - for the same reason it's jarring int.hex() doesn't exist. If Mark or I wanted to use float._as_integer_ratio() directly too, that's fine: we're numeric grownups and won't throw a hissy fit if ints don't support it too ;-) ___ 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
On Mon, Mar 12, 2018 at 10:01 PM, Tim Peters wrote: > 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 ;-) > Ironically, the various Fraction constructors *calls* as_integer_ratio() for floats and Decimals. From which follows IMO that the float and Decimal classes are the right place to encapsulate the knowledge on how to do it. -- --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
On Mon, Mar 12, 2018 at 09:49:27AM -0700, Raymond Hettinger wrote:
> * We already have a simple, traditional, portable, and readable way to
> make the test: int(x) == x
Alas, the simple way is not always the correct way:
py> x = float('inf')
py> x == int(x)
Traceback (most recent call last):
File "", line 1, in
OverflowError: cannot convert float infinity to integer
So to be correct, you need to catch OverflowError, ValueError (in case
of NANs), and TypeError (in case of complex numbers).
Or guard against them with isinstance() and math.isfinite() tests. But
doing so has its own problems:
py> x = Decimal('snan')
py> math.isfinite(x)
Traceback (most recent call last):
File "", line 1, in
ValueError: cannot convert signaling NaN to float
> * In the context of ints, the test x.is_integer() always returns True.
> This isn't very useful.
It is if you don't know what type x is ahead of time.
if x.is_integer():
versus:
if isinstance(x, int) or isinstance(x, float) and x.is_integer()
> 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.
Could the numeric tower offer a default implementation that should work
for most numeric types? The default could possibly even be
int(self) == self
Then you only have to implement your own if you have special cases to
consider, like floats, or can optimise the test. Many numbers ought to
know if they are integer valued, without bothering to do a full
conversion to int. For example, Fractions could return
self.denominator == 1
as a cheap test for integerness.
> * 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.
This is a good point, but not an overwhelming one.
> 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.
A very nice list! Thank you for that!
But the last one is true only to a point. It is possible to be too
small. (The Python 1.5 API is *much* smaller than Python 3.6. I don't
think that it was better.) And consider that a *consistent* API is often
more important than a *minimalist* API.
--
Steve
___
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
On Mon, Mar 12, 2018 at 9: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. > Looks like it snuck into the float type as part of the fractions.Fraction work in https://bugs.python.org/issue1682 . I couldn't find much related discussion; I suspect that the move was primarily for optimization (see https://github.com/python/cpython/commit/3ea7b41b5805c60a05e697211d0bfc14a62a19fb). Decimal.as_integer_ratio was added here: https://bugs.python.org/issue25928 . I do have significant uses of `float.as_integer_ratio` in my own code, and wouldn't enjoy seeing it being deprecated/ripped out, though I guess I'd cope. Some on this thread have suggested that things like is_integer and as_integer_ratio should be math module functions. Any suggestions for how that might be made to work? Would we special-case the types we know about, and handle only those (so the math module would end up having to know about the fractions and decimal modules)? Or add a new magic method (e.g., __as_integer_ratio__) for each case we want to handle, like we do for math.__floor__, math.__trunc__ and math.__ceil__? Or use some form of single dispatch, so that custom types can register their own handlers? The majority of current math module functions simply convert their arguments to a float, so a naive implementation of math.is_integer in the same style wouldn't work: it would give incorrect results for a non-integral Decimal instance that ended up getting rounded to an integral value by the float conversion. 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
13.03.18 10:35, Larry Hastings пише: On 03/12/2018 08:41 PM, Guido van Rossum wrote: If you force me to choose between allowing hex(3.14) or 42.hex() I'll choose the latter I assume you meant (42).hex() here. If you're also interested in changing the language to permit 42.hex(), well, color me shocked :D (For those who haven't seen this before: it's a well-known gotcha. When Python's grammar sees "42.hex()", it thinks "42." is the start of a floating-point constant. But "42.hex" isn't a valid floating-point constant, so it throws a SyntaxError.) "42." is a valid floating-point constant. But a floating-point constant followed by an identifier is an invalid syntax. This is the same error as in "42. hex" and "42 hex". ___ 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
On 03/12/2018 08:41 PM, Guido van Rossum wrote: If you force me to choose between allowing hex(3.14) or 42.hex() I'll choose the latter I assume you meant (42).hex() here. If you're also interested in changing the language to permit 42.hex(), well, color me shocked :D (For those who haven't seen this before: it's a well-known gotcha. When Python's grammar sees "42.hex()", it thinks "42." is the start of a floating-point constant. But "42.hex" isn't a valid floating-point constant, so it throws a SyntaxError.) //arry/ ___ 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
