Author lemburg
Recipients Retro, belopolsky, brian.curtin, georg.brandl, lemburg, mark.dickinson, michael.foord, pitrou, rhettinger
Date 2010-12-02.21:24:17
SpamBayes Score 7.1135e-09
Marked as misclassified No
Message-id <4CF80E7F.5080201@egenix.com>
In-reply-to <1291318810.85.0.116938218004.issue10562@psf.upfronthosting.co.za>
Content
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) ?
History
Date User Action Args
2010-12-02 21:24:19lemburgsetrecipients: + lemburg, georg.brandl, rhettinger, mark.dickinson, belopolsky, pitrou, Retro, michael.foord, brian.curtin
2010-12-02 21:24:17lemburglinkissue10562 messages
2010-12-02 21:24:17lemburgcreate