classification
Title: Type: Add math.tau enhancement commit review Python 3.6
process
Status: Resolution: closed fixed gvanrossum Aaron.Meurer, Decorater, Nofar Schnider, belopolsky, benjamin.peterson, eric.araujo, georg.brandl, lisroach, mark.dickinson, ncoghlan, pfalcon, python-dev, rhettinger, serhiy.storchaka, stutzbach, tim.peters, veky, vstinner, waldir, xcombelle normal easy, patch

Created on 2011-06-16 03:10 by ncoghlan, last changed 2018-04-10 06:16 by sbaird. This issue is now closed.

Files
tau.diff gvanrossum, 2016-08-10 01:45 review
tau2.diff gvanrossum, 2016-08-10 04:26 review
tau3.diff lisroach, 2016-08-12 03:39
tau4.diff lisroach, 2016-08-15 04:27 review
Messages (63)
msg138412 - (view) Author: Nick Coghlan (ncoghlan) * Date: 2011-06-16 03:10
I'd like to add a new constant to the math module:

tau = 2*math.pi

Rather than repeating all the reasons for why tau makes more sense than pi as the fundamental circle constant, I'll just refer interested readers to http://tauday.com/
msg138414 - (view) Author: Benjamin Peterson (benjamin.peterson) * Date: 2011-06-16 03:50
Perhaps we should wait until \tau gains popularity larger than some impassioned physicist. \tau has been used to represent the golden ratio longer.
msg138416 - (view) Author: Raymond Hettinger (rhettinger) * Date: 2011-06-16 06:12
-1
msg138419 - (view) Author: Nick Coghlan (ncoghlan) * Date: 2011-06-16 10:32
The golden ratio is more commonly denoted with phi (although tau does get used sometimes).

Popularity isn't the point though, it's the fact that tau *makes geometric sense* in ways that 2*pi doesn't.
msg138421 - (view) Author: STINNER Victor (vstinner) * Date: 2011-06-16 10:43
I like this issue number, but I don't think that Python needs this new constant: it's trivial to add it to your own project. We have pi and e, it's enough. If we begin to add a new constant, others will ask to add much more constants, and there are million of other constants (useful or not). You may want to create a library of some other common constants. You can use float.fromhex() to have a good accuracy.
msg138422 - (view) Author: Antoine Pitrou (pitrou) * Date: 2011-06-16 11:16
Nick, you just have to write: tau = 2 * math.pi
and you're done.

> there are million of other constants

Actually, I've heard there are an infinity of them.
msg138423 - (view) Author: STINNER Victor (vstinner) * Date: 2011-06-16 11:31
> Actually, I've heard there are an infinity of them.

Can you prove that?
msg138431 - (view) Author: Benjamin Peterson (benjamin.peterson) * Date: 2011-06-16 13:20
2011/6/16 STINNER Victor <report@bugs.python.org>:
>
> STINNER Victor <victor.stinner@haypocalc.com> added the comment:
>
>> Actually, I've heard there are an infinity of them.
>
> Can you prove that?

Don't have to. Axiom of infinity. :)
msg138548 - (view) Author: Daniel Stutzbach (stutzbach) Date: 2011-06-17 20:33
On Wed, Jun 15, 2011 at 8:10 PM, Nick Coghlan <report@bugs.python.org>wrote:

> I'd like to add a new constant to the math module:
>
>  tau = 2*math.pi
>
> Rather than repeating all the reasons for why tau makes more sense than pi
> as the fundamental circle constant, I'll just refer interested readers to
> http://tauday.com/

(The following is best if read aloud using your best pirate impression)

I'd rather name the new constant "matey".  Then we have:

The circumference of a circle is: r matey
The area of a circle is: one-quarter r r matey
etc.
msg138551 - (view) Author: Mark Dickinson (mark.dickinson) * Date: 2011-06-17 21:04
Not to mention d(area of circle of radius r) = r dr matey.
msg138553 - (view) Author: Georg Brandl (georg.brandl) * Date: 2011-06-17 21:14
> http://tauday.com/

And I thought putting "dx" directly next to the integral sign was audacious...
msg139338 - (view) Author: Guido van Rossum (gvanrossum) * Date: 2011-06-27 23:37
Uh, not until I've seen a lot more evidence that people are habitually writing "TAU = 2 * math.pi" in their programs...
msg183004 - (view) Author: Simon Baird (sbaird) Date: 2013-02-26 00:17
https://github.com/search?q=%22TAU+%3D+2+%2A+Math.PI%22&type=Code
https://github.com/search?q=%22TAU+%3D+PI+*+2%22&type=Code
msg183198 - (view) Author: Waldir Pimenta (waldir) Date: 2013-02-28 03:13
Following-up sbaird's comment, I must point out that those aren't Python-specific results. Filtering them by appending &l=python to the urls yields:
- "TAU = 2 * Math.PI": 6
- "TAU = 2*Math.PI": 2
- "TAU=2*Math.PI": 0
- "TAU = Math.PI * 2": 0
- "TAU = Math.PI*2": 2
- "TAU=Math.PI*2": 1
(total: 11)

- "TAU = 2 * PI": 9
- "TAU = 2*PI": 12
- "TAU=2*PI": 0
- "TAU = PI * 2": 2
- "TAU = PI*2": 0
- "TAU=PI*2": 0
(total: 23)

Then again, the results for all languages are still helpful to estimate the overall adoption of the notation in code, and indeed the global usage of these patterns (in github only) is in the hundreds.

Also, it's worth taking a look at the usage of the twopi constant, which is already defined in several languages (http://en.wikipedia.org/w/index.php?oldid=509096802#Support_in_programming_languages), and has been manually defined in python quite often, proving its usefulness:

- https://github.com/search?l=python&q=twopi&type=Code (~2k results in python, and ~58k overall)
- https://github.com/search?l=python&q=two_pi&type=Code (~200 results in python, ~23k overall)
msg272287 - (view) Author: Guido van Rossum (gvanrossum) * Date: 2016-08-10 01:41
I'm just going to do this.
msg272299 - (view) Author: Zachary Ware (zach.ware) * Date: 2016-08-10 04:21
Builds fine on Windows.  Happily, math.tau == 2*math.pi is True.
msg272301 - (view) Author: Guido van Rossum (gvanrossum) * Date: 2016-08-10 04:26
OK, here's a diff with a test that math.tau ~~ 2*math.pi.
msg272304 - (view) Author: Tim Peters (tim.peters) * Date: 2016-08-10 04:56
Hmm.  I'd test that tau is exactly equal to 2*pi.  All Python platforms  (past, present, and plausible future ones) have binary C doubles, so the only difference between pi and 2*pi _should_ be in the exponent (multiplication by 2 is exact).  Else we screwed up one or both mantissas (typed the constant wrong, and/or the C compiler is rounding incorrectly) - which would be bad.
msg272319 - (view) Author: Mark Dickinson (mark.dickinson) * Date: 2016-08-10 07:14
> I'd test that tau is exactly equal to 2*pi.

+1
msg272325 - (view) Author: Mark Dickinson (mark.dickinson) * Date: 2016-08-10 10:25
At some point before 3.6, the docs should get updated, and cmath should get the tau constant too.
msg272373 - (view) Author: Raymond Hettinger (rhettinger) * Date: 2016-08-10 20:31
Perhaps minds are already made up, but this may be the last chance to say that I think that this shouldn't go forward.

* The push to use of "tau" has the flavor a political fad or wishful thinking that may or may not succeed.  The math module should only implement established practice.

* Since not everyone knows or uses tau, its use would tend to make code less clear. As a reviewer, I would ask that code like "from math import tau" to be changed to "from math import tau as twopi".  The latter is more clear to most users (how many people would recognize "tau * r" when it occurs in the middle of a larger expression?).

* I've surveyed engineers in my recent Python courses (often with Physics, EE, MaterialScience, DSP, or CompSci backgrounds and not a single one of them had heard of this constant).

* If people really wanted this, we would be seeing more cases of "tau = 2.0 * math.pi" in code.  Google searches and Github code search shows that this is very rare.

* It is already trivial to write "tau=2.0*pi" so why bother?

* Adding mysteriously named constants degrades the usability of the math module where many of the tools are currently self-evident but not all (
tau is a number, gamma is a function, and what the heck is a frexp?).

* Also, the name "tau" is already used for other purposes in various contexts (shear stress, proper time in relativity, torque, tau lepton, optical depth in astronomy, time contacts in RC circuits, etc).

If needed, I can survey the audiences at the upcoming SF PyData conference and the SF PyBay conference to see if any of the participants have any clue what this is about and whether they would support the addition.
msg272374 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * Date: 2016-08-10 20:36
+1 to Raymond.
msg272375 - (view) Author: Guido van Rossum (gvanrossum) * Date: 2016-08-10 20:39
Noted, but it doesn't change my decision. Obscure fact: did you know there
are also branches of mathematics and engineering that define pi to for
something else?
msg272376 - (view) Author: Antoine Pitrou (pitrou) * Date: 2016-08-10 20:39
Agreed with Raymond's arguments.
msg272377 - (view) Author: Evelyn Mitchell (Evelyn Mitchell) * Date: 2016-08-10 20:41
I also agree with Raymond's arguments. Adding tau doesn't add clarity to the math module, it just adds complexity.
msg272422 - (view) Author: Nofar Schnider (Nofar Schnider) * Date: 2016-08-11 08:40
I agree with Raymond.
In my opinion, it doesn't seem like there is a need to add such a constant.
I know many of my previous and current colleagues would not use it (why should them if they can just write "2 * math.pi" ?)
It seems that the efforts to spread the word that Pi is wrong and Tau is right haven't "bear fruits". For now I don't think we should make such a strong stand in adding it.
If we do add new constants they should be of calculations that are harder and might ruin the code's visibility.

https://www.explainxkcd.com/wiki/images/0/08/pi_vs_tau.png
msg272457 - (view) Author: Guido van Rossum (gvanrossum) * Date: 2016-08-11 15:34
It's okay if Python occasionally shows its lighter side in unexpected places. Think of the delight of future (junior) high schoolers who discover that Python participates in the tau debate. :-)

Also, I think this video by Vi Hart should be linked to from the docs for this constant: https://www.youtube.com/watch?v=jG7vhMMXagQ
msg272465 - (view) Author: Vedran Čačić (veky) * Date: 2016-08-11 17:49
Guido once again shows he is not a mathematicians (honestly, most of the "arguments" for tau are plain nonsense), but he is a fantastic popularizer. I (and most of the other professional mathematicians) will love Python a tiny bit less, but a horde of people will love it more, and it's a fine tradeoff. :-)
msg272467 - (view) Author: Tim Peters (tim.peters) * Date: 2016-08-11 18:07
For those insisting that tau is somehow unnatural, just consider that the volume of a sphere with radius r is 2*tau/3*r**3 - the formula using pi instead is just plain impossible to remember ;-)
msg272469 - (view) Author: Antoine Pitrou (pitrou) * Date: 2016-08-11 18:15
Le 11/08/2016 20:07, Tim Peters a écrit :
>
> For those insisting that tau is somehow unnatural, just consider
> that the volume of a sphere with radius r is 2*tau/3*r**3 - the formula using
> pi instead is just plain impossible to remember ;-)

Thank you, I'm totally convinced now :-)
msg272470 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * Date: 2016-08-11 18:22
In general, the volume, in n-dimensional Euclidean space, of the unit n-ball, is given by

V_n = pi**(n/2) / gamma(n/2+1)

or

V_n = (tau/2)**(n/2) / gamma(n/2+1)
msg272472 - (view) Author: Antoine Pitrou (pitrou) * Date: 2016-08-11 18:44
The patch needs a documentation update, by the way.
msg272473 - (view) Author: Aaron Meurer (Aaron.Meurer) Date: 2016-08-11 18:45
If this is implemented, it would be (as far as I can tell) the only thing in the math module that isn't also implemented in any of the standard external math libraries. None of numpy, scipy, sympy, or mpmath implement tau (if I'm missing one that others think is equally important to the ecosystem, let me know).
msg272476 - (view) Author: Aaron Meurer (Aaron.Meurer) Date: 2016-08-11 19:52
I also wonder, if math will be gaining constants that no one uses like tau, if it will also gain constants that people actually do use (currently math just has pi, e, inf, and nan). [i for i in dir(numpy) if isinstance(getattr(numpy, i), float)] reveals euler_gamma as one example. https://docs.scipy.org/doc/scipy/reference/constants.html lists a bunch more.

And if we're adding derived constants, why not loge2, another derived constants, used way more often than tau?

In case you can't tell, I'm opposed to adding tau, although fwiw I do think it would be nice to add some of the other constants I mentioned above like euler_gamma to math, and in general, I support adding more stuff to math (but only generally useful stuff, obviously; there's no need to port all of scipy.special, for instance).

As an aside, a technical note on the patch: for consistency, it should also be added to the cmath library (pardon me if I misread the patch and that's already happening).
msg272478 - (view) Author: Stefan Krah (skrah) * Date: 2016-08-11 20:04
Aaron, I may be wrong, but I understood this to be something like:

>>> from __future__ import barry_as_FLUFL
>>> 3 <> 10
True

I *do* hope sympy supports that! :-)
msg272483 - (view) Author: Emanuel Barry (ebarry) * Date: 2016-08-11 20:55
I think that whether or not something is trivial doesn't really correlate to whether or not it has its place in the language. After all, math.pi is 3.1416, and most people using pi will not worry about more than 4 decimal digits. Those who do are presumably using something better than floating-point arithmetic to begin with ;)

For yet another colour to paint this tiny bikeshed, maybe we could put new constants in something like math.constants, with aliases to existing ones. Of course, I don't mean to point out how ridiculously disproportioned this discussion is, but...
msg272484 - (view) Author: Guido van Rossum (gvanrossum) * Date: 2016-08-11 21:28
Let those other libraries follow.
msg272485 - (view) Author: Aaron Meurer (Aaron.Meurer) Date: 2016-08-11 21:49
Emanuel Barry, that is both untrue and irrelevant (sorry to be blunt, but that's a total straw man on my and I believe other's argument). The fact that the only mathematical constants in math are pi and e (nan and inf aren't really "mathematical" constants) *does* indicate to me that only the really important ones are included.

GvR, are you also in favor of adding more math constants/functions to the math module? I do see the value of Easter eggs in the language, but two real constants and one Easter egg constant seems weirder than ten real constants and one Easter egg constant. I'm +1/(2*pi) (because I still think tau in general is stupid) to add it if it also means the math module can be expanded. And before you ask, yes, I'll be happy to contribute once things move to GitHub.
msg272487 - (view) Author: Guido van Rossum (gvanrossum) * Date: 2016-08-12 00:13
FWIW I don't plan to have more constants there, at the current rate we'll
be fine for centuries. :-)

What worries me more is proposals to add Python functions to math...

--Guido (mobile)
msg272493 - (view) Author: Lisa Roach (lisroach) * Date: 2016-08-12 03:39
I've updated the test to assert tau is equal to 2*math.pi, as well as updated the docs and cmath.

Let me know if I have made any errors!
msg272505 - (view) Author: Mark Dickinson (mark.dickinson) * Date: 2016-08-12 08:43
The unification of tau2.diff and tau3.diff LGTM; thanks, Lisa!

My commit bit is broken at the moment; anyone in a position to apply those patches?
msg272507 - (view) Author: Mark Dickinson (mark.dickinson) * Date: 2016-08-12 09:06
BTW, if we're talking about useless constants in the math module, it's hard to get more useless than math.e: it's rare for e to turn up in formulas except in the form e**<something>, and the latter case is better catered for by the more accurate (and usually faster) expression exp(<something>. I'd even go so far as to call math.e *worse* than useless, since its presence leads people astray by encouraging them to write math.e**x instead of exp(x).

To give just one example, on my machine, the result of exp(500) has an error of 0.42 ulps, while math.e**500 gives an error of over 150 ulps.
msg272509 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * Date: 2016-08-12 09:20
> To give just one example, on my machine, the result of exp(500) has an
> error of 0.42 ulps, while math.e**500 gives an error of over 150 ulps.

How can it be? math.e**500 = math.exp(math.log(math.e)*500) and
math.log(math.e) is 1.0.
msg272533 - (view) Author: STINNER Victor (vstinner) * Date: 2016-08-12 12:19
> math.e**500 = math.exp(math.log(math.e)*500)

That's the theory if numbers have an infinite precision. In practice,
intermediate results are rounded and have a limited precision.
msg272555 - (view) Author: Tim Peters (tim.peters) * Date: 2016-08-12 18:45
Serhiy's objection is a little subtler than that.  The Python expression math.log(math.e) in fact yields exactly 1.0, so IF it were the case that x**y were implemented as

math.exp(math.log(x) * y)

THEN math.e**500 would be computed as math.exp(math.log(math.e) * 500) == math.exp(1.0 * 500) == math.exp(500.0).

But that's not how x**y is implemented.  Because the error in log() is multiplied by y, and then fed into exp() blowing it up even more, only a hopelessly naive library would implement pow() that way.  In practice, library pow functions fake the effect of at least 15 more bits than native double precision to absorb these errors.

Under the covers, then, a reasonable library pow computes math.log(math.e) to more than native double precision - and _that_ (internal, invisible) result is not 1.0.  Because math.e isn't the mathematical e to begin with.  The difference between math.e and the mathematical e is a difference quite visible to the internal log, which delivers an internal log not equal to 1, and its difference from 1 is "an error" multiplied by 500 and fed into the internal exp (blowing up the error even more).

In the end, math.e**500 returns a very good approximation to the true value, _given_ that math.e is not e.  There's no reason to hope that's close to exp(500), though - that delivers a very good approximation to e**500 (where e is the true e).  The larger the exponent, the more different math.e**y _should be_ from exp(y), and for the same fundamental reason 2**y differs from 3**y (or plug in any other pair of distinct bases).

All that said, I agree with Mark that math.e is at best an attractive nuisance.  Still, I'm -1 on removing it - it's a traditional and universally embraced nuisance ;-)
msg272561 - (view) Author: Paul Sokolovsky (pfalcon) * Date: 2016-08-12 20:24
What about rounding pi to 3 (and tau to 6)?

https://en.wikipedia.org/wiki/Indiana_Pi_Bill (and I'm sure we can find a cute video about how cool to have pi as 3 to add it to the docs).
msg272566 - (view) Author: Alexander Belopolsky (belopolsky) * Date: 2016-08-12 21:32
> All that said, I agree with Mark that math.e is at best an attractive nuisance.

Why don't we fix the nuisance part without making it less attractive:

class _E(float):
def __pow__(self, other):
if self is e:
return exp(other)
else:
return pow(self, other)

e = _E(2.718281828...)

> It's okay if Python occasionally shows its lighter side in unexpected places.

I would rather see

from math import π

work in the future Pythons.

I like Vi Hart, but I am firmly on the π side in the π vs. τ debate.  The problem with τ is that it is visually smaller than π, actually twice smaller: π ≈ ττ, but the actual definition is the opposite.
msg272592 - (view) Author: Xavier Combelle (xcombelle) * Date: 2016-08-13 16:43
Python will really follow the tau sort joke ? I never saw it mentioned in any serious math or programming document. All the github search result looks like people who are in this joke (kind of).

The page http://tauday.com/state-of-the-tau list very little use of tau in relevant domains, the most relevant to our discussion would be the including of tau in modula-2 standard library.

I don't see how the introduction of the unknown tau constant in python programs will make them clearer or better to the targeted public who will read them.

I must confess however that 2*pi occurs frequently in formula and these formula would be simplified if tau was used. However an honest and non partisan web site would list all the use of pi without 2 where the formula would be more complicated. I don't see that so I'm still not convinced.

I know that Guido van Rossum is the Benevolent dictator for life of python, but as I understand it until this point, the dictator position was used after all argument took place and not before.
msg272598 - (view) Author: Vedran Čačić (veky) * Date: 2016-08-13 17:40
> However an honest and non partisan web site would list all the use of pi without 2 where the formula would be more complicated. I don't see that so I'm still not convinced.

"non partisan" is probably hard to find, but if you want to see the other side of the story, http://www.thepimanifesto.com/ is probably most accessible.
msg272601 - (view) Author: Georg Brandl (georg.brandl) * Date: 2016-08-13 17:51
Please folks. Stop taking this so seriously and remember that this is the language where you can type in

>>> import antigravity

and it actually works. (Sort of.)
msg272617 - (view) Author: Vedran Čačić (veky) * Date: 2016-08-13 20:49
As an Easter egg, of course. I'm all for it. But please take a look at https://docs.python.org/3.5/search.html?q=antigravity&check_keywords=yes&area=default
msg272618 - (view) Author: Decorater (Decorater) * Date: 2016-08-13 21:16
not to mention I like to use the following expression myself.

pie = 22 / 7  # because why not?
tau = 2 * pie
msg272627 - (view) Author: Antoine Pitrou (pitrou) * Date: 2016-08-14 00:38
Unsubscribing from this ridiculous issue. Guido, do your thing.
msg272671 - (view) Author: Chih-Hsuan Yen (yan12125) * Date: 2016-08-14 12:58
The documentation of tau should mention it's equal to 2 * pi.
msg272679 - (view) Author: STINNER Victor (vstinner) * Date: 2016-08-14 16:10
Chi Hsuan Yen added the comment:
> The documentation of tau should mention it's equal to 2 * pi.

According to this discussion, tau is very important. Maybe it's better to
document pi as tau/2? :-)
msg272682 - (view) Author: Chih-Hsuan Yen (yan12125) * Date: 2016-08-14 16:38
From http://tauday.com/

> No, really, pi is wrong...

For me it's a sign that pi is (currently) more common than tau. One purpose of the documentation is helping newcomers understand what Python's built-in objects mean. "tau = 2 * pi" is better than "pi = tau / 2" as those who know pi only are more than those who know tau only.
msg272714 - (view) Author: Lisa Roach (lisroach) * Date: 2016-08-15 04:27
I have added some more detail to the Tau documentation, including that Tau is 2 * pi, as well as some links to Tau Day and Vi Hart's video.

That should give Python users enough to get started forming their own opinions on tau vs pi :)
msg272770 - (view) Author: Guido van Rossum (gvanrossum) * Date: 2016-08-15 15:37
Lisa, this LGTM. I'll commit it so we can put this behind us!
msg272775 - (view) Author: Roundup Robot (python-dev) Date: 2016-08-15 16:15
New changeset 68f2d6098be1 by Guido van Rossum in branch 'default':
Issue #12345: Add mathemathcal constant tau to math and cmath.
https://hg.python.org/cpython/rev/68f2d6098be1
msg272777 - (view) Author: Alexander Belopolsky (belopolsky) * Date: 2016-08-15 16:23
There is a typo in the NEWS entry:

"Issue #12345: Add *mathemathcal* constant tau to math ..."
msg272802 - (view) Author: Guido van Rossum (gvanrossum) * Date: 2016-08-15 22:09
Thanks, fixed.
msg313664 - (view) Author: Mark Dickinson (mark.dickinson) * Date: 2018-03-12 16:25
Why does this issue keep ending up as the target of unrelated PR notifications?
msg313668 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * Date: 2018-03-12 16:33
Because of its lucky number. See https://github.com/python/core-workflow/issues/223 (fixed).
History
Date User Action Args
2018-04-10 06:16:00sbairdsetnosy: - sbaird
2018-04-10 06:03:29serhiy.storchakasetpull_requests: - pull_request6132
2018-04-09 20:27:49PokestarFansetpull_requests: + pull_request6132
2018-03-12 16:33:38serhiy.storchakasetmessages: + msg313668
2018-03-12 16:25:04mark.dickinsonsetmessages: + msg313664
2018-03-10 15:17:20serhiy.storchakasetpull_requests: - pull_request5816
2018-03-10 15:08:29tttnnssetpull_requests: + pull_request5816
2018-02-25 20:20:09mark.dickinsonsetpull_requests: - pull_request5653
2018-02-25 17:14:13gvanrossumsetnosy: - gvanrossum
2018-02-25 11:31:19christian.heimessetpull_requests: + pull_request5653
2018-02-25 10:07:04mark.dickinsonsetpull_requests: - pull_request5651
2018-02-25 10:02:49christian.heimessetpull_requests: + pull_request5651
2018-02-25 01:35:51ncoghlansetpull_requests: - pull_request5640
2018-02-25 00:53:16python-devsetpull_requests: + pull_request5640
2018-02-24 08:02:33serhiy.storchakasetpull_requests: - pull_request5622
2018-02-24 07:56:58yan12125setnosy: - yan12125
2018-02-24 07:52:47tttnnssetpull_requests: + pull_request5622
2017-05-25 10:51:23vstinnersetpull_requests: - pull_request1878
2017-05-24 20:43:34python-devsetpull_requests: + pull_request1878
2016-08-15 22:09:11gvanrossumsetmessages: + msg272802
2016-08-15 16:23:54belopolskysetmessages: + msg272777
2016-08-15 16:16:35gvanrossumsetstatus: open -> closed
resolution: fixed
2016-08-15 16:15:56python-devsetmessages: + msg272775
2016-08-15 15:37:29gvanrossumsetmessages: + msg272770
2016-08-15 04:27:09lisroachsetfiles: + tau4.diff

messages: + msg272714
2016-08-14 16:38:51yan12125setmessages: + msg272682
2016-08-14 16:17:56ebarrysetnosy: - ebarry
2016-08-14 16:12:39zach.waresetnosy: - zach.ware
2016-08-14 16:10:48vstinnersetmessages: + msg272679
2016-08-14 12:58:10yan12125setnosy: + yan12125
messages: + msg272671
2016-08-14 00:39:06pitrousetnosy: - pitrou
2016-08-14 00:38:53pitrousetnosy: gvanrossum, tim.peters, georg.brandl, rhettinger, pfalcon, mark.dickinson, ncoghlan, belopolsky, pitrou, vstinner, benjamin.peterson, stutzbach, eric.araujo, Aaron.Meurer, python-dev, sbaird, zach.ware, serhiy.storchaka, waldir, xcombelle, veky, ebarry, Nofar Schnider, lisroach, Decorater
messages: + msg272627
2016-08-13 21:19:35skrahsetnosy: - skrah
2016-08-13 21:16:08Decoratersetnosy: + Decorater
messages: + msg272618
2016-08-13 20:49:47vekysetmessages: + msg272617
2016-08-13 17:51:34georg.brandlsetmessages: + msg272601
2016-08-13 17:40:02vekysetmessages: + msg272598
2016-08-13 16:43:08xcombellesetnosy: + xcombelle
messages: + msg272592
2016-08-12 21:32:37belopolskysetnosy: + belopolsky
messages: + msg272566
2016-08-12 20:24:45pfalconsetnosy: + pfalcon
messages: + msg272561
2016-08-12 12:19:13vstinnersetmessages: + msg272533
2016-08-12 09:20:04serhiy.storchakasetmessages: + msg272509
2016-08-12 09:06:08mark.dickinsonsetmessages: + msg272507
2016-08-12 08:43:39mark.dickinsonsetmessages: + msg272505
2016-08-12 03:39:09lisroachsetfiles: + tau3.diff
nosy: + lisroach
messages: + msg272493

2016-08-12 00:13:37gvanrossumsetmessages: + msg272487
2016-08-11 21:49:59Aaron.Meurersetmessages: + msg272485
2016-08-11 21:28:28gvanrossumsetmessages: + msg272484
2016-08-11 20:55:52ebarrysetnosy: + ebarry
messages: + msg272483
2016-08-11 20:04:38skrahsetnosy: + skrah
messages: + msg272478
2016-08-11 19:52:07Aaron.Meurersetmessages: + msg272476
2016-08-11 18:45:08Aaron.Meurersetmessages: + msg272473
2016-08-11 18:44:05pitrousetmessages: + msg272472
2016-08-11 18:34:00Aaron.Meurersetnosy: + Aaron.Meurer
2016-08-11 18:22:19serhiy.storchakasetmessages: + msg272470
2016-08-11 18:15:00pitrousetmessages: + msg272469
2016-08-11 18:12:23Evelyn Mitchellsetnosy: - Evelyn Mitchell
2016-08-11 17:49:15vekysetnosy: + veky
messages: + msg272465
2016-08-11 15:34:52gvanrossumsetmessages: + msg272457
2016-08-11 08:40:19Nofar Schnidersetnosy: + Nofar Schnider
messages: + msg272422
2016-08-10 20:41:00Evelyn Mitchellsetnosy: + Evelyn Mitchell
messages: + msg272377
2016-08-10 20:39:30pitrousetmessages: + msg272376
2016-08-10 20:39:12gvanrossumsetmessages: + msg272375
2016-08-10 20:36:42serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg272374
2016-08-10 20:31:01rhettingersetmessages: + msg272373
2016-08-10 10:25:39mark.dickinsonsetmessages: + msg272325
2016-08-10 07:14:17mark.dickinsonsetmessages: + msg272319
messages: + msg272304
2016-08-10 04:26:09gvanrossumsetfiles: + tau2.diff

messages: + msg272301
2016-08-10 04:21:40zach.waresetversions: + Python 3.6
nosy: + zach.ware

messages: + msg272299

stage: needs patch -> commit review
2016-08-10 01:45:58gvanrossumsetfiles: + tau.diff
keywords: + patch
2016-08-10 01:41:57gvanrossumsetstatus: closed -> open
assignee: gvanrossum
resolution: rejected -> (no value)
messages: + msg272287
2013-03-16 07:02:43terry.reedysetmessages: - msg184297
2013-03-16 07:01:54python-devsetnosy: + python-dev
messages: + msg184297
2013-02-28 03:13:26waldirsetnosy: + waldir
messages: + msg183198
2013-02-26 00:17:05sbairdsetmessages: + msg183004
2011-07-26 14:26:51eric.araujosetfiles: - unnamed
2011-07-26 14:26:49eric.araujosetnosy: + eric.araujo
2011-06-27 23:37:41gvanrossumsetnosy: + gvanrossum
messages: + msg139338
2011-06-17 21:14:55georg.brandlsetnosy: + georg.brandl
messages: + msg138553
2011-06-17 21:04:54mark.dickinsonsetnosy: + mark.dickinson
messages: + msg138551
2011-06-17 20:33:38stutzbachsetfiles: + unnamed

messages: + msg138548
nosy: + stutzbach
2011-06-16 23:09:47sbairdsetnosy: + sbaird
2011-06-16 13:20:30benjamin.petersonsetmessages: + msg138431
2011-06-16 11:40:47pitrousetstatus: open -> closed
2011-06-16 11:31:46vstinnersetstatus: pending -> open

messages: + msg138423
2011-06-16 11:16:58pitrousetstatus: open -> pending

nosy: + pitrou
messages: + msg138422

resolution: rejected
2011-06-16 10:43:27vstinnersetnosy: + vstinner
messages: + msg138421
2011-06-16 10:32:19ncoghlansetmessages: + msg138419
2011-06-16 06:12:23rhettingersetnosy: + rhettinger
messages: + msg138416
2011-06-16 03:50:34benjamin.petersonsetnosy: + benjamin.peterson
messages: + msg138414
2011-06-16 03:10:29ncoghlancreate