Issue 10562: Change 'j' for imaginary unit into an 'i' (original) (raw)
Created on 2010-11-28 15:19 by Retro, last changed 2022-04-11 14:57 by admin. This issue is now closed.
Messages (60)
Author: Boštjan Mejak (Retro)
Date: 2010-11-28 15:19
In Python, the letter 'j' denotes the imaginary unit. It would be great if we would follow mathematics in this regard and let the imaginary unit be denoted with an 'i'.
Author: Michael Foord (michael.foord) * 
Date: 2010-11-28 15:21
We follow engineering which uses j.
(I was about to close this as wontfix but Antoine is particularly keen that Mark deals with this issue...)
Author: Mark Dickinson (mark.dickinson) *
Date: 2010-11-28 16:06
Glad to oblige. :-)
Author: Mark Dickinson (mark.dickinson) *
Date: 2010-11-28 16:11
Just to add my own thoughts: 'j' for a (not the ) square root of -1 has, as Michael points out, a history of use in engineering (particularly electrical engineering) and physics. Personally, I would have preferred 'i' to 'j' here, but changing it now would cause (IMO) gratuitous breakage. It really doesn't seem a big enough issue to be worth making a fuss about.
Author: Boštjan Mejak (Retro)
Date: 2010-11-28 20:30
"The Python programming language also uses j to denote the imaginary unit. MATLAB associates both i and j with the imaginary unit." -Wikipedia<http://en.wikipedia.org/wiki/Imaginary_unit#Alternative_notations>
It would be a welcome feature in Python if the programming language would, like MATLAB, associate both i and j with the imaginary unit.
Author: Alexander Belopolsky (belopolsky) *
Date: 2010-11-28 20:49
Why not allow complex('1i')?
(Tongue in cheek: I am really looking for arguments against lax parsing in number builtins. See issue 10557.)
Author: Mark Dickinson (mark.dickinson) *
Date: 2010-11-28 20:55
It would be a welcome feature in Python if the programming language would, like MATLAB, associate both i and j with the imaginary unit.
I suggest taking this to the python-ideas mailing list. A working patch might increase the idea's chances.
Author: Mark Dickinson (mark.dickinson) *
Date: 2010-11-28 20:58
Why not allow complex('1i')?
Indeed, if 4i were permitted as an imaginary literal, I'd expect to allow complex('3 + 4i') as well.
(And possible just plain complex('i') too, since complex('j') is currently allowed. Grr.)
Author: Alexander Belopolsky (belopolsky) *
Date: 2010-11-28 21:03
On Sun, Nov 28, 2010 at 3:58 PM, Mark Dickinson <report@bugs.python.org> wrote: ..
I'd expect to allow complex('3 + 4i') as well.
And with spaces surrounding '+' too.
Author: Boštjan Mejak (Retro)
Date: 2010-11-28 21:14
It would be great if the feature of having both j and i would exist in the interpreter core, as well as the built-in function complex() to accept i.
Author: Antoine Pitrou (pitrou) *
Date: 2010-11-28 21:17
There should be an environment variable to make the symbol settable.
$ PYTHONIMAGINARYSYMBOL=i python -c "import cmath; print(cmath.sqrt(-1))" 1i
Author: Antoine Pitrou (pitrou) *
Date: 2010-11-28 21:17
(and perhaps a ResourceWarning if you choose something different from i and j)
Author: Boštjan Mejak (Retro)
Date: 2010-12-02 18:56
The imaginary unit 'i' should be equvivalent to the imaginary unit 'j'. The imaginary unit, however, should be used consistently in the source code.
Author: Raymond Hettinger (rhettinger) *
Date: 2010-12-02 19:04
If this change were important, the numpy/scipy guys would have requested it long ago. Any possible benefit would be slight and not at all worth the disruption.
s.replace('j', 'i')
Author: Mark Dickinson (mark.dickinson) *
Date: 2010-12-02 19:40
There should be an environment variable to make the symbol settable.
That could work; it's a bit late to do this in 3.2, though. How about the following transition strategy for the complex output.
Python 3.3: Introduce PYTHONIMAGINARYSYMBOL environment variable (and possibly also a related command-line option to the interpreter?).
Python 3.4: Show a warning on startup if this environment variable isn't used.
Python 3.5: Make the environment variable mandatory.
Python 3.6: Make the environment variable optional again, but this time with the default output being 'i' rather than 'j'.
Python 3.7: Deprecate use of PYTHONIMAGINARYSYMBOL. (Warning on startup if it's set.)
Python 3.8: Error on startup if PYTHONIMAGINARYSYMBOL is set.
Python 3.9: Go back to ignoring PYTHONIMAGINARYSYMBOL.
I'm sure we could find a compatible transition strategy for the complex inputs: (3.3: accept both 'i' and 'j'; 3.6: warn about 'j' usage; 3.8 remove acceptance of 'j' on input).
Author: Boštjan Mejak (Retro)
Date: 2010-12-02 19:46
That is acceptable, but way to slow for the 'j' imaginary unit to become extinct. It should happen sooner.
Author: Georg Brandl (georg.brandl) *
Date: 2010-12-02 20:30
We also should consider a good roadmap to account for the eventual support of quaternions in the language syntax.
Since the conventional mathematical symbols for the additional imaginary units of quaternions are j and k, confusion is bound to happen.
My preferred solution is to limit PYTHONIMAGINARYSYMBOL values to "i", "j" or "k" in Python 3.4. The two additional imaginary unit symbols would then be a cyclic permutation of i,j,k, viz. for PYTHONIMAGINARYSYMBOL=j, the units are k and i.
This deterministic approach has the advantage that migration of code from one imaginary symbol to another is as easy as:
sed -e 's/k/l/' -e 's/j/k/' -e 's/i/j/' -e 's/l/i/'
provided that you restrict yourself not to use the characters i, j, k or l in identifiers, keywords or strings in the source code.
Author: Antoine Pitrou (pitrou) *
Date: 2010-12-02 20:41
Since the conventional mathematical symbols for the additional imaginary units of quaternions are j and k, confusion is bound to happen.
My preferred solution is to limit PYTHONIMAGINARYSYMBOL values to "i", "j" or "k" in Python 3.4. The two additional imaginary unit symbols would then be a cyclic permutation of i,j,k, viz. for PYTHONIMAGINARYSYMBOL=j, the units are k and i.
Can we consider an environment variable to change the direction of the permutation, e.g. PYTHONIMAGINARYPERMUTATIONDIR=-1?
Otherwise +11j from me.
Author: Raymond Hettinger (rhettinger) *
Date: 2010-12-02 20:41
Since we have two distinct user groups (engineers and everyone else), it's clear that we should fork Python. That would let each group work with their on most-natural-representation and it would prevent unnecessary configuration challenges.
Benjamin, could you please start a new branch and fork the website into python.i.org and python.j.org.
Author: Brian Curtin (brian.curtin) *
Date: 2010-12-02 20:45
Will PYTHONIMAGINARYPERMUTATIONDIR accept imaginary numbers? If so, we will also need PYTHONIMAGINARYPERMUTATIONDIRIMAGINARYIDENTIFIER.
Author: Boštjan Mejak (Retro)
Date: 2010-12-02 20:57
How did you implement the letter 'j' as the imaginary unit? Can you now implement the letter 'i' to act as an imaginary unit? Is that possible? If it's possible in MATLAB, why not have both 'j' and 'i' in Python as well?
Author: Georg Brandl (georg.brandl) *
Date: 2010-12-02 21:06
I heard that MathWorks has a patent on METHOD AND APPARATUS FOR IMAGINATORIAL FREEDOM, so if that's true we might not be allowed to implement it.
Author: Boštjan Mejak (Retro)
Date: 2010-12-02 21:13
"In electrical engineering<http://en.wikipedia.org/wiki/Electrical_engineering> and related fields, the imaginary unit is often denoted by j to avoid confusion with electrical current<http://en.wikipedia.org/wiki/Current_(electricity)> as a function of time, traditionally denoted by i(t) or just i." -Wikipedia
Does Python have to deal with electrical current as a function of time to associate j with the imaginary unit and not i?
Author: Brian Curtin (brian.curtin) *
Date: 2010-12-02 21:14
yes
Author: Georg Brandl (georg.brandl) *
Date: 2010-12-02 21:16
Sure. I have personally written software where i denotes, in effect, an electrical current.
Author: Raymond Hettinger (rhettinger) *
Date: 2010-12-02 21:21
Can you now implement the letter 'i' to act as an imaginary unit? Is that possible?
Yes, it's possible; however, the developers do not think it is worthwhile.
If it's possible in MATLAB, why not have both 'j' and 'i' in Python as well?
Python does some things differently that MATLAB. One design choice is to avoid global configurations (such as number of places displayed in a float) because modules written by different people make make different assumptions or may compete for a preferred setting.
Let's try to end this thread now. It's a bit of no-win situtation. None of the core devs see enough possible benefit to warrant the disruption it would cause. Years of Python being used in the scientific community has shown that the current use of 'j' has not been a problem.
Author: Marc-Andre Lemburg (lemburg) *
Date: 2010-12-02 21:24
Mark Dickinson wrote:
Mark Dickinson <dickinsm@gmail.com> added the comment:
There should be an environment variable to make the symbol settable.
That could work; it's a bit late to do this in 3.2, though. How about the following transition strategy for the complex output.
Python 3.3: Introduce PYTHONIMAGINARYSYMBOL environment variable (and possibly also a related command-line option to the interpreter?).
Python 3.4: Show a warning on startup if this environment variable isn't used.
Python 3.5: Make the environment variable mandatory.
Python 3.6: Make the environment variable optional again, but this time with the default output being 'i' rather than 'j'.
Python 3.7: Deprecate use of PYTHONIMAGINARYSYMBOL. (Warning on startup if it's set.)
Python 3.8: Error on startup if PYTHONIMAGINARYSYMBOL is set.
Python 3.9: Go back to ignoring PYTHONIMAGINARYSYMBOL.
I'm sure we could find a compatible transition strategy for the complex inputs: (3.3: accept both 'i' and 'j'; 3.6: warn about 'j' usage; 3.8 remove acceptance of 'j' on input).
Hmm, what calendar are you using ? April 1st is still a few months away on the Gregorian one and even the Julian calendar isn't that far off yet :-)
Why not simply support both for number constructors (and stick with 'j' for the language spec) ?
Author: Mark Dickinson (mark.dickinson) *
Date: 2010-12-02 21:33
In all seriousness, the idea of accepting both 'i' and 'j' in complex() isn't horrible. I'm personally -0.small on it, mostly because it seems likely to lead to more objections about the complex str() and repr() output containing 'j's. I still think python-ideas would be a more appropriate place for that discussion, though.
Author: Marc-Andre Lemburg (lemburg) *
Date: 2010-12-02 22:01
Mark Dickinson wrote:
Mark Dickinson <dickinsm@gmail.com> added the comment:
In all seriousness, the idea of accepting both 'i' and 'j' in complex() isn't horrible. I'm personally -0.small on it, mostly because it seems likely to lead to more objections about the complex str() and repr() output containing 'j's. I still think python-ideas would be a more appropriate place for that discussion, though.
I think this falls under a "locale" problem of some sort... engineers like 'j', mathematician prefer 'i'.
Personally, I think it's more important to be able to read scientific data easily without too many problems, then to be able to write the processed data in exactly the same way it was read.
When formatting complex numbers, you have the issues of whether to include spaces, parens, 'i' or 'j', so this is better left to a application space function to deal with, IMHO.
I would prefer to have str() and repr() always use the parens and j notation - it makes recognizing complex numbers easier, e.g. compare
(1+0j)
0+1j 1j 11 11
to
(1+0j)
0+1j (0+1j) 11 11
(but I guess that another problem)
Author: Mark Dickinson (mark.dickinson) *
Date: 2010-12-02 22:08
Personally, I think it's more important to be able to read scientific data easily without too many problems, then to be able to write the processed data in exactly the same way it was read.
I wonder whether there are many examples where scientific data is written in a form that Python's complex() constructor couldn't currently read, but would be able to read if it accepted 'i' in place of 'j'.
My (wild) guess would be that, in the cases where the data isn't stored in binary form anyway, complex numbers are written simply as pairs of floats.
Author: Georg Brandl (georg.brandl) *
Date: 2010-12-02 22:15
That would be a good question for a numpy/scipy-related mailing list, I guess.
Author: Mark Dickinson (mark.dickinson) *
Date: 2010-12-02 22:29
Maybe we need a complex analog to datetime.strptime:
complex.strpcx('(3 + 4i)', '(%R + %Ii)') -> 3 + 4j
Author: Antoine Pitrou (pitrou) *
Date: 2010-12-02 22:42
Le jeudi 02 décembre 2010 à 22:29 +0000, Mark Dickinson a écrit :
Mark Dickinson <dickinsm@gmail.com> added the comment:
Maybe we need a complex analog to datetime.strptime:
complex.strpcx('(3 + 4i)', '(%R + %Ii)') -> 3 + 4j
How about '3 + 4i'.transform('complex')?
Author: Boštjan Mejak (Retro)
Date: 2010-12-02 23:54
(7.8064-6j)
According to PEP 8, the output in our example should be with spaces surrounding the subtraction operator, like this:
(1 + 2.56j) * (-1 - 3.44j) (7.8064 - 6j)
Author: Éric Araujo (eric.araujo) *
Date: 2010-12-03 04:49
Whether 1+2j is a literal or an expression is debatable. I think +1 is an expression but 1+2j is a literal; neither should have a space.
I’m not sure the language reference and the actual implementation are in agreement here (I have peephole optimizations in mind).
Author: Alexander Belopolsky (belopolsky) *
Date: 2010-12-03 05:34
On Thu, Dec 2, 2010 at 11:49 PM, Éric Araujo <report@bugs.python.org> wrote: ..
Whether 1+2j is a literal or an expression is debatable. I think +1 is an expression but 1+2j is a literal; neither should have a space.
With respect to implementation there is no debate:
[TokenInfo(type=57 (ENCODING), string='utf-8', start=(0, 0), end=(0, 0), line=''), TokenInfo(type=2 (NUMBER), string='1', start=(1, 0), end=(1, 1), line='1+1j'), TokenInfo(type=53 (OP), string='+', start=(1, 1), end=(1, 2), line='1+1j'), TokenInfo(type=2 (NUMBER), string='1j', start=(1, 2), end=(1, 4), line='1+1j'), TokenInfo(type=0 (ENDMARKER), string='', start=(2, 0), end=(2, 0), line='')]
[TokenInfo(type=57 (ENCODING), string='utf-8', start=(0, 0), end=(0, 0), line=''), TokenInfo(type=53 (OP), string='-', start=(1, 0), end=(1, 1), line='-1'), TokenInfo(type=2 (NUMBER), string='1', start=(1, 1), end=(1, 2), line='-1'), TokenInfo(type=0 (ENDMARKER), string='', start=(2, 0), end=(2, 0), line='')]
(Who designed the tokenize interface, btw? I took me 3 tries to come up with the incantation above.)
I’m not sure the language reference and the actual implementation are in agreement here (I have peephole optimizations in mind).
Literals are atomic to the tokenizer. AST processes a stream of tokens. Peephole optimizations are irrelevant because these are hacks that operate on the bytecode when the lexical structure is all but forgotten.
Author: Alexander Belopolsky (belopolsky) *
Date: 2010-12-03 05:35
And of course, roundup ate my work. The tokenize incantation was
pprint(list(tokenize(iter([b'1+1j']).next)))
Author: Mark Dickinson (mark.dickinson) *
Date: 2010-12-03 08:00
Whether 1+2j is a literal or an expression is debatable.
Really? I can't imagine what basis you'd have for calling either 1+2j or +1 a literal.
Author: Georg Brandl (georg.brandl) *
Date: 2010-12-03 08:53
An imaginary basis maybe?
Author: Boštjan Mejak (Retro)
Date: 2010-12-03 09:26
The result of 1 + 2j cannot be further broken down, so the result stays as 1
- 2j (note the spaces!).
(1+2j)
(1 + 2j)
Following PEP 8 in this regard is also needed. Abandon the request of adding the i unit and rather fix this spacing issue. The complex() built-in function should also be fixed to add spaces around operators.
Author: Marc-Andre Lemburg (lemburg) *
Date: 2010-12-03 09:35
Mark Dickinson wrote:
Mark Dickinson <dickinsm@gmail.com> added the comment:
Maybe we need a complex analog to datetime.strptime:
complex.strpcx('(3 + 4i)', '(%R + %Ii)') -> 3 + 4j
That's a good idea.
Perhaps we could also add a .strfcx() to do the formatting in much the same way.
Author: Robert Lehmann (lehmannro) *
Date: 2010-12-03 09:45
I wonder whether there are many examples where scientific data is written in a form that Python's complex() constructor couldn't currently read, but would be able to read if it accepted 'i' in place of 'j'.
I could not reproduce widespread real world issues with the syntax as it stands using Google Code Search (a mere 4 unique hits). http://goo.gl/sqMhY
Author: Mark Dickinson (mark.dickinson) *
Date: 2010-12-03 09:59
Thanks for that, Robert.
Actually, I find those few results quite convincing as evidence that it would be useful to support 'i' (and 'I') on input.
Author: Éric Araujo (eric.araujo) *
Date: 2010-12-03 12:45
I can't imagine what basis you'd have for calling either 1+2j or +1 a literal.
Poor understanding of the parser/tokenizer/formal grammar.
Author: Boštjan Mejak (Retro)
Date: 2010-12-03 13:41
Please make the tokenizer surround spaces around operators. So the output would be like in the example below:
(1 + 2j)
(1 + 2j)
Author: Adam Byrtek (adambyrtek)
Date: 2010-12-03 16:18
What happened with "there should be one-- and preferably only one --obvious way to do it"?
Author: Boštjan Mejak (Retro)
Date: 2010-12-03 16:57
Indeed. There should be spaces around all the operators. Even in my posted example.
Author: Alexander Belopolsky (belopolsky) *
Date: 2010-12-03 17:18
On Fri, Dec 3, 2010 at 11:57 AM, Boštjan Mejak <report@bugs.python.org> wrote: ..
Indeed. There should be spaces around all the operators. Even in my posted example.
Aim higher: we obviously want Python output look beautiful in print, so operands should be surrounded by U+2009 (THIN SPACE).
Author: Boštjan Mejak (Retro)
Date: 2010-12-03 17:22
Alexander, is it possible to make an output like (1+2j) be printed as (1 + 2j). Also, why is the result put in parens?
Author: Alexander Belopolsky (belopolsky) *
Date: 2010-12-03 18:03
Alexander, is it possible to make an output like (1+2j) be printed as (1 + 2j).
Sure, and 'j' can be highlighted in red, but this is a job for a front-end or a custom display hook, not core python. You may want to take a look at ipython.
Also, why is the result put in parens?
There was a historical reason for that, but I don't remember it now. You may find the answer in the tracker, svn log, or python-dev archives.
It may not have been obvious, but most of the comments here including mine were not serious even when they did not include smileys. Nothing will happen here. Time to move on.
Author: Eric Pruitt (ericpruitt) *
Date: 2010-12-03 18:21
Also, why is the result put in parens?
Without them, something like 'eval("100 * " + repr(imaginary))' would not work properly.
Author: Boštjan Mejak (Retro)
Date: 2010-12-03 19:13
Parens are okay then. Still, put spaces around operators. If 1 + 2j let the output be (1 + 2j) Please!!!
Author: Boštjan Mejak (Retro)
Date: 2011-11-20 21:33
What's up with that now? Any interests in changing the imaginary unit from "j" to "i" ?
Author: Boštjan Mejak (Retro)
Date: 2011-11-20 21:37
Come on, let's do this.
Author: Alyssa Coghlan (ncoghlan) *
Date: 2011-11-20 23:51
While this thread was amusing to read, changing Python from the engineering notation to mathematical notation for imaginary numbers is not going to happen. 'i' has ambiguity problems relative to '1' and 'l' in too many fonts - 'j', on the other hand, almost always uses a visually distinct glyph. And whether 'i' or 'j' seems more natural to you will depend on whether or not you have an electrical engineering background (as noted earlier in the thread, 'i' refers to current in electrical engineering).
If you care about the precise formatting of a complex number, write your own formatting function rather than relying on the exact format produced by "repr(num)".
Having an alternate constructor for complex objects that was more forgiving about 'i' vs 'j' also doesn't offer a huge benefit over the simple "x = complex(arg.replace('i', 'j')".
So while I have some sympathy for mathematicians that are frustrated by having to train their fingers to hit 'j' instead of 'i', that's not a good enough reason to change the language syntax or the behaviour of the complex() builtin. (See also http://www.boredomandlaziness.org/2011/02/status-quo-wins-stalemate.html)
Author: Boštjan Mejak (Retro)
Date: 2011-11-21 19:20
It's stupid that the imaginary unit in Python is denoted by a "j" just for ambiguity reasons that "i" can be mistaken with a "1" or an "l". It's true that "1" and "l" can look the same in some fonts, but that is certainly not true for the small letter "i".
Just fix the "j" into an "i" already.
Author: Boštjan Mejak (Retro)
Date: 2011-11-21 19:25
Please fix this in Python 3.3 and don't forget to fix the complex() function/method as well.
Author: Brian Curtin (brian.curtin) *
Date: 2011-11-21 19:26
Please stop re-opening this thread. The reasons it will not be fixed have been laid out.
Author: Eric Snow (eric.snow) *
Date: 2011-11-21 19:54
@brian.curtin: +1
@Retro: as noted in #10621, please take this to python-ideas@python.org
Author: Guido van Rossum (gvanrossum) *
Date: 2011-11-21 20:12
This will not be fixed. For one thing, the letter 'i' or upper case 'I' look too much like digits. The way numbers are parsed either by the language parser (in source code) or by the built-in functions (int, float, complex) should not be localizable or configurable in any way; that's asking for huge disappointments down the road. If you want to parse complex numbers using 'i' instead of 'j', you have plenty of solutions available already.
History
Date
User
Action
Args
2022-04-11 14:57:09
admin
set
github: 54771
2011-11-21 20:12:36
gvanrossum
set
nosy: + gvanrossum
messages: +
2011-11-21 19:54:41
eric.snow
set
nosy: + eric.snow
messages: +
2011-11-21 19:26:59
brian.curtin
set
status: open -> closed
messages: +
resolution: remind -> wont fix
nosy: + brian.curtin, - gvanrossum
2011-11-21 19:25:41
Retro
set
messages: +
2011-11-21 19:24:26
Retro
set
nosy: + gvanrossum
2011-11-21 19:24:08
Retro
set
status: closed -> open
resolution: wont fix -> remind
2011-11-21 19:23:37
brian.curtin
set
status: open -> closed
resolution: remind -> wont fix
2011-11-21 19:20:42
Retro
set
status: closed -> open
resolution: wont fix -> remind
messages: +
2011-11-20 23:51:12
ncoghlan
set
status: open -> closed
nosy: + ncoghlan
messages: +
resolution: remind -> wont fix
stage: resolved
2011-11-20 21:37:16
Retro
set
status: closed -> open
resolution: wont fix -> remind
messages: +
versions: + Python 3.3, - Python 3.2
2011-11-20 21:33:02
Retro
set
messages: +
2010-12-04 19:49:50
eric.araujo
set
files: - unnamed
2010-12-04 00:32:49
rhettinger
set
nosy: - rhettinger
2010-12-03 19:13:43
Retro
set
files: + unnamed
messages: +
2010-12-03 19:04:05
pitrou
set
nosy: - pitrou
2010-12-03 18:44:55
mark.dickinson
set
assignee: mark.dickinson ->
nosy: - mark.dickinson
2010-12-03 18:28:47
ericpruitt
set
nosy: - ericpruitt
2010-12-03 18:24:58
adambyrtek
set
nosy: - adambyrtek
2010-12-03 18:21:14
ericpruitt
set
nosy: + ericpruitt
messages: +
2010-12-03 18:04:43
belopolsky
set
nosy: - belopolsky
2010-12-03 18:04:05
belopolsky
set
files: - unnamed
2010-12-03 18:03:56
belopolsky
set
files: - unnamed
2010-12-03 18:03:05
belopolsky
set
nosy:lemburg, rhettinger, mark.dickinson, belopolsky, pitrou, lehmannro, eric.araujo, Retro, adambyrtek
messages: +
2010-12-03 17:22:36
Retro
set
files: + unnamed
messages: +
2010-12-03 17🔞31
belopolsky
set
messages: +
2010-12-03 16:57:03
Retro
set
files: + unnamed
messages: +
2010-12-03 16🔞51
adambyrtek
set
nosy: + adambyrtek
messages: +
2010-12-03 15:22:30
michael.foord
set
nosy: - michael.foord
2010-12-03 15:21:22
georg.brandl
set
files: - unnamed
2010-12-03 15:21:19
georg.brandl
set
nosy: - georg.brandl
2010-12-03 13:43:58
brian.curtin
set
nosy: - brian.curtin
2010-12-03 13:41:37
Retro
set
files: + unnamed
messages: +
2010-12-03 12:46:27
eric.araujo
set
files: - unnamed
2010-12-03 12:45:18
eric.araujo
set
messages: +
2010-12-03 09:59:04
mark.dickinson
set
messages: +
2010-12-03 09:45:51
lehmannro
set
nosy: + lehmannro
messages: +
2010-12-03 09:35:30
lemburg
set
messages: +
2010-12-03 09:26:01
Retro
set
files: + unnamed
messages: +
2010-12-03 08:53:16
georg.brandl
set
messages: +
2010-12-03 08:00:18
mark.dickinson
set
messages: +
2010-12-03 05:37:08
belopolsky
set
messages: -
2010-12-03 05:36:26
belopolsky
set
messages: -
2010-12-03 05:35:34
belopolsky
set
messages: +
2010-12-03 05:34:00
belopolsky
set
messages: +
2010-12-03 05:33:38
belopolsky
set
messages: +
2010-12-03 05:33:33
belopolsky
set
messages: +
2010-12-03 04:49:30
eric.araujo
set
nosy: + eric.araujo
messages: +
2010-12-03 04:46:43
eric.araujo
set
files: - unnamed
2010-12-02 23:54:05
Retro
set
files: + unnamed
messages: +
2010-12-02 22:42:13
pitrou
set
messages: +
2010-12-02 22:29:01
mark.dickinson
set
messages: +
2010-12-02 22:15:46
georg.brandl
set
messages: +
2010-12-02 22:08:14
mark.dickinson
set
messages: +
2010-12-02 22:01:28
lemburg
set
messages: +
2010-12-02 21:33:25
mark.dickinson
set
messages: +
2010-12-02 21:24:17
lemburg
set
nosy: + lemburg
messages: +
2010-12-02 21:21:38
rhettinger
set
messages: +
2010-12-02 21:16:14
georg.brandl
set
messages: +
2010-12-02 21:14:51
brian.curtin
set
messages: +
2010-12-02 21:14:48
georg.brandl
set
files: - unnamed
2010-12-02 21:14:44
georg.brandl
set
files: - unnamed
2010-12-02 21:14:41
georg.brandl
set
files: - unnamed
2010-12-02 21:14:38
georg.brandl
set
files: - unnamed
2010-12-02 21:13:18
Retro
set
files: + unnamed
messages: +
2010-12-02 21:06:40
georg.brandl
set
messages: +
2010-12-02 20:57:12
Retro
set
files: + unnamed
messages: +
2010-12-02 20:45:06
brian.curtin
set
nosy: + brian.curtin
messages: +
2010-12-02 20:41:48
rhettinger
set
messages: +
2010-12-02 20:41:06
pitrou
set
messages: +
2010-12-02 20:30:35
georg.brandl
set
nosy: + georg.brandl
messages: +
2010-12-02 19:46:53
Retro
set
files: + unnamed
messages: +
2010-12-02 19:40:08
mark.dickinson
set
messages: +
2010-12-02 19:04:30
rhettinger
set
nosy: + rhettinger
messages: +
2010-12-02 18:56:23
Retro
set
files: + unnamed
messages: +
2010-11-28 21:19:18
mark.dickinson
set
files: - unnamed
2010-11-28 21:17:30
pitrou
set
messages: +
2010-11-28 21:17:05
pitrou
set
nosy: + pitrou
messages: +
2010-11-28 21:14:19
Retro
set
files: + unnamed
messages: +
2010-11-28 21:03:13
belopolsky
set
messages: +
2010-11-28 20:58:53
mark.dickinson
set
messages: +
2010-11-28 20:55:37
mark.dickinson
set
messages: +
2010-11-28 20:49:10
belopolsky
set
nosy: + belopolsky
messages: +
2010-11-28 20:43:22
georg.brandl
set
files: - unnamed
2010-11-28 20:30:00
Retro
set
files: + unnamed
messages: +
2010-11-28 16:11:59
mark.dickinson
set
messages: +
2010-11-28 16:06:02
mark.dickinson
set
status: open -> closed
resolution: wont fix
messages: +
2010-11-28 15:21:24
michael.foord
set
nosy: + michael.foord
messages: +
2010-11-28 15:19:52
pitrou
set
assignee: mark.dickinson
nosy: + mark.dickinson
2010-11-28 15:19:14
Retro
create